Category: Blog

Or in plan language: talk to each other, work together, be helpful, check things are going ok.

These are my four principles for team work.

Communicate

Communication doesn’t mean one-way information from those in the know, and communication doesn’t happen well when intermediaries (especially software tools) get in between people. Talking to each other is the best way to communicate.

Collaborate

Collaboration means working together to achieve the same goals, not working on different things separately or with different goals. Lots of work gets done in isolation. The best work gets done in collaboration.

Contribute

In some teams, everyone has specific roles and responsibilities. They all know what they do and they only do that. But in better teams, people use the breadth of their knowledge, skills and expertise to contribute, even if it isn’t in their job description. Being helpful makes a big difference in how teams work. Sharing knowledge, offering to chat, making introductions, taking on tasks when someone is busy, it all makes the difference between being a group of individuals and a team.

Coordinate

Coordinate used to mean centralised upfront planning and giving people instructions to follow, make sure they’re doing the right things and staying on track. Now it means looking for signals about what’s happening, what has changed and responding in real time. That’s why checking-in with each other is so important. If one person shifts their focus, maybe it’s a signal they know something the rest of the team don’t. But if everyone notices they can check that they all still have the same understanding of what the team should be focused on.

So, teams can use ticketing systems, have separate goals, stick to their roles, and plan ahead if you want, but they’ll probably do better if they talk to each other, work together, be helpful, and check things are going ok.

I used to think that you’d notice blame culture by seeing people punished for mistakes. And, that a culture of blame is wrong because no individual is ever solely responsible for a mistake because we all work within complex systems.

Now I realise that a culture of blame is much more subtle.

Blame culture exists when people feel like they have to explain their actions, and always their failings, as caused by something outside of themselves. This thing happened because that person didn’t do something, they say. Or some other thing didn’t happen because that’s just how it is around here. None of this was caused by my actions, they suggest. That is a culture of blame.

The opposite of a culture of blame isn’t a culture of accepting mistakes, it’s a culture of accepting responsibility. You can see the absence of a culture of blame in the sense of agency people have. When people show initiative and take risks, when they approach problems with ways they can contribute to solving them, when they take control of things within their influence, that’s when there is no culture of blame.

What do you believe about how the world works? Do you believe it works like a machine, that a cause always leads to an effect and that makes the world predictable? Or do believe it works in random ways, where sometimes a cause doesn’t have the expected effect and sometimes effects appear from unknown causes, that the way the world works is unpredictable and emergent.

These two opposite ways of seeing the world are often so deeply rooted that we don’t recognise them, but they matter. They matter when we run organisations the way we see the world. And they matter when we try to apply tools and techniques in our organisations. Our tools and techniques fit with one or the worldview, and they aren’t interchangeable.

Tools & techniques for a predictable worldview	Tools & techniques for an emergent worldview
Linear/waterfall process. Upfront planning. Targets. Outputs. Gannt charts.	Agile. Thinking in bets. OKR’s. Outcomes. Now, next, later roadmap.

Predictable worldview tools and techniques make sense if you believe in a predictable world. Emergent worldview tools and techniques make sense if you believe in an unpredictable world. Using the wrong tools for the worldview doesn’t make sense.

So, when people say things like, “agile failed”, maybe the problem is trying to apply emergent tools in an organisation with a predictable view of how the world works.

Two additions to this version of my thoughts on creating simple product strategies:

• Strategies, plural. Not one big strategy, but lots of small simple strategies that make it easier to figure out what’s working.
• Capabilities to solve the problem. Thanks to Ian for this addition. He’s right, a strategy without the ability to deliver on it is useless.

So, four parts to simple strategies.

1. A worthwhile problem to solve
2. A hypothesis about how to solve the problem
3. The capabilities to solve the problem
4. 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.

The capabilities to solve the problem

The product manager has to match what to build with whether the team can build it. Working with the team to figure out what they can build, they test feasibility. Not just feasibility for the technology, but compliance, security, accessibility, etc., to know the organisation and team has everything it needs 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.

Next… an example.

Product management and service design can complement each other and create better products/services because of it. But because both roles are pretty flexible, generalist roles, there’s lots of room for misunderstanding. To work well together, both people have to fill that room with understanding.

How not to work together

