Weeknotes 353

This week I did:


Had a couple of conversations and wrote a bit about how we validate that we’re working on the right problems and have implemented the right solutions. Product management is fundamentally about validation. Anyone can do, but a product manager does and tries to prove it’s the right thing to do. So, I want to try to formalise the different techniques that we use to validate and in what situations they work best. For example, interviews are good for validating the problems people face, whilst user behaviour data is useful for validating whether the solution is working for people.


I tried a different format for my retro last month. High WIP is still a problem, but I’ve realised that context-switching seems to be my barrier to getting more done. Going from work to life to side-projects doesn’t happen smoothly as they use very different ways of thinking.

Website migration

I migrated my website to a new host. I’ve been meaning to do it for a while. There were some technical issues with the database import for the new host sorted it.

I read:

Modern work method

The Modern Work Method, derived from over 5,000 interviews with top business professionals, is a new philosophy of how to deliver business value fast, designed for the remote and distributed contexts in which many teams now work.

Move fast and fix things

James Plunkett writes about “the tensions between products and missions come down to the trade-off between pace and responsibility. Do we have to move slowly if we’re trying to fix big social problems? Or can we move fast, learning as we go?” This fits with my thinking about system-shifting product management and how product managers have a responsibility to apply a new way of thinking to tackle wicked problems through changing systems.

And I thought about:

Cross-functional teams and the problems they work on

The assumption behind stable cross-functional teams is that they’ll be solving the same kinds of problems repeatedly. That’s why they have a fixed skill set that includes all the skills they need. For teams tackling different and new problems, stability might be a hinderance as it brings bias about how to approach the problem. Creating new teams for new problems might be a better approach to solving them.

Meetings as attention grabbing

In my ongoing efforts to get to the source of the problem (much to the annoyance of others who would rather tackle surface signals) I’ve been thinking about system behaviours that drive too many meetings. I wonder if it’s connected to having a high level of work in progress.

Believing in the fast flow of value

I don’t think anyone really believes in the fast flow of value. The old mindset for work believes in productivity over value, in keeping everyone busy over solving customer problems. Shame really.