4 exercises — structuring a 3-minute pitch, delivering an elevator pitch with evidence, responding to complexity objections, and adapting pitch depth for different audiences.
0 / 4 completed
1 / 4
You need to pitch a new internal monitoring tool to your manager in 3 minutes. Which structure is most effective?
Option B uses the Problem / Solution / Why Now / What I Need pitch structure:
1. Problem (specific): "40 minutes per incident manually correlating logs across five dashboards" — not "our monitoring is bad", but a specific, measurable cost 2. Root cause named: "current tooling surfaces noise, not the root signal" — shows you understand the cause, not just the symptom 3. Solution described functionally: "alert aggregation layer that correlates signals and ranks by impact" — tells the listener what it does, not how it's built 4. Why now (urgency): "three P1s in the last 30 days that exceeded SLA" — links the solution to a current, measurable business problem 5. What I need (bounded ask): "2 sprint cycles + one senior engineer review" — specific, scoped, easy to approve
Why A fails: "Has dashboards and alerts" is a feature list — no problem framing, no urgency, no ask
Why C fails: "Quite complex but I can explain it" signals lack of preparation; "aggregates things" is too vague to approve
Why D fails: Formal framing without content — this sounds like preamble, not a pitch
3-minute pitch formula: Problem (specific + measurable) → Solution (functional, not technical) → Why now (current business cost) → What I need (specific, bounded)
2 / 4
You built an internal code review automation tool that saves time. You need a 30-second elevator pitch. Which is best?
Option C is a strong elevator pitch because it follows the cost → insight → solution → proof pattern in 30 seconds:
1. Specific cost: "2.3 days average to close code reviews" — puts a number on the problem immediately 2. Diagnostic insight: "Half of that is formatting and boilerplate — things a machine can catch" — shows you understand the structure of the problem 3. Solution that solves the diagnosed problem: "automates those checks, surfaces only substantive feedback" — connects directly to the insight 4. Proof from a real pilot: "2.3 days to 0.8 days across three teams" — this is not a claim, it's evidence
Why A fails: "Python, AST parsing, CI integration" is a technology description, not a value proposition. The listener doesn't know why they should care
Why B fails: "Something every team needs" is a generalisation — it doesn't connect to a specific problem this organisation has
Why D fails: "Faster and better" without evidence — after hearing the pitch the listener still doesn't know what specifically changed
Elevator pitch formula: [Specific current cost] → [Insight about why] → [What your solution does about that] → [One piece of evidence from reality]
3 / 4
Your manager says: "This monitoring tool sounds interesting, but it sounds too complex to build given our current sprint load." How do you respond?
Option B uses the validate → decompose → checkpoint → bounded downside technique for handling a complexity objection:
1. Acknowledges the concern as legitimate: "The complexity concern is real" — not dismissing the objection 2. Reduces the risk with a minimal first milestone: "single-service prototype in one sprint" — transforms an overwhelming scope into a single bounded unit 3. Minimises integration risk: "doesn't require changes to the existing alert pipeline" — names the specific fear (breaking existing systems) and addresses it 4. Uses phased checkpoints: "go/no-go after each sprint" — turns an open-ended commitment into a series of small decisions 5. Names the bounded downside: "stop at the first milestone if it's not delivering value — sunk cost is one sprint" — the manager can now assess: is one sprint of risk acceptable? The answer is usually yes
Why A fails: "Not that complex actually" — dismisses your manager's concern and starts an argument about your assessment vs. theirs
Why C fails: "I can make it simpler" is a vague concession — simpler in what way? At what cost to the solution's value?
Why D fails: "The complexity is necessary" shuts down the conversation with no compromise path
Complexity objection formula: Validate → Smallest first milestone → Risk addressed → Phased checkpoints → Named bounded downside
4 / 4
You're presenting the same tool to three different people: a tech lead, a product manager, and a VP of Engineering. Which adapts the pitch most effectively?
Option C demonstrates audience-adaptive pitching — same product, three different value propositions:
Tech lead: Wants to know HOW it works and will have opinions about the implementation. The pitch invites their expertise: "What would you want in the rule set?" — turns evaluation into collaboration
Product manager: Doesn't care about AST parsing. Cares about outcomes. The pitch starts with the function ("automates mechanical review") then jumps to the business impact: "2.3 days to 0.8 days"
VP: Cares about engineering capacity and cost. "65% reduction in review cycle time" and "4 engineer-hours per sprint freed" are the metrics they track. "Runs on existing CI — no new vendor costs" removes a potential barrier before it's raised
Why A fails: One pitch for three audiences means one audience will be bored (VP hearing about AST), one will be confused (PM hearing about AST), and one will be underserved (tech lead who needs implementation details)
Why B fails: The PM version ("a thing that checks code") is dismissive and vague; the tech lead version is all implementation without context for why the problem matters
Why D fails: "Let them take what's relevant" is an audience-burden approach — it's the presenter's job to adapt the message, not the audience's job to filter it
Audience adaptation formula: Tech lead → HOW (mechanism) + invite their expertise PM → WHAT it does (function) + WHAT changed (business outcome) VP → IMPACT in their metrics + COST removed before it's raised as objection