I did:

Think big, start small

Thinking big, starting small was definitely a theme for me this week. In some case, how we struggle to think big enough and in others how we don’t start small enough. Where it does work, it can lead to amazing things, so it’s still a principle I stand by.

• Took part in a problem space analysis session to bring together our thinking on organisational context and emerging strategy, policy and regulatory changes, and user research and known user needs. It’s a lot to think about and figure how each thing might affect our business model.
• Did an opportunity space mapping workshop in Excel. I’ve been experimenting with doing workshops without using Miro. The retro I did last week was in Loop and that worked pretty well.
• Went to a hackathon for AI.
• Used ‘working backwards’ to talk through a future business case I’m working on with another product manager.
• Chatted about the product skill of breaking big things down into small. It really is a skill.
• Planned a ‘who does what’ workshop. I’ve done this before to help product managers and delivery managers figure out how to work better together. I think it’s better done between people to bring out their strengths rather than using a standardised RACI (’cos, ya know, individuals and interactions over processes and tools).
• Went to our community of practice, which I usually miss because of other meetings. One of our senior product development managers led an excellent discussion on product metrics.

I read:

Management by objectives

Read lots about MBO and how it may be a useful for making an organization efficient, but it is no longer suitable for modern management because of the changing business world.

“Although MBO and empowerment represent a major step forward in management, they get results only insofar as employees are committed… The challenge today is not so much empowerment, but ownership: the sense of belonging, and the sense of purpose… In theory, MBO is intended to enhance communication and understanding up and down the hierarchy and across departments or units. The reality is rather opposite. The inflexibility of personal and departmental goals ends up creating a lack of cooperation between people and departments. This is because the goals are not geared toward the common good, but rather individual gain.”

The author of this 1972 paper thought that MBO would be consider an old fashion idea by the 1980’s. How wrong they were.

I believe OKRs done right are the antidote to this way of managing. Rather than assessing individuals by outputs, we should judge teams by outcomes.

43 minutes per staff member per day

Ben Holliday write about the problem of using AI in healthcare to improve on administrative processes that might be better fixed in other ways. My rule for using things like Copilot is to only use it if there isn’t a single right answer. And, I assume, lots of healthcare processes are about getting to the right answer, whether its how many boxes of surgical gloves to buy or which department has to cut their budget.

Service patterns

I’ve been thinking a bit about service patterns and then I read James’ weeknotes, which took me to service patterns UK, which took me to Ben Holliday’s website, which took me took to the gov design blog, which took me learn to drive a car. But all the while, the little product manager voice in my head said, “That’s just features.”

Sociotechnical principle of the day

Trond Hjorteland’s thread on sociotechnical principles is a really interesting read.

I thought:

How to identify strategic levers

Strategic levers are an important part of a product strategy. They describe the things within your control that you are going to use to affect things outside your control, usually user behaviour in a way that makes the product and organisation successful.

There has to be a cause and effect relationship between a lever and user behaviour. That relationship should make intuitive sense and the effect should show in the data. That’s why we treat levers as hypotheses, because until we’ve proved the effect of using the lever it’s little more than an informed guess.

The best way to figure out the levers your product should use is to start with the worthwhile problems you’ve identified. Ask yourself, what could solve this problem? Sometimes it helps to think of the levers as carrots or sticks, as things that encourage the kind of user behaviour you or discourage the kind of user behaviour you don’t want.

Then you need to think about how these levers work together and complement each other, and don’t counteract each other.

Metaphors

I’ve been thinking about the metaphors we use to talk about our products. At the moment, I like thinking about products as vehicles that take users on their (not our) journey.

Sometimes our users want a car so they can decide where they want to go. Other times, we want them to have a taxi with more knowledge about how to navigate to where they need to get to. And sometimes we want them to get on a bus so they can travel with other users. These three forms of travel; self-guided, org-guided, and community-guided, give us metaphors for talking about different types of products.

You know what else I realised? Business jargon is the same kind of abstraction as metaphors.

Mcdonaldization is not a product strategy

If your product strategy is about being the same as every other product, being unnoticeable and unremarkable, then you don’t have a product strategy.

Ritzer (1992), who came up with the term Mcdonaldization, was referring to organisations whose strategies are focused on being predictable, calculable, efficient and controllable.

A good product strategy knows when to use this kind of standardisation, but more importantly, how to differentiate. (This goes alongside my thoughts on marginal gains not being a good product strategy either).

The elephant and the knowledge workers

Us humans have a tendency to claim absolute truth based on our limited, subjective experience and inadvertently ignore other people’s limited, subjective experiences which may be equally true.

Post navigation