Customer Outcomes Template for User Research

Tony Ulwick's research at Strategyn typically identifies 10-25 outcomes per job. Fewer than 10 usually means you are defining outcomes at too high a level. More than 30 means you are capturing tasks rather than outcomes. A good test: can two different product solutions each address this outcome? If yes, it is an outcome. If only one specific implementation addresses it, you are describing a solution.

Use an in-app survey (Typeform, SurveyMonkey, or your own implementation) targeting active users. Keep the survey focused on one job with 10-15 outcomes. For each outcome, ask two questions on a 1-10 scale: "How important is this to you?" and "How satisfied are you with your current ability to achieve this?" Most users complete a 15-outcome survey in under 5 minutes.

The framework works for any product with users, including internal tools, developer platforms, and ops tools. Replace "customer" with "user." The principle is the same: identify outcomes that users value highly and are currently poorly satisfied with. Internal users often have fewer alternatives, so even moderate dissatisfaction signals a real problem.

Each underserved outcome can become a Key Result in your [OKR framework](/glossary/okr-objectives-and-key-results). The outcome statement is the Key Result. The baseline and target from the performance table define the measurement. The Objective is the higher-level job or theme the outcomes fall under. This creates a direct line from customer research to team goals.

Outcomes are customer-centric: they describe what the customer achieves. Metrics are product-centric: they describe what the product measures. "Minimize the time to generate a board-ready report" is an outcome. "[Time to first report](/metrics)" is the metric you track to know if you are serving that outcome. Every outcome should have a corresponding metric in your analytics. ---