We should be selling our products as enablers, by that i mean; how can we level-up our customers through using our product and help them achieve their goals quicker?
Having worked within start-ups and scale-ups teams before, I can totally relate to the clouded judgement that can come into play when figuring out what to do, and what direction to take things. Product teams can easily get distracted by what they you are building instead of why you are building it. You get excited, carried away at the possibilities of what the product could do, without validating or actually understanding why or how your users might use it in their lives.
It's no surprise that over 42% of startups fail due to no market need. When we are focusing on what to build and the new shiny feature that will be available, we loose sight of who we are building for and what their goals and needs are.
Asking the right questions to uncover motivations
A great way to start getting you and your team into the mindset of outcomes over features is by introducing the Jobs to be done (JTBD) framework. You can use this Framework to focus on what your customer wants to accomplish, rather than the tools or features they require to get there.
Professor Clayton Christensen who introduced the theory explains that people "hire" different products or services to do "jobs" they need to get done. Therefore understanding these motivations is key to why some products succeed and why some fail.
The framework focuses on the three different areas which are:
The Situation "When"
The Motivation "Want/Would like"
The Expected Outcome "So I can"
The Milkshake Mystery using JTBD
Real world examples are helpful in understanding the power that this framework can have when building products. Christensen has a great example of how McDonalds tried to increase sales of their milkshakes, and started by asking their target audience focusing on their needs "how would you improve this milkshake?" their answers were clear, but had no effect on sales.
So instead, they used the JTBD framework, and ethnographic studies, observing their users as they came in and ordered milkshakes. This time instead of asking them how they'd improve the milkshake, they focused on the on outcomes and jobs their customers were trying to achieve. They asked customers "What job were you trying to do for yourself that caused you to come here and hire that milkshake?”
The results? Over half the milkshakes were sold before 8 o'clock in the morning, they were bought alone and they all drove off with it. They all had the same job to get done that morning which was they had a long drive to work and needed something to do to keep the commute interesting.
"Let me tell you when I hire this milkshake it is so viscous that it easily takes me 20 minutes to suck it up through that thin little straw. Who cares what the ingredients are — I don’t. All I know is I’m full all morning and it fits right here in my cupholder."
How public roadmaps can help validate solutions from ideas
So now you know how to find out what your customers are trying to achieve, how can you find which is the most important to them?
The issue with many product roadmaps is that they focus on a long list of features that are spread along a timeline, which therefore create commitment to the business and put pressure on teams to deliver them. The fundamental flaw here is that they are focusing on delivering an output for the product rather than the outcome for the business and its customers. The commitment towards these features can sometimes also cause teams to become drowned and not able to react quickly towards changing user needs, competition or even the market.
Engage your users in your public roadmap
A great way of finding what should fit on your roadmap is by making it public. Customers love being let in on a secret! Transparency builds trust and once they know what you're working on they want to actively be involved and let you know what they think.
If your customers are involved by suggesting new features and getting their insight into what you are building you're building a product for them, rather than your team. This also massively reduces risk along the way as you know those customers are going to a) be super excited when their recommended feature launches and b) want to use your product even more.
A great example of a public roadmap is Front's Trello roadmap. The voting and commenting is a great way to see what people are discussing and engaging with about your product features. Front even point out themselves that:
"The public roadmap has already helped us collect valuable feedback — e.g. the native iPhone app was far more urgent than we anticipated, and 4 times more requested than the Android app: we instantly added it to our next product cycle"
Sell your product as an enabler
But it doesn't stop when you start selling. Always start with the problem first - getting teams to focus on this is far more empowering and unlocks different levels of creativity than dictating the solution from the outset. An approach I always take to these types of projects is, whilst this may be the desired state - how did we get here? Try to rewind your thinking and start from scratch.
When developing a new feature, the first question you should be asking is, “What will people be doing differently as a result of this feature?”. You can also validate this with user to uncover these motivations too. Running exploratory user interviews will help you understand your users motivations and start talking about what their desired outcomes are.
Growth requires outcome driven projects
Different projects require different methods and Intercom has a nice table showing the characteristics of a feature-driven project over an outcome-driven project. There's still merit towards feature-driven projects but one thing both of them share is how key it is for them to be driven by customer problems first.
An outcome-driven mindset
In summary, the best way to start adopting an outcome-driven mindset is to start by asking yourself the right questions to re-frame you and your teams ways of thinking, this can be aided by using frameworks such as Jobs to Be Done.
Then focus on your ways of working, how can you improve the current processes that are leading to a feature-driven approach? We've shown one approach in this article which is the public roadmap but there are many more ways you can achieve this.
Finally, selling your product as an enabler and starting with the problem first. This is ultimately what is going to drive growth for your business and using research to uncover your users motivations is a powerful method of achieving this.
🤔 Are you interested in exploring this approach in more detail? I can help you get there quicker. Book a discovery call today and we can chat about how your product could benefit from an outcome-driven approach.