Weeknotes 389

This week I did:

Stuff

Among lots of others things I:

  • Welcomed our new director of digital & innovation. I’m really looking forward to seeing how our team shapes up over the next few months.
  • Kicked-off a short, sharp project to learn how to build high-performing campaign landing pages and generate new leads.
  • Chatted about how we create familiar mental models for ambiguous problems, and apply it to a new product we’re building.
  • Did a bit more audience validation work for that new product.

Productivity

Completed 55 tasks, an average of 11 a day.

Set five goals this week and achieved 20% of them. This takes my total weekly goal performance to 45%.

Using Google Tasks as a personal to do list is working pretty well so I’m trying out using it for work to do’s. I’m still of the opinion that an effective to do list is just about having reminders in one place to reduce cognitive load. The trick is in building the habit of remembering to add things people say, emails, thoughts you have, etc.

Roadmap

Started updating my roadmap to reflect the things I want to focus on this year. Still need more thinking, and I’m tempted to divide each of the columns with the smaller long-standing goals I have. Then it would show things like ‘Do Microsoft Learn courses… because it contributes to… formal learning… because it contributes to… continually developing my knowledge, skills and practice.’

Impact/effort mapping

Started writing a blog post on some thoughts on how to do impact/effort mapping in a way that reduces game-playing of putting the things where you know it means it’ll get them done and make it more adaptable to each team’s specific situation. Might even finish it one day (I also need to finish other posts about why impact/effort mapping is a bad idea because it prioritises work that is convenient for the organisation and product management maturity models).

And I read:

Getting user-centred design work into agile planning increments

I agree, “Working within the team tooling means being able to act as one team”. But it takes knowledge, experience and most of all, discipline, from everyone to use tools appropriately, and that’s more essential than what tool is used. I feel like we don’t talk enough about the discipline to stick with a well-defined process long enough to learn what needs to be improved.

How High-Performing Teams Build Trust

Collaboration, communication, credit and conflict. Four things for improving trust in teams.

The Chartability Workbook

This is awesome. A playbook for making data visualisations accessible.

The Strategic Foresight Book

I haven’t read it yet, but this book on strategic foresight from Ben Holt looks great. “The decisions we make now will impact the future, and that future will hold new challenges and unexpected opportunities. Strategic foresight allows us to engage with uncertainty, explore possibilities, and turn our insights into action today.” I’m really interested in how product managers do more thinking about uncertainty and what future possibilities might look like. But why a pdf?

I thought about:

It’s ok to do things badly

Maybe one of the consequences of Agile, Lean, start-up thinking, continuous everything, etc., is the idea that organisations and teams should always be getting better. Improvements must be made, everywhere, by everyone, for every process and product. Maybe not. Maybe it’s ok to be bad at what we do. Or mediocre, Or just good enough. Maybe we don’t need that kind of constant pressure.

Problem Solving perspectives

After an interesting chat, I thought about how the different functions of an organisation (finance, HR, design, product) are different perspectives on how to solve organisational problems. Perhaps finance sees solutions in terms of resources and infrastructure, maybe HR sees solutions as requiring people and skills, and product sees solutions as being about changing user behaviour. So, the goal of effective management is to get these perspectives to fit together and complement each other in ways that enables the organisation to successfully tackle all the problems it faces.

But it’s far more likely that those different perspectives are actually in conflict because we don’t have the language to explain them or the desire to challenge such deeply held beliefs. I wonder why it seems like more difficult in some organisations than others. And whether it has something to do with hierarchical, command-and-control structured organisations being clearer about the mental models they impose, whereas flatter organisations with more equally-powered leaders not providing that clarity. Or maybe it’s just one of those team dysfunctions at the leadership level regardless of structure.