Category: Blog

A simple product strategy has three parts:

1. A worthwhile problem to solve
2. A hypothesis about how to solve the problem
3. A way to know if the problem has been solved

A worthwhile problem to solve

This is where product managers spend most of their effort – finding and understanding problems and figuring out if they are worth solving. Those problems can be big or small, tame or wicked, organisational or customer problems. What makes the problem worth solving depends on the context but could include how many people it affects, how much they are willing to pay for a solution or how much it limits an organisation from doing what it wants to do. Without a worthwhile problem to solve, no strategy is going to create a successful product.

A hypothesis about how to solve the problem

With a deep understanding of the problem and confidence that it’s worth trying to solve, a product manager can create multiple hypotheses for solving the problem. Testing and validating these hypotheses enables the product manager to hone in on the solution most likely to succeed. Getting to a single well-defined hypothesis gives direction about what to build in order to solve the problem.

A way to know if the problem is solved

Product managers have to figure out how to know if the product they built has solved the problem. Often this is by understanding user behaviour and measuring whether the product caused a change in that behaviour, also known as achieving an outcome. The product also has to be scalable, financially viable, marketable, etc., etc. in order to solve the problem for lots of people at the same time.

Shuhari is a Japanese martial art concept which describes the stages of learning to mastery. Shuhari roughly translates to “to keep, to fall, to break away” or “follow the rules, break the rules, transcend the rules”.

What shuhari is

It’s what happens when you focus on a practice. It doesn’t matter what the practice is for as long as it involves:

• A skill that improves when repeated intentionally.
• Has an established and documented body of knowledge.
• Has space for novel change.

What shuhari isn’t

It isn’t:

• A maturity model – it doesn’t give us a stepped or staged approach to improving skills. It’s almost impossible to define the line between shu and ha or ha and ri.
• A skill assessment framework – it shouldn’t be used to compare one person with another. This is because everyone’s practice is unique to them.

Shuhari for product managers

Everyone starts their practice by learning and following the rules. In product management, this often means using frameworks and techniques without really understanding how or why they work. User stories are a good example. At the shu stage, the product manager focuses on the format and religiously sticks to the ‘As a…’ way of writing a user story. Everyone has to start here.

As they practice, they understand the limitations of sticking to the prescribed format for user stories. They develop the tacit knowledge of how user stories are really just a way of capturing conversations and recording shared understanding. When the product manager learns that how understanding is created and shared is more important than the format it’s recorded, then they are breaking the rules of user stories.

In time, with lots of practice, the product manager learns to apply the reasoning and rationale of user stories without having to consciously think about doing it. They know that user stories are a kind of boundary object. They have transcended the rules of user stories and reached the state of Ri.

Shuhari for teams

Different people on the same team can be in different places. One person might be very experienced and have spent a lot of time developing their skills, whilst another person might not have invested as much effort in their professional. This can cause tension. Someone at Ri could do something because they are so practiced they don’t even think about why they do it, but to someone at Shu, it looks wrong and doesn’t make sense.

Why shuhari matters

We often focus on skills at work but skills are really just the visible manifestation of practice. Shuhari isn’t about the skills; it’s about the practice.

Shuhari tells us that practice and practicing are important for knowledge work roles like product management where there is always more to learn.

Shuhari tells us product managers to get the reps in if we want to be better product managers.

Jukesie wrote The unProduct Person, which poses some interesting questions about the current state of product management and its focus on frameworks. It made me think a bit more deeply about what I think about some of those points.

I think the need for people to ‘professionalise’ the craft of product management, to make it a definable thing, to demonstrate how important it is and how ‘scientific’ it is has been to its detriment. 

The discipline/function/profession of product management is still very new/emerging, it doesn’t have regulations to pin it down like finance does, it has been at the forefront of the internet-era disruption/transformation (along with lots of other roles), and it works with intangible things in messy spaces. These four factors (along with many more, I’m sure) make for shaky ground to grow in. But I’m ok with that. I think the answer is to get better at dealing with uncertainty, not go looking for certainty. So, I think I agree about not needing to ‘professionalise’ (whatever that might mean) product management any time soon. More time for emergence required.

Personally, I definitely identify with using a certain way of thinking to approach certain types of problems more than I identify with the job title and ‘more professionalism’ isn’t going to change that.

To me, product management is fundamentally a scientific pursuit. It uses the scientific method in an organisational context. I think the future of product management is in using more systems-thinking approaches rooted in synthesis and how things connect in complex systems, but for now we are where we are, so the scientific method with it’s reductive analysis is good enough.

