Three W’s and an H for Product Management
Retrospectives are some of the most useful ceremonies in agile software delivery. The team meets, identifies assumptions that led them astray and explores the origins of those assumptions.
One theme that emerged in many of my teams’ retros was wrong assumptions about the purpose of a feature. Either the whole development team had a different view of the purpose of a feature than stakeholders and end users, or the team had built the feature with conflicting assumptions about its purpose. As we inspect the result in our increment review, we often decide on costly and time-consuming rework.
While our teams strive towards a development cycle where each team member understands the purpose of what they are building end-to-end, that’s kind of an ideal which is really hard to reach. As we’re iterating our way towards that ideal, I found myself recommending four steps in the feature development cycle to my teams: Why, What, How, and When. Those are conceptual steps which can be used as rough guidance — there’s no timeframe, no roles, and no strict ceremonies attached to them. If you’re tackling a very simple problem, you might go through all four steps in a day or so. For more complex problems, each step might take you significant effort though.
As you’re working your way through the four steps, you might find inconsistencies or omissions along the way. It’s totally acceptable to pause and go back a step. However, you shouldn’t skip any of the steps as you move along.
Step 1: Why
‘Why’ is one of the first questions my four year old god daughter asks me — regardless of the subject. She’s right in doing so, because understanding the reasons behind a request or a problem helps you weigh possible solutions. In our teams we call the answer to this question ‘End user problem’. Ideally this is still open-ended, and it is focused on the end user of the software we’re building. In some cases it might make sense to have a related or separate ‘business problem’.
Twitter lately faced the business problem ‘we are too reliant on advertising revenue.’ Their first attempt at solving this problem, Twitter Blue, created an end user problem, which was ‘I don’t know which accounts are real and which are fake.’
Understanding the underlying problem is a crucial prerequisite to even starting to think about possible solutions.
Step 2: What
When you understand the problem an end user faces, you can start to think about solutions. Rather than jumping to specific remedies (be patient, we’ll get to the ‘How’), it is sensible to first think about criteria that your solution should meet in order to solve the problem. Ask yourself: ‘What needs to be true for a possible solution to be accepted by the end user?’
In our product teams we call the answer to this question ‘business acceptance criteria’. We use the term business even though it might lead us away from focusing on the end user. The goal of terminology here is to stress that we’re not thinking about technical solutions yet — we’re merely gathering criteria for any possible solution. If you have better naming ideas, I encourage you to drop them in the comments :-).
Asking ‘What’ has two main benefits: First, it keeps your mind open to all sorts of possible solutions. You don’t narrow your search down to one solution which might turn out to be expensive or has other downsides. Second, it gives you a good basis for agreement with stakeholders. If you can agree with them on what a solution should deliver, you have a basis to go back to them at later stages to check delivery and validate assumptions.
In our Twitter example, criteria for a solution to the end user problem might be ‘a solution needs to give users a clear indication whether an account is real’, ‘a solution needs to be recognisable at a glance’, ‘a solution needs to be accessible to all real users’, and ‘a solution needs to protect Twitter’s interest in diversifying their income’.
Step 3: How
Equipped with a shared understanding of the underlying problem and a set of criteria for possible solutions, your team can now start to develop actual ways to solve the problem. In this case it might be a good idea to start broad and narrow down your candidates.
Starting with multiple possible solutions, maybe testing a few with actual end users, helps you validate your assumptions about the problem or your criteria with small investment early in the process. At this point you might want to revisit steps 1 and 2 and capture your new-found understanding.
Ideally all of your solution candidates meet the list of criteria from step 2. However, they might differ in other ways which are important to your project, like cost (of building, maintaining, and iterating on your feature), implementation time, dependencies, etc. Having a clear, prioritized understanding of those feature-independent criteria helps you pick the right candidate.
As our teams start implementation, I would recommend to only know enough about the how to get started. When our teams rush, they normally skip step 1 or 2 — when they delay, it’s usually because they overthink the how before they get into implementation.
If you’re asking ‘but what about big complex solutions?’ I recommend Allen Holub’s concept of ‘narrowing the scope’.
Going back to Twitter, one solution might be for accounts to get badges, but to separate those badges from verifications. One weakness of this solution might be that it does not provide a clear revenue advantage — why should an end user pay for a badge? What might be other possible solutions?
Step 4: When
The question when is the easiest and the hardest to answer. At the start I mainly had it in my list because I wanted to showcase that only after you’ve gone through steps 1 to 3, you can start thinking about the timeline for delivery of a feature. Of course, that doesn’t answer the question though.
Ideally, by the time you arrive at when, you already have a good idea of the impact of the problem you’re trying to solve, you agreed with stakeholders on criteria for your solution, and you know enough about solution to get started. When to start your delivery mainly depends on when your solution is the most valuable thing you can implement. I’ve written about the concept of value in more detail in this story.
Going back to how often helps our teams get closer to the answer to when. Ideally we narrow the scope of a solution to what one of our teams can deliver in one sprint. In practice this is really hard, especially when you start out with a new platform. Taking the effort to narrow the scope of your solution without compromising on the end user problem pays back in shorter timelines and reduced uncertainty of delivery though.
Our friends at Twitter might conclude that this is the most valuable end user problem to solve right now. They might come up with a narrow enough solution that can be implemented in one sprint, so they might say start delivery immediately.
Where Three W’s and an H help our teams
While any software delivery team dreams of building for end users only, in reality stakeholder requests are much more immediate and affect out day-to-day life more directly than end-user needs. End users usually just leave and spend their money at your competitors — your sales teams and management stick around and have access to your DMs, which is much more annoying ;-).
In our teams we find that stakeholders rarely come with refined answers to why and what. Usually they have a half-baked answer to how and a very specific expectation of when. More often than not, my teams found themselves in negotiations on steps 3 and 4 — with no shared understanding of steps 1 and 2. Even if they managed to satify stakeholders’ expectations of when, those stakeholders would be unhappy with the delivered solution because it did not meet the implicit what.
Going back to the framework of the three W’s and an H helps my teams to focus their discussions on the why and the what first. This generally results in more meaningful conversations and a shared understanding of what we’re trying to achieve and how we perceive value in this context. As a result, our scrum teams get more freedom in looking for a good solution that meets the feature-agnostic criteria of our program as well as possible. Also, we encounter more understanding from stakeholders on prioritisation and timelines.