4 essential questions to ask before you prioritize product ideas

How to make the right decisions and keep your stakeholders in the loop, including the doc template I use at Typeform

Your team could build a million things. At the same time, your job as a PM is to make sure you ship the most valuable product. You want to solve the most important customer problems with the smallest effort possible.

It’s pretty straightforward to find new product ideas. Your customers share their feedback and request new features. The data you collect on customer behavior highlights usability issues. Your team and company executives share their new ideas with you all the time.

The hard part is to find the good ideas. Where should you invest your time and effort? In which direction should the team experiment next? Which idea will be 10x better than existing solutions?

In this post, you’ll discover a simple tool which helps you discern the most promising ideas from the rest, by asking 4 questions:

The opportunity analysis doc.

A template for evaluating product opportunities

When you evaluate a promising idea, you want to ask yourself 4 essential questions:

1. Desired outcome. What is the customer (or business) trying to achieve?
2. Problem with existing solutions. How does the current solution not allow the customer or business to reach their goals?
3. Measures of success. How will we know we have solved the problem?
4. Strategic fit. How does fixing this problem contribute to our strategic goals?

The idea is to write your answers to these questions in a document, no longer than 2–3 pages. When you write it down, you can share your thought process with the whole organization. It’s a lightweight way to communicate all important information to your team and stakeholders. Here’s what it looks like:

You can find a link to the template at the end of this post.

Let’s dig deeper into what goes in each section.

1/ Desired outcome

What is your customer or business trying to achieve? Focus on the underlying interests and desired outcomes. Leave out all solution ideas. Don’t equate feature requests and customers’ ideas with desired outcomes:

“If I had asked people what they wanted, they would have said faster horses.” — Henry Ford (or possibly someone else, it doesn’t really matter)

I personally like to use the jobs-to-be-done framework and focus on functional and emotional jobs. In case you haven’t heard about it, you can read up on it here or watch a great talk about it here.

It’s important to be specific. Make the desired outcome tangible and concrete. Here’s a great example from Jason Evanish on what a desired outcome is not: “As a marketer, I want a mobile app so I can access my data away from a computer”.

It’s rather: “On their way to work on the subway, content marketers like to check how their blog traffic is doing for items they published that morning or the day before. It helps them get into work and know how they’re doing before they sit down. If a number is low, they may try promoting it extra to try to raise the number. If the number is high, they may share the win with others on the team.”

Instead of asking yourself “why would someone use my product?”, ask “what is this person trying to achieve?”.

Source: Kathy Sierra’s talk on building badass users © 2013 UserOnboard.com

Write in a style that’s easily understandable for anyone internally at your company. A new hire should be able to get what’s going on.

Customer quotes are a powerful way to illustrate a point you’re making. With a small caveat: don’t use them in isolation. Make sure they reflect a pattern and not just an individual opinion.

2/ Problem with existing solutions

Define how current solutions do not allow the customer or business to reach their goals. Provide focus and frame the problem. I use these guidelines from Facebook to make sure the problem statements are effective:

• Be human, simple, and straightforward. Capture the hearts and minds of the people you meet.
• Get at the why behind something happening. Don’t try to solve “people are dropping off in the X flow” — investigate the why behind them dropping off. Then solve that problem.
• Stay away from solutions.
• Remain company wins! — agnostic. Don’t think about monetizing just yet, focus only on the user (except for company-focused initiatives).

Explain how you know this is a real problem worth solving. I like to summarize customer research and include key data points like support tickets and data analysis. If you find several problems, rank them in order of priority for the customer.

3/ How we will measure success

It’s essential to have a clear success metric in place. Before you launch anything, you should know exactly how you will measure success. If you don’t, confirmation bias will lead to a wrong and misleading interpretation of the data you collect.

Focus on the impact you want to have. “We will have accomplished this”, not “we need to do that.” Make sure to include how a metric is calculated and what it’s meant to measure.

You can also come up with a counter metric which would convince you that you’re not breaking two new things every time you fix one. Here’s an example from Intercom:

Put a new button in your product and people will click it. Get enough clicks and you can call that an increase in engagement. But that’s nonsense. A counter metric is “have people stopped doing anything else?”. So if you add a metric totrack one area of your product, you must also analyse the other areas that arelikely to be impacted.

4/ Strategic fit

Name the company goals you impact with your initiative. This part acts as a sanity check and makes sure all efforts are aligned. For example, if your product is focused on small and medium businesses, don’t prioritize features for enterprise customers.

Avoid a common mistake: documentation for documentation’s sake

Don’t mistake the opportunity analysis doc with another lifeless item on your to-do list. You can’t just ‘punch out a product document’. Following a rigid approach would mean you’re missing the whole point.

The document doesn’t replace the product discovery process. The doc is just the outcome of the process, in written form. It serves as a reminder for you to ask the right questions. Jason Evanish summarizes it neatly:

If you don’t know the answer to one of the sections in the Thesis [their name for opportunity analysis doc], go find out. Dive into your analytics, talk to customers, run a survey, talk to your sales/account management/support teams that interact with customers regularly. You will gain the full respect of your designers and engineers if they know you always have a customer story and/or data to back up everything they may ask you about in the Thesis.

That’s it! By following the above, you will make sure you’ve asked all the important questions before investing too much effort into an idea. Writing it down will help you structure your thinking process, and make your stakeholder communication easier.

In case you want to use the template for yourself, click here to find it on Google Docs. Just make a copy and adapt it to your own needs. Thanks for reading.

“There is no way to write a six-page, narratively structured memo and not have clear thinking.” — Jeff Bezos, Amazon