OKRs are one of the big faultlines for me. While I don’t intrinsically think they are a bad thing – and there is definitely evidence they have been successful and useful places – I just don’t believe the juice is worth the squeeze in the vast majority of cases

I agree that the OKR juice isn’t worth the squeeze. It’s easy to spend more time and effort aligning the OKRs than OKRs provide alignment for teams. This isn’t OKR’s fault – it’s bureaucracy and hierarchy’s fault.

The pursuit of excellence in and mastery of the growing number of frameworks and models for product people seems to have overwhelmed the more foundational principles of product practice.

Another thing I agree with. A focus on frameworks does get in the way of understanding and applying the foundations of product practice. I’ve seen it happen. But maybe you can only see it from Ri. If you’re at Shu, then you have to learn the rules before you can break them, and that means learning frameworks. So the best thing a person at Ri can do is help those at Shu to learn and practice and progress as quickly as possible. Get the reps in.

Being focused on delivering valuable outcomes, articulating and holding tight to a vision, owning the hard decisions/trade-offs in pursuit of that vision, being the ‘glue’ to help teams achieve…and doing all of this by influencing without authority. It is a facilitation and influencing role

This is a yes and no for me. Yes, because those things are what product managers have to do, no, because the only reason they have to do them is because of how organisations are set up, who has power, how information flows, etc. If organisations were different, product managers wouldn’t have to do those things. Product managers only have to do glue work because there are forces trying to pull people in different directions. Those things might not seem so foundational to the role if the organisation changed, which tells us they probably aren’t that foundational now.

I’d rather Product people learned more about policy and service design, data science, DevOps, programme management or data protection than attend another Product specific training course. I truly believe the path to making the most effective contribution possible is that of the path of the generalist. Breadth not depth. Empathy for many professions more than narrow expertise in one.

Definitely agree that product people should be generalists, and S-shaped too. Not only do they need a broad range of knowledge but they need to be curious and know how to learn quickly too.

So, there’s a lot I can agree with in Jukesie’s post, but does it make me an unProduct Person? I don’t think so. For me, “avoiding hierarchy and being flexible and open to new ideas and ways of operating” describes the Ri of product management (and I intentionally avoid using the word ‘maturity’ there because it’s infantalising and reinforces existing power structures). Ri is a good place to be. Hope I get there one day.

When the traffic lights stop working, traffic still flows. Some drivers go for, some are a little hesitant, but they all know the rules so they figure it out. Traffic flows more quickly because drivers don’t have to wait for an artificially created gap in the flow, if they see a naturally occurring gap, they go.

That is, until it doesn’t flow. When one of those drivers gets it wrong and causes an accident, it all grids to a halt.

Traffic lights bring greater safety at the expense of the flow of traffic (at that location at least. Good traffic lights design should prevent longer delays elsewhere). They work this way because safety is prioritised over the speed of flow. So what if lots of drivers have to wait a few seconds as long as that one driver who might have otherwise been in an accident doesn’t get hurt.

That’s why the “flow” part of “fast flow of work” is so important. Traffic make things slower but make the flow safer and more reliable.

I’ve been doing product management in the charity sector for ten years. So, as I leave the sector, I thought I’d reflect on that time. I’ve been lucky enough to work on products that changed lives, made millions of pounds, and that failed. I met amazing people, and I hope I helped a few of them. I definitely learned from them. And I certainly had a lot of fun along the way.

When I started working in charities, I worked on ecommerce products. It was a great introduction to managing products because I had a lot of responsibility for making the business successful. I didn’t only manage the ecommerce website, I did market research, sourced merchandise, answered customer service queries, recruited new team members, managed the relationship with the warehouse, and liaised with the marketing team. I had responsibility for the end-to-end value stream. I was lucky to be given the autonomy many charity product managers dream of.

Since then I’ve worked on all kinds of products; websites, customer service and logistics, fundraising, health behaviour change, volunteering, chatbots, and learning products. Looking back at these different products at different charities, I can see some of the same patterns occurring.

No one knows what product managers do

Even product managers struggle to explain what they do, so it’s understandable that others aren’t clear. This lack definition is good and bad. It can allow for flexibility in the role to meet organisational needs but often means products don’t get managed as well as they could.