Sometimes, when two people from different disciplines start working together, they get stuck into the work without taking the time to figure out how they should work together.

In an attempt to tackle the confusion and misunderstanding this creates, we often try to define how product people and service design people should work together, which gets into trying to define terms like ‘product’ and ‘service’ as a way of drawing boundaries of responsibility and make sure people stay in their lanes.

I don’t think this is the right approach.

We aren’t trying to systematise or scale the relationship, we’re trying to nurture it. So, avoid to temptation to define things like ‘product’ and ‘service’. It becomes a purely theoretical exercise and won’t improve the relationship between product managers and service designers.

Instead of treating each other as job titles we can treat each other as people with a broad range of perspectives, experiences and expertise. And then we develop the relationship necessary to work well together.

Building a partnership

We have to talk about how one individual product manager works with one individual service designer. That’s the only way to talk about building a partnership. It’s about how two people talk to each other, create the space for each other’s perspective, not how two job titles might work together in theory. But, it might help us understand each other’s perspective. Maybe it looks something like this:

• Service Designers merge a design methodology with a service orientation, Product Managers apply the scientific method and systems thinking in an organisational context.
• Service Designer are user-centred, product managers balance multiple perspectives.
• Service Designers deal with the relationships and interactions between tangible things, product managers deal with intangible and often unrelated things.
• Service Designers go deep, product managers go wide.
• Service Designers are usually involved with a service/product for a short period of time and are judged by their outputs, product managers are usually involved for a long time and are responsible for the quality and success.
• Service Designers work is mostly upfront, a product manager’s work is never finished, it’s about iteration and incremental change.

All of these are good things. Good partnerships are about recognising different perspectives, skills and experiences individuals bring. The solution for how people work well together is creating the space for conversations to understand each other.

Creating the space

The space we want to create is one where different perspectives are welcome and treated equally. It’s a psychologically safety space. It has a shared expectation that no one will embarrass, reject, or punish the other for sharing ideas, taking risks, or soliciting feedback.

The relationship between product manager and service designer should be:

• Mutually respectful of each other’s discipline, skills, expertise and expertise.
• Equal in power, or at least reducing the power distance.
• Supportive and encouraging.
• Aligned to what the work is trying to achieve.
• Understanding of the challenges the other faces.

These things are the basis for any good working relationship but it’s important to make them explicit as in many organisations there are implicit rules for things like how seniority is treated, and personalities can sometimes get in the way if one presents as more extroverted than another.

If it’s hard to say such things explicitly, user manuals for me, read me’s, etc., are a good place to start. But really, doing the hard work of creating a psychologically safe space for the partnership to live in will be worth it in the future. Spend time together, get to know each other.

Establishing who does what

Agreeing responsibilities should be straightforward as the roles are so different, but it rarely is. This can be because of organisational pressures, lack of clarity about roles, hidden agendas, etc., but also because we have all have different ideas about things.

The best answer to ‘who does what’ is to talk about it and agree responsibilities based on skills, experience, availability, etc.

If there are responsibilities that both think they should have, call it out. Discuss it.

Keeping the partnership going

Keeping working relationships positive and effective when everyone is under pressure and busy with getting the work done can be hard. It takes time and lots of effort.

A couple of tips for Product Managers to help Service Designers:

• Provide context – You’ll have knowledge of the wider context of the market, organisational goals, technical constraints, budget limitations, team skills, supplier relationships, etc., etc. Help the Service Designer understand how these things affect their work.
• Trust the expertise – Let the Service Designer do their thing. Give them the space to explore problems from their perspective and come up with solutions.

A couple of tips for Service Designers to help Product Managers:

• Presenting information – Product Managers have to switch between strategy and implementation, now and future, new and existing, creating and operationalising. Understanding this means you can provide them with the right level of information at the right time.
• Align thoughts – Product Managers think in experiments and work in iterations. This doesn’t always align with how a service might be designed. Think about how to bring those different ways together.

P.S. Talking to each other works for all roles. Even though some roles are better defined and have clearer responsibilities which make working together clearer, starting with a good relationship always makes working together easier.

Read more:

• Service designers and product managers: working together
• Service Design and Product – Andy Budd on The Product Experience

I can tell you everything you need to know about agile in three words.

