Great PMs Focus on Outcomes, NOT Outputs

So I recently finished the phenomenal book Escaping the Build Trap by Melissa Perri (see my in depth article here) and wanted to dig deeper into a Cornerstone Concept that Perri repeats over and over; namely, how can PMs and Product Development Teams focus on delivering Outcomes (aka real customer value) vs. Outputs (aka features).

Because tangible examples help with clarity, we’ll use one of my favorite products, Spotify, as an example.

Photo by Tim Mossholder on Unsplash

The Real Difference Between Outputs and Outcomes:

Defined simply:

Outputs are WHAT you build in your product and tied back to digitally tangible items. Things as small as a given button, or as large as a full feature set

Whereas

Outcomes are WHY you build any given thing into your product that tie back to delivering value and solving problems. Things like helping people find things on in your app or letting people stay organized.

Using Spotify’s search functionality as an example, some of the OUTPUTS would be:

• Have a search bar
• The returned list of results
• The backend indexing algorithm
• Saving recent search results

While some of the OUTCOMES would be

• Janice wants to find songs, artists, and albums easily (A facet of the overall search function value)
• Larry wants to explore and find new genres without knowing any specific song (a different facet of the search function)
• Laura does not do well with spelling but still wants to find the things she is looking for (need for smart interpretation of search terms)
• James wants to see lots of potential options for what they are looking for, but probably cares about the most popular results (how to return what is being searched for)
• Jin does not speak English (and doesn’t use English’s alphabet or script) and still wants to be able to find great audio easily (multi-language support both for search and for audio indexing)

NOTE: You ABSOLUTELY need to build things (outputs), but so many PMs fall into the cycle of of simply saying we need to have X without ever tying it back to REAL USER VALUE (this is essentially the entire focus of the book, obviously unpacked in much more detail).

Photo by Ross Findon on Unsplash

How To Change Your Perspective and Process:

So now we agree that Outcomes are what matter, how do you go about switching your mindset and process to stop just shipping features and instead deliver value?

Ask Why Does This Matter?

• This can be as big as small as you want it to be and should be a process question that is asked throughout the entire development process. You should ALWAYS have a strong answer, because if it doesn’t really matter, why are you building it?

Ask What Actual Problem are We Solving?

• This ties directly back to user value and makes it very easy to to determine what to build because it gives you a clear benchmark on if it actually solves anything. You should be able to look at any feature being added to the product and be able to say something like “Adding a search bar and function will enable Janice to find audio easily”. It acts as your litmus test throughout the entire build process.

Talk to Real Customers

• Personas are, by nature, fictitious, and they normally fit into a nice box. Real customers don’t. Which is why you need to talk to them. Watch how they use the product, uncover what is frustrating to them, ask them what they wish they could do, ask them what they love etc. All of these help inform the previous two changes to let you know what you should actually build, because you have a great read on WHO is using your product.

Align to Organizational Strategy

• Unfortunately, unless you are building a self-funded, passion product, you also need to align to and enable the overall organizational strategy. This can be any number of things like increasing bottom line profitability, decreasing churn, increasing the Total Addressable Market of the org etc. but for whatever you build, not only does it need to be solving real customer problems, it also must drive the company strategy, otherwise you will never get leadership buy-in.

Lead the Market

• This is mainly a significant perspective shift from REACTIVE product development to PROACTIVE product development. So many PMs are simply software waiters that react to what is being asked of them, rather being leaders that pioneer new paths. For whatever your product niche is, ask yourself what does it look like to lead the market in this area?

Analyze Your Data

• Lastly, use the data you are capturing to both validate your assumptions AND see if what you are delivering is adding value (i.e. customers are using it). Before anything ships, you should have measurable outcomes defined for what success of that value set looks like and ensure you have a way to accurately measure those outcomes.

NOTE: If you don’t have data, you need it. You should be able to measure everything, otherwise you are guessing blind and have no idea if anything you build is successful.

Photo by Towfiqu barbhuiya on Unsplash

Great Questions to Ask Yourself:

Finally, change starts with you. I’ve found that asking questions is the best path for personal growth and introspection, so below are 6 questions you can ask yourself about your PM process to see where you can improve.

1. How do we build the roadmap today?
2. How do we prioritize features today?
3. When was the last time I talked to and observed real customers?
4. What does the Data tell us?
5. What’s the next most valuable thing we can build?
6. What frustrates our customers the most?

Ultimately the best PMs never struggle with what to build or prioritize because they have spent time understanding their users and determining what delivers the most value for their customers.

Drop a comment and let me know how YOU deliver value.