What sets a good product apart from a bad product isn’t necessarily the set of features it offers or mere aesthetics. It’s the ‘job’ of the product that matters to people, not the list of functions it performs. Here, we talk about the danger of ‘product requirements’.
We’ve all been there as product owners when talking about “product requirements”. However, “product requirements” can be a dangerous word. Let me explain.
Firstly, it’s “required” for whom and according to what criteria? How did we set those criteria in the first place? How did we define the success of that criteria…and so on?
Secondly, how did we validate that it’s actually based on real customer need? (or is it just a need that a stakeholder feels is what the customer needs?)
Enter the outcome-based approach (aka Jobs to Be Done theory). JTBD really cuts through all the noise around a set of features that don’t necessarily help customers achieve anything meaningful. When it comes to delivering value to both the customer and the business, we need to think hard about the outcomes that our target audience is trying to achieve and their surrounding context.
What do we mean by this? Let’s turn to our JTBD master, Harvard Business School professor, Clayton Christensen to understand the ‘job’ of a product – in other words, the outcomes customers are trying to achieve:
“We actually hire products to do things for us. And understanding what jobs we have in our lives for which we hire a product, is really the key to cracking this problem of motivating customers to buy what we’re offering.”
How customers experience life vs. How businesses think about the market: The milkshake example
Let’s take a real, fascinating example. Business wanted to increase their sales of milkshakes. They targeted what they thought was their most likely milkshake consumer and gave them samples. They believed that improving the product based on their feedback would result in them selling more milkshakes. i.e. More chocolatey, chewier, chunkier, cheaper…. However, when they went back and applied this feedback to their milkshakes, they were surprised to see no impact on sales whatsoever.
Someone wanted to approach the problem differently. They wondered what motivated the customers to have a milkshake in the first place? What job was the milkshake performing for them? Why were customers buying milkshakes? When did they do so? They stood outside the restaurant and captured real-time data. What they found was pretty amazing: They discovered a pattern — that is: “All customers who bought milkshake had a long and boring drive to work in the morning and they just needed something to keep the commute interesting for longer than any other drink or food” Says Christensen.
Here we go. This is the job of the milkshake it turns out: In the context of the drivers, its job is to help them keep their journey tasty and their tummies full before their breakfast at 10am. Who would have thought?
The bonus (and the deeper) lesson is that to your or my mind, a milkshake can be a competitor to a “Burger King” milkshake or any other type of milkshake for the matter, but in the customers’ minds, it’s competing against other snack foods such as bananas, bagels, doughnuts, Sneakers etc.!
To summarise so far:
- The way customers experience life is usually different than what businesses think of the market & competition.
- Even if it seems so on the surface, people don’t actually want features – they want their problem solved.
How does this help us?
When thinking about product requirements, it helps us to consider the customers’ context and the task/goals they’re trying to achieve. Once we nail the customer problem, then we start thinking about the solutions that are aligned with their outcomes. This is more likely to stick with them as we motivate them based on their functional (or indeed emotional) needs to use the solutions we offer – this sounds simple, but it takes time to uncover the real need. The answer is rigorous user testing and customer interviews.
Why does it matter?
- Product feature prioritisation becomes easier and crystal clean when the outcomes are unearthed and understood by the team and the stakeholders.
- It means you can focus on releases that help customers achieve a particular outcome, rather than a set of features that don’t necessarily help with any real need.
- It helps us think about a product’s emotional job (emotion need), not just functional ones. i.e. I’m thirsty and need a drink vs I need something to hold onto during my long, lonely and boring journey.
When we mentally flick the switch from features to outcomes and focus on the job of the product, we can apply this thinking in lots of different areas. We can start applying 5 whys when digging into a problem until we get to the root of it. Or we can start using job stories rather than user stories to empathise with customers better. These are just small examples for you to start embedding JTBD methodology. Perhaps in a separate upcoming post, we can dive into these.
Would you like to learn more about how JTBD methodology can be applied in your organisation? Contact us and we’ll share more about our product methodologies and how they’ve helped our roster of blue-chip and startup customers ask the right questions to get the digital product they need.