To be effective in charities, product managers have to be the ultimate generalists. It isn’t enough to know agile methodologies and how to write requirements for developers. PMs have to know about laws and regulations, psychology and behaviour change, charity finance, design, commercial and fundraising, finance and budgeting, marketing, software testing and release management, delivery management, leading teams, user research, market analysis, supplier relationship management, strategy, security, data protection, and most importantly developing internet-era business models. They need to know about all these things to work with the experts in those areas, and to fill the gap if there’s no expert available. That’s the good thing about not having a single clear definition that is applied consistently across all charities. It’s good for charities because they can hire someone with the skills they need. And it’s good for product managers because they can work on all kinds of different products and develop a broad set of skills.

I’ve seen leaders, who feel responsibility for a product, acting as product managers. They make the strategic decisions (often without the rigor a PM would bring) and tell others what to build. This is the bad thing about the lack of definition. It makes the role of the actual product manager too much about implementing technology to achieve someone else’s vision and strategy, just because that’s one of their skill sets that no one else on the team has. This is the usual issue of product managers working as project managers or tech support. If leaders understood what product managers can bring and how to work more collaboratively with them to set goals, explore problems and define solutions, the charity would get better products which achieve better outcomes and more impact.

Too much looking inward

Connected to no one knowing what product managers do, is product managers focusing too much on process within the organisation. When we do this (and I’ve done plenty of it myself), we set ourselves up as being internal-facing rather than focused on the people we’re trying to help and what the change we create could look like.

It’s hard to claim PMs can bring more value if we aren’t doing the things that bring that value. It’s hard to help others understand how technology at scale can create change or what internet-era business models for a charity could look like if we spend too much time on low value activities like what the roadmap should look like or what prioritisation framework should we use.

In more mature product organisations, the ‘product trio’ of product manager, tech and ux/design is a good way to structure a team. In less product-oriented organisations like charities, I think the duo of product and delivery works better. Product management focuses on outward looking things like market analysis, user adoption, etc., and delivery management focuses on internal things like helping the team work better together, stakeholder involvement, etc.

When product managers aren’t spending their time on internal facing activities, they can bring the value of looking outwards. More experiments. More speaking to users. More understanding the wider context and the forces that affect the people with the problems you’re trying to tackle. More developing internet-era business models. More focus on outcomes and impact.

Wicked problem solvers

Charities tackle wicked problems. But they haven’t yet figured out how to use technology to tackle them. We know from numerous examples in the commercial sector that tech at scale can have a profound effect on our society. But charities haven’t realised they can too, so instead they rely on the tried and tested methods of campaigning and advocacy to create change.

This means that charities tend to look at digital products as merely more modern ways of doing what they’ve always done. Things like taking donations, applying for jobs or volunteering opportunities, communicating, etc., can be done using technology, and so charities focus their product managers on these. This means product managers act as a conduit between stakeholders and developers, collecting requirements and project managing changes to the systems. Marty Cagan wrote about this ‘IT mindset’ back in 2014 (when I was getting started) and it’s still mostly true in charities in 2024.

But product managers and digital technologies have so much more to offer. Figuring out how to use tech and data in responsible ways to intervene in complex social systems to create intentional change is a far better use of the product manager’s skill set and mindset. If Uber can use technology to change how we travel and Spotify can change how we listen to music, then charities can use technology to make the world a better place.

What I hope the next ten years looks like

I firmly believe technology has the potential to create change at scale for all kinds of wicked problems affecting the world, and I hope charities embrace the opportunities it provides. And I hope product managers are instrumental in helping charities understand this opportunity and make the most of it. To do so, the value product managers bring will need better definition, product managers will have to develop their outward-facing knowledge and skills, and charities will have to explore and experiment ways of using technology.

72% of respondents to my LinkedIn poll think that if I do four hours of work over four weeks, then the work takes four weeks, not four hours.

Of course, both are true. It just depends on what you mean when you say “work”. And that’s what makes talking about deadlines and estimates and the time work takes so difficult.

But, is it ever possible to talk about work, and delivery, and value without also talking about time?

As part of my goal of being even more minimalist this year, I’m going to try to live out of two 35 litre bags.

Clothing

• Hat – Warm hat
• Shell jacket
• Down jacket
• Waterproof jacket
• Fleece jacket
• Shirt x3
• T-shirt x3
• Jean x3
• Shorts x3
• Socks x3
• Trainers
• Belt

Ditch pack

• Passport
• Bank card
• Driving licence
• Cash
• Hard drive
• Spare car key

Wash kit

• Tooth brush
• Tooth paste
• Towel
• Flannel
• Shower gel
• Nail clippers
• Deordorant
• Moisturiser
• Hair trimmer
• Scissors

Tech

