<aside> 💡 Keep in mind the majority of your pitch shaping time should be focused on the problem statement and insights, using insights to refine your initial problem statement before any low-fi designs or solution drafting is done.

</aside>

Problem Statement

<aside> 💡 It’s critical to have a clearly defined core problem to solve or use-case/job-to-be-done to focus on. It’s ok to have secondary, tertiary, and additional problems but try to keep your “core problem” clear and succinct. Keep in mind your problem statement might change over time as you gather new insights and learnings.

</aside>

Core problem: Required

• What problem are we trying to solve? What is the opportunity, job-to-be-done or use case that we’re addressing?
• Is this a new or existing problem? How likely is this to happen? What’s the impact? Provide as much detail as possible..

Why now?

Explain why now and how this might align with your objectives or key results/goals OKRs).

Hypothesis format — If we…then we will increase x by …

Audience

<aside> 💡 For whom are we solving this problem? Which customers are affected? When possible, link to Archetypes, User Personas, and User Journeys to ensure consistency across pitches.

</aside>

• User Persona:
• Customer Journey:
• Archetype:

Insights

<aside> 💡 Not every pitch has the same approach when it comes to insights: For example, an existing feature might rely more on existing quantitative insights vs. a newer feature has no baseline metric to track so you might want to do more user interviews and other qualitative insights. Even with these nuances, every pitch should have a heavy focus on gathering insights.

</aside>