PURSUIT: Framework for your next great product idea.

TLDR: Use this quick framework to help think about product questions. I’ve learned through building product at startups and in large companies that product thinking doesn’t just rest with the Product Manager. On the greatest teams, everyone thinks like an owner. So my dear product-y folks… meet PURSUIT yet another acronym to hopefully make your life better: P = Problem, U = User, R = Rationale, S = Solution, U = Uncertainties/ risks, I = Insights, T = Test metrics

I work with a great group of product managers, engineers, designers, and more XFN…for example, Xin and Michael below (hey guys!)

In each of their disciplines they are generally top of their class or in one case... the top Physics student in all of China (true story.) Yet early on, I realized that we would at times have disconnects on basic product calls. The root cause was that engineers and the team were guessing at how to think through product.

To resolve, I shared my recipe for product development called “PURSUIT”. These are 7 questions that you can treat as a checklist for product thinking. For my product reviews, these are the exact questions I will ask workstream owners. This helps the presenter to prep and me to be more predictable.

This beauty is the extent of my design skills…image may or may not have been made in Powerpoint ;)

P.U.R.S.U.I.T

1. Problems: Great products start with clear people problems. In this first step, identify which precise problem(s) you are trying to solve. These stem from issues you may hear in research, results of data analysis, market gaps, or opportunity areas that you believe to be unexplored. Sometimes these manifest as “pain points” that the user is aware of that they articulate to you. This “pain” is what you ideally stop from happening by solving core people problems.
2. Users: Be clear about who you are optimizing for. Even if your team is building something that an entire population may use, identify who within that population you are uniquely prioritizing and why. Have a clear prioritization criteria (growth rate, size of audience, proximity to mission, etc.) You may also choose to identify a secondary audience that you protect while optimizing for primary. Example “I won’t erode value or degrade experience for this person while optimizing for this priority group.” As lean guru (and one of my favorite Stanford lecturers) Steve Blank shares “your job is not to make every customer happy…[but to] pick the right customer segments” and solve their problems.
3. Rationale: Be able to clearly answer: Why does solving this problem matter? This helps you to avoid building something for tech’s sake or because it seems cool. What data or research supports that this problem is worth solving for this customer group? Identify the impact that will be realized from solving this problem and how it connects to your team or the company’s overall mission.
4. Solution: Your solution should be a proposal with clear hypotheses and assumptions. As you form your build-and-test plan you are ultimately looking to evaluate whether the assumptions you made are valid. For some people, developing a solution can feel like a lot of pressure. One thing that has helped me is understanding that with 100% certainty my solution is not 100% right. It will however, be a step towards a better world for my prioritized users. Be open to being wrong and leveraging your team to tack towards the best solution. As Eric Ries in The Prototype Mindset one of the most critical steps in solutioning is the MVP test and iterate cycle.
5. Uncertainties: It is thrilling to think on all the ways your great idea can go right. Don’t let that blind you to risks inherent in your plan. Be clear about failure modes and which of your assumptions are weakest. This should inform your test plan (validate the riskiest assumptions early on) and how you will iterate. I think of uncertainties in terms of a few categories that I take largely from my startup days: market risk, execution/ technical risk, product risk, and based on recent experience…. malicious/adverse user behavior risk.
6. Insight: Include any research or results from other product tests that give you confidence in what will/won’t work in your solution idea. This is where you should in particular leverage your strong research, data, and marketing counterparts.
7. Test Metrics: Identify which test metrics you will use to evaluate how well your solution is solving the problem for your target user group. I find it helpful to start by stating a clear goal in natural language. Often goals will fall into three categories: a) Goals that link to your overall company mission, b) Feature adoption/ success metrics, c) quality and tracking metrics. For test metrics try your best to keep it as simple as you can and if you find yourself getting too creative on a monster composite metric, consider breaking your metric into smaller parts.

Give me some examples and more!

Click this link to view an example: How I concepted a product for real estate, “Investor Layers”

Additional resources I like:

• Ty Ahmad-Taylor on Product Manager Tools: Ty does an amazing job of laying out the role of a PM and the importance of problem-centricity
• Gibson Biddle and Todd Yellin on Evolution of a product leader and taking risks: In this interview Gib and Todd share on the windy path to product leadership and the importance of risk-taking to product leadership.
• Stanford D School Design Thinking Overview: This video gives an overview of the Stanford design thinking process.

Send me a direct message or drop a comment if you want to see more illustrations, resources, or have questions.