The first sentence of the Agile Manifesto says it all. It says, “We are uncovering better ways…”. Those are the three most important words in the whole manifesto, or anything written about agile since. They tell us the essence of what it means to be agile.

Just three words:

• Uncovering – means finding out as we go, not thinking we can know it all upfront.
• Better – let’s us know we are always looking for improvements.
• Ways – tells us it’s a practice, it needs to be worked at repeatedly to make it successful.

Uncovering better ways… of doing anything… but especially…

Uncovering better ways to lead…

…is still emerging, and there’s lots to learn, but it probably means considering things like:

• Embracing change and uncertainty, not portraying false certainty.
• Involving people in creating vision and direction, not telling people what to do.
• Cultivating emotional intelligence, self-awareness and vulnerability, not ignoring the soft skills.
• Being a trusted thought-partner, not a teller of single truths.
• Practicing nonviolent communication, not giving orders.
• Bringing positive energy, not problems from above.
• Removing obstacles, not ignoring them.
• Creating the conditions for good work to happen, not focusing on process.
• Empowering and trusting other’s expertise, not thinking you know best.
• Using radical candor, not leaving issues unresolved.
• Encouraging intelligent failure, not blaming people for making mistakes.
• Coaching, supporting and challenging people, not leaving them to figure things out for themselves.
• Role modelling desired behaviour, not expecting others to be the ones to change.

Uncovering better ways to be a team…

…is best done by the people in the team and could include things like:

• Working together as one team, not working in silos and handing over work from one team to another.
• Having shared goals, not individual performance objectives and rewards.
• Knowing the user and their needs, not doing what stakeholders say.
• Reducing cognitive load, not being overwhelmed.
• Developing relationships, not letting things get in between us.
• Respecting different opinions, not following the loudest voice.
• Embracing diversity, not hiring for fit.
• Fostering psychological safety, not exerting power over others.
• Protecting wellbeing, not promoting heroics of putting the work first.

Uncovering better ways to organise work…

…has lots of potential and might include things like:

• Optimising for the flow of value, not for just getting work done.
• Limiting work in progress, not slowly working on many different things.
• Visualising work, not hiding it.
• Creating fast feedback loops, not planning everything upfront.
• Aiming for excellence, not letting quality slip.
• Pulling work to ourselves, not pushing it to others.
• Learning, not assuming we know all we need to.

All ways are continuous, things can always be better, and the uncovering is never finished.

I once worked with a team who each had individual performance objectives set with HR, and team objectives set by their manager, but their stakeholders judged them by what they delivered. They reported on long-standing KPI’s for their products but no one could remember who had set them and they weren’t used for decision-making. No one measured any outcomes.

Unsurprisingly, they didn’t know which measures mattered or how to be successful.

This isn’t an uncommon story. People often have multiple ways of being evaluated at work, and they often lack any kind of connectedness or coherence, and sometimes even conflict with each other. Once a year, managers take a guess at what an individual might be able to achieve over the next twelve months and set objectives accordingly.

There are better ways.

Let’s start by doing away with individual performance objectives.

Let individuals focus their efforts on achieving their team’s objectives. Individuals succeed when the team succeeds. However much an individual contributes to the team’s success, they can’t succeed unless the team does.

And… here’s the magic ingredient that helps the individual improve their performance faster than a manager with annual objectives: the team provides fast feedback that helps the individual course correct to meet the team’s expectations at that time and as they change.

If the individual gets and responds to fast feedback from the team, they have the maximum opportunity to improve. The feedback is humble, because the team understands the circumstances, helpful, because the team wants to the individual to succeed, and immediate, because everyone works together everyday. There is no need for measurement as a separate activity to inform and justify improvement. No need for quarterly or annual performance reviews that are distant from the work.

The role of the manager becomes one of coaching the individual to respond positively to the feedback, to use it to shape their behaviours towards what the team needs from them. Feedback from the team also helps individuals identify skills gaps in a way that individuals can’t for themselves, and which managers can help them to improve on. As they improve, so the team has a better chance of succeeding.

Team needs psychological safety to be able to give each other fast feedback in this way. But team’s need that anyway. And being able to give and receive feedback from each other helps to build psychological safety, so the two grow together.

If the team is the unit of delivery then it’s also the measure of success and the source of improvement.

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.