<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>
<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
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 …
<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>
<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>