Discovery, at the product level, makes a lot of sense. You need to figure out exactly what product needs to be built, so that you build something that will hit a sweet spot for your customer. However, what that customer cares about is NOT your product. It's the outcome your product helps them achieve. Outcomes are clearest in a B2B context. Almost all enterprise sales are driven by 4 factors: increasing revenues, decreased cost, decreased risk, or improved customer experience. For consumers, this isn't always clear cut. In many cases, though, there are specific objectives the customer is trying to achieve.
And yet, discovering client or stakeholder ideal outcomes is more important than discovering products. It might sound like an academic distinction that has little practical meaning. But actually shifting from products to outcomes is the most important step in moving from a "my company" focus to a "customer-centric" focus. Because a product is still something that only you and your team cares about. An outcome is the main thing your customer cares about.
Instead, I think the core learning process my team goes through is how to achieve specific business outcomes for specific people as quickly as possible. Usually this is a case of being laser focussed on only what must be shipped first in order to achieve those outcomes.
All other ideas are added to the backlog and delayed until after the immediate next release. Any time spent analyzing them, developing them, testing them, or reporting on them delays your current release. And your highest priority outcome. Counterintuitively, this includes longer term activities like planning, estimation, or budgeting.
If you allow all of these other features to creep into your release, you are delaying the possibility of achieving your customer's outcome. And your customer has to achieve their outcome before you can achieve yours. That is the true total cost of incrementally adding the extra features. Not just the extra product team time (regardless of how much more time it does require).
The fact of the matter is that it's not worth aligning around big laundry lists of features that go into a release. Because it then becomes a case of pork barrel politics in favor of individual stakeholders in a larger company. If that is going on, the main goal or outcome of a release is already difficult to see. And everyone wants to get in their piece of pork.
When do you know you have a useful outcome?
Let's say you have 200 possible features you can build and ship. Of that 200, you can combine them into subsets that achieve a particular benefit for one or more clients. These clients can be external or internal. So the goal of a release is to make that subset small enough to make an impact for at least one person. Possibly a few people. Or one client.
1. A Specific Person, Company, or Role in a Narrow Market Segment
You have one specific person or at least persona in mind. You can use the Hero Canvas, or not, doesn't matter. But it's important to frame discussions of value around people impacted.
Having a specific person in mind grounds your effort. Most of the meaning around products will be based on how they impact your customer's lives. How it plays into the stories they already tell themselves about their struggles and efforts.
Also, by choosing a specific persona or person, you choose an angle or perspective. Similar to the Copernican revolution, you "choose your sun". This is what gives life to your business, not the other way around.
New technologies can be applied in a number of different markets or segments. And the details will vary widely based on which segment you choose. For example, you invent a way for drones to collaborate autonomously. This invention can be used in agriculture, military, construction, oil exploration, or games. In each case, it's the same base technology, but you will prioritize different first features for each one as you productize the technology for each application in each segment. Without targeting a specific market, all you have is a clever invention.
2. Their success metric
You have an understanding of their motivations, metrics, and how they define their own success. Again this is often clearer in a B2B context. Here's an example of different metrics with an HR department:
The problem [our failed startup] set out to tackle, reducing turnover and improving new hire performance, was felt acutely by our buyers (CHROs / Heads of Talent). It was NOT felt acutely by our users (recruiters). Recruiters are measured against average time-to-hire, not new hire retention or performance. We were trying to improve outcomes about which users would pay lip service, but which didn’t impact their paychecks or promotions. --Sam Stone of @ansarotech
By choosing a person or group of people, they will be measuring themselves against particular metrics, such as the average time-to-hire for recruiters. By helping that person with that metric, you improve their life. Provide value. Whether you do that with a product, service, article, app, or anything else doesn't really matter to them. It matters a lot to you. But to you only.
3. No side effects
You aren't causing unintended side effects that matter to that person. To counter-balance the previous point, if you significantly do improve one metric but damage something else that matters to that person, then they won't be interested.
Let's say your product speeds up the average time to hire for recruiters, but it requires that they work 12 hours days in order to achieve that outcome. In particular, they need to stay at work for 4 extra hours per day, to maintain the information about candidates in your SaaS app. For many recruiters, this will be an unacceptable side effect, as they will have to sacrifice family time also, in order to achieve the outcome.
4. Easy to execute or confirm
If you are at a validation stage, it should be easy to validate what the outcomes are by talking to those customers.
If you are already building product, this implies you have built your product in a way that is cheap to release. In the software case, this means you are using a lot of automated software testing. So you are sure of exactly what is in the product and what is working. And you can release as soon as all of your tests pass. Better to commit to fewer features, but only release ones that work.
If you are in a big company, it should be easy to get alignment around a particular outcome. There can be multiple conflicting agendas of the stakeholders, and it may be difficult to agree what the intended outcome is. Figuring this out takes time, but it's still relatively the fastest path to the outcome, if you want to work sustainably.
The challenge with outcome discovery is often that the #1 or #2 are unclear. And after they become initially clear, they often change.
Case Study
Sometimes you discover a smaller, nearer term outcome that helps align everyone as an incremental step. For example, in an enterprise software case, it can be worth helping a different stakeholder in the shorter term.
Giving a salesperson something to demo, before delivering an initial release only directly to a client. The salesperson has a lower bar. She only needs to build a picture and narrative around the product. She don't need it to be fully functional, taking care of all edge cases and side effects.
What if my releases require Herculean efforts?
Release scopes need to be as small as possible, and organized around specific outcomes which you are trying to achieve. Because this means it gets out to customers faster. And you achieve the outcomes faster.
If releases are really big, then quite possibly, that's the most productive outcome you need to address. It makes more sense to streamline your existing processes, before it's even worth looking at creating new products. If you don't streamline first, you'll create resource locks among partially finished and unreleased products all over the place.
Actual time frames will vary significantly by industry. A good general rule of thumb nowadays is a maximum of a month, for any product that doesn't have a manufacturing component. For example, you're unlikely to be able to build an oil tanker in a month. But you could come up with a design prototype for one in a month.
Why discovering outcomes first matters even more than discovering product
The person being helped decides whether your help was valuable. It doesn't matter how much effort or resources or blood you lost, if it's not relevant to your target customer. Usually, product teams don't spend nearly enough time to getting deep enough into the customer's world. They don't need to at first, but at that point they are relying a lot more on luck than they care to admit. Taking beta they don't need to. Even using the word product already pre-supposes a solution. Namely, that it's a product. As opposed to a number of other solutions, like a service.
Key Takeaways
- True outcome discovery and alignment is even more valuable than product discovery at an early stage.
- Outcomes focus you on people for whom you want to create an impact, as this will ultimately drive your success.
- A well-chosen outcome needs: a clear person affected, a metric they use to evaluate the outcome, no side effects, and easy and clear path to execution
Next Steps
Get details of my hero canvas course over here, to help you narrow your focus on the outcomes your customers and users care about.