Shaping Your Pitch

A step-by-step guide to transform raw problems into well-shaped pitches ready for betting decisions

What is Shaping?

Shaping is the critical pre-work that transforms vague ideas into concrete, actionable proposals. It's about defining the problem, exploring solutions, and setting boundaries before asking teams to commit time.

🎯 What Good Shaping Delivers

  • Problem clarity: Specific user pain points
  • Solution direction: High-level approach without implementation details
  • Clear boundaries: What's in scope and what's not
  • Risk awareness: Known challenges and dependencies
  • Success criteria: How we'll know we solved the problem

⚠️ What Bad Shaping Looks Like

  • × Vague problem statements ("improve UX")
  • × Solution-first thinking without understanding why
  • × No boundaries or constraints defined
  • × Undefined success criteria
  • × Ignoring technical or business risks

👥 Who's Involved in Shaping

Shapers

Senior designers, product managers, or technical leads who can think strategically

Subject Experts

Domain experts, customer support, or users who understand the problem deeply

Technical Advisors

Engineers or architects who can assess feasibility and identify technical risks

Stakeholders

Business owners or leaders who understand strategic priorities and constraints

The Shaping Process

1

Set Boundaries

Define what's possible and what's not

🕐 Set Your Appetite

How much time is this problem worth solving?

2 weeks: Small improvements, fixes, or quick wins
4 weeks: Meaningful features or significant improvements
6 weeks: Major features or complex problems

🎯 Key Questions to Answer

  • • What's the maximum time we'd spend on this?
  • • What would we definitely NOT do in this timeframe?
  • • What's the minimum viable outcome?
  • • How does this fit with our other priorities?
  • • What dependencies might constrain us?
2

Understand the Problem

Get to the root of what users actually need

🔍 Research Activities

  • User interviews: Talk to 3-5 people experiencing this problem
  • Support ticket analysis: What are users complaining about?
  • Data exploration: What does usage data tell us?
  • Internal stakeholder interviews: Sales, support, customer success perspectives

💡 Discovery Questions

  • • What specific task are users trying to accomplish?
  • • Where exactly do they get stuck or frustrated?
  • • What workarounds are they using now?
  • • How often does this problem occur?
  • • Who is most affected by this problem?
  • • What's the business impact of not solving this?
💡 Pro Tip: Use the "5 Whys" Technique

Keep asking "why" to get to root causes. "Users don't use feature X" → "Why?" → "It's hard to find" → "Why?" → "It's buried in settings" → "Why?" → "We never designed for this use case"

3

Sketch Solutions

Explore approaches without getting into details

✏️ Sketching Techniques

  • User flow diagrams: How users will move through the solution
  • Wireframes: Basic layout and key elements (no visual design)
  • System diagrams: How different parts connect
  • Alternative approaches: 2-3 different ways to solve it

🎨 What to Include

  • • Key user interactions and flows
  • • Main UI elements (but not pixel-perfect)
  • • Data flow and integrations needed
  • • Critical decision points for users
  • • How it fits with existing features

Remember: Sketches should be concrete enough to discuss but abstract enough that teams have creative freedom in implementation.

4

Address Risks & Rabbit Holes

Identify what could go wrong and set guardrails

⚠️ Risk Assessment

Technical Risks
  • • Performance implications
  • • Integration complexity
  • • Data migration needs
  • • Browser/device compatibility
Business Risks
  • • User adoption challenges
  • • Regulatory compliance
  • • Resource dependencies
  • • Market timing

🐰 Avoiding Rabbit Holes

Identify areas where teams might spend too much time:

  • • Perfect UI animations or micro-interactions
  • • Edge cases affecting <5% of users
  • • Over-engineered architecture for current needs
  • • Extensive customization options
  • • Integration with every possible tool

Circuit Breaker: Define clear "stop points" where you'll reassess if the solution is taking longer than expected.

5

Define Success & Write the Pitch

Make it concrete and ready for betting

🎯 Success Criteria

How will you know the problem is solved?

User Behavior Changes

What will users do differently?

Business Metrics

What numbers should improve?

Qualitative Signals

Support requests, user feedback, etc.

📝 Pitch Checklist

🚨 Common Shaping Mistakes to Avoid

Process Mistakes

  • × Shaping in isolation: Not involving domain experts or technical advisors
  • × Under-shaping: Pitching vague ideas that teams can't execute
  • × Over-shaping: Specifying implementation details and removing team autonomy
  • × Rushing to solutions: Not spending enough time understanding the problem

Content Mistakes

  • × Solution masquerading as problem: "We need a dashboard" instead of "Users can't track progress"
  • × No clear boundaries: Leaving scope completely open-ended
  • × Ignoring constraints: Not considering technical debt, resources, or dependencies
  • × Unrealistic appetite: Complex problems with 2-week appetite

Ready to Shape Your First Pitch?

Use this guide to thoroughly research and shape your problem before creating a pitch. Good shaping leads to better betting decisions and more successful projects.