• Work laptop
• Work laptop charger
• Surface laptop
• Surface charger
• Phone
• USB to USB-C cable
• USB-C to USB-C cable
• Kindle
• Backup phone
• Wall plug
• Battery pack
• Wired earphones

Personal

• Glasses x2
• Sunglasses
• Swiss army knife
• Car keys
• Window tool
• Pen
• Notebook
• Headtorch

We pretty much agree it’s not right to refer to people as resources (or at least we should). It’s disrespectful and dehumanising. It smacks of an outdated industrial mindset where people were thought of as interchangeable cogs in the machine, easily replaced by the next person in line.

So, in avoiding that problematic term, we seem to have replaced in with the term ‘capacity’. What does that mean? Is it just a different term for the same kind of thinking or is it something different?

When we say ‘capacity’, we often mean it as short-hand for ‘who does what work when’. If we take the definition of capacity as ‘the maximum amount something can contain’, then when we say, “the team is at full capacity this month”, we mean that a group of people (who) are already doing all the work they can in the time they have available. We think of the ‘who’ and the ‘what’ as fixed (throwback from the industrial mindset) and the ‘when’ as the variable. “The team might have more capacity next month”, means we expect them to have more time next month and the work they couldn’t fit in this month will have to wait till then.

But in modern digital work all those things are variable. Not just when, but who and what too.

Who might be on the cross-functional team could change, but also what skills, knowledge, time, processes and environments the people might have could also change. These things vary depending on the work. A developer using a new language and unfamiliar systems to what they are highly-skilled in will take longer.

What the work involves also changes. Understanding the work, doing the work of figuring out how to do the work, realising the problem the team thought they were tackling turns out not to be the real problem, doing the work of coordinating the work. It all has to be done. And it all changes with each new piece of work. Even the same work changes as a team gets more practiced at doing it.

What gets in the way of the work also deserves a special mention. Teams doing one piece of work that takes four days or four pieces of work that take a day each is taking the same amount of time, but in latter the work-in-progress is much higher. That’s four times the coordination required, four times the dependencies, four times the context switching, four times the amount of knowledge people have to keep in their heads. Not having the right tools or systems necessary for the work also gets in the way.

To help us understand these variables we can think about them on a sliding scale.

• What – the type of work ranges from delivering known, fixed, repeatable outputs… to… achieving uncertain, novel outcomes.
• What gets in the way – the amount of work-in-progress ranges from low, where the team can focus on one piece of work at a time… to… high, where the team has lots of distracting priorities.
• Who – the people on the team range from highly-skilled, knowledgeable, have the right processes in place, etc., for the type of work … to… learning (either because they are inexperienced and haven’t developed yet or because the type of work is uncertain and new to them), setting things up, improving practices and processes.

The more we’re on the right of the scales, the more impossible it is to estimate team capacity, and in fact, the more meaningless the term becomes. We should accept that.

When we have conversations about team capacity, it’s useful for us to be clear about why we’re having those conversations, what question are we really asking. Sometimes, when we ask, “how much capacity does the team have next month”, we’re really asking, “can the team do x work next month”. That changes it from a capacity conversation to a prioritisation conversation (which isn’t necessarily any easier, but there you go).

But where this becomes really useful is in changing the conversation from ‘capacity’ to ‘ability’, from how much can the team do, to how do we help them be more able to do different things better. How do we help team’s improve on their ability to achieve uncertain or novel outcomes, to drive down their work-in-progress limit, to learn new things, to work at a sustainable pace?

We’ve gone from harmful assumptions about resource utilisation, to understanding how the variability of digital work makes capacity a meaningless term, to talking about improving a team’s ability to do good work. This is where the impactful value is for teams, leaders and organisations, not in making sure everyone is always busy or in guessing when a piece of work will be done, but continually improving team ability.

Within product teams and for leaders, which date matters tells us whether the focus is on outputs or outcomes.

If when a piece of work is available to users is the date that matters, then we’re focusing on outputs.

If when we have enough data to know if the work has achieved what we wanted is the date that matters, then we’re focusing on outcomes.

I’m not sure about the saying, “If all you have is a hammer, everything looks like a nail”.

Even if you only have a hammer you still recognise the difference between a nail, a screw and a bolt. You know you can use your hammer pretty effectively on nails. You know using it on screws is going to be messy but might kind of work. And you know your hammer definitely isn’t going to work on bolts.

So, only having a hammer limits the problems you choose to tackle, it doesn’t mean you tackle them all in the same way.

Maybe the saying should be, “If all you have is a hammer, go find the nails that need knocking in”.