https://youtu.be/Vq1f6HnGddU
前不久我去当了一场 Hackathon 的评委。一天审 21 个产品 demo，每个 10 分钟讲 + 5 分钟答疑。一整天下来快六小时的内容，到最后我能清晰回忆起来的产品，不到 5 个。
不是项目不好，里面也有很真实的好点子。问题在哪？
不在产品，在结构。
将近一半的团队没等到 demo 时间就被叫停了。有几个甚至从头到尾没有真正打开过自己的 app。前 7 分钟讲背景、讲团队、讲市场规模、讲方法论，等计时器跳到「Demo!」，他们手忙脚乱地翻一张截图，三言两语过完——而这本来应该是整个 pitch 里最有意思的部分。
特别遗憾。你花了几天甚至几周做的东西，结果到了最关键的 90 秒，已经没时间展示了。
这种结构问题不止出现在 hackathon。设计评审、客户提案、内部产品建议、会议 keynote，到处都是。设计师、Founder、咨询顾问，几乎每个人都在不停地 pitch。但大多数人讲的顺序，是反的。
修这个问题的工具，已经 50 年了
视频里我拆解的框架，是 1973 年 Barbara Minto 在 McKinsey 提出的金字塔原理（Pyramid Principle）。它把绝大多数人凭直觉用的「层层铺垫到结论」结构，整个反转过来。
结论先讲。三个理由支撑。每个理由配一个证据。
整座金字塔，就这么三层。
这个形状不是装饰用的。它对应的是评委、客户、Founder 这种高阶听众真实的信息处理方式：先要答案，再决定要不要花时间听理由。如果你把结论藏在第 12 页 PPT，等你讲到那一页时，他们的注意力早就走了。
怎么开场：SCQA
讲结论之前，你需要 30 秒的开场——不是 7 分钟，是 30 秒。金字塔原理给了一个干净的开场公式，叫 SCQA。
Situation 情境——把范围收窄，今天我们到底在解决谁的什么问题？
Complication 冲突——展示差距：现在的结果是什么，期望的结果是什么，这中间的 gap 为什么是个问题？
Question 问题——把听众心里那个「那要怎么补上呢？」明确说出来
Answer 答案——你那一句话的结论
30 秒之内，听众已经知道情境、感觉到张力、自己脑子里冒出了那个问题，并准备好听你的答案。之后所有时间都用来用「理由 + 证据」捍卫这个答案。
每个 Pitch 都必须回答的三类问题
一旦你抛出了结论，听众心里默默在问三个问题之一。一个好的 pitch 应该全部都回答到。
Why（为什么）——这事为什么值得做？用数据、差距、不解决会怎样，来证明问题成立。
How（怎么做的）——你的方案怎么运作？demo 就活在这一层。步骤、流程、产品当场跑给我看。
How do you know（你怎么知道有效）——拿出证据。Beta 数据、用户反馈、和过去状态的对比。
主结论下面的每一个支撑理由，都应该回答这三个之一。如果某个理由不在这三类里，它就不该出现在前 90 秒。
5 步法 Pitch 框架
把这些拼起来，我现在用的 5 步法长这样：
一句话讲结论——开场前 15 秒，说清楚「我们做了 X，给 Y 用户，解决了 Z 问题」
MECE 拆三柱——三个互不重叠、合在一起又完整的理由。回答：为什么这是真问题、为什么是现在、为什么是我们
每柱配一个证据——一对一，不要堆
SCQA 开场——把 Situation / Complication / Question / Answer 全部压进前 30 秒
30 秒自检——录音自己讲一遍开场前 90 秒。讲不完结论 + 三柱，就回到第 1 步
第 5 步是大多数人会跳过的一步，也是决定 pitch 能不能落地的那一步。如果你在自己房间里对着手机录音都讲不完，到了 hackathon 现场，倒计时一响，更不可能讲完。
10 分钟 Pitch 时间该怎么分
下面这张时间分配表，来自我那天清楚记得的 4 个 pitch 的共性：
| 阶段 |
时间 |
说明 |
| Hook + 一句话结论 |
30 秒 |
你只能让对方记住一句话时，要记的就是这句 |
| 问题陈述 |
30 秒 |
谁痛，多痛 |
| 解决方案 |
30 秒 |
你做了什么，为什么这么做 |
| Demo 演示 |
5–6 分钟 |
整场最重要的一段，不能低于总时长 50% |
| 影响 / 进展 |
1 分钟 |
数据、Beta 数字、商业模式 |
| Call to action |
30 秒 |
你希望对方做什么 |
注意里面缺了什么：那段杀了我评过一半项目的「公司背景 + 方法论 + 团队 slide」7 分钟前奏，没了。
一个具体例子：PerCam
为了把抽象框架落到实处，我让 Claude 帮我写了一个虚构产品的 pitch。这个产品叫 PerCam，是一个戴在猫脖子上的项圈摄像头。它不是真的，纯粹为了演示框架而存在。
按这个框架写出来，整个 pitch 90 秒，slide 长这样：
Situation 情境：全世界有超过 6 亿只宠物猫。室内猫一天 70% 清醒时间都不在主人身边。室外猫消失在邻居家的围栏和偶尔的鸟里。
Complication 冲突：现在我们能做的，是把一台静态宠物摄像头固定在墙上，盯着空房间，而猫早就跑到别处去了。
Question 问题：怎么把摄像头放到一个它从未到过的地方——猫自己身上，而且猫还不讨厌你？
Answer 答案：Meet PerCam。一台 12 克重的项圈摄像头，全天高清直播猫的生活，AI 自动剪掉无聊片段，猫根本不知道它在那里。
然后是三柱：
Hardware——12 克，猫认可，沿用 GoPro highlights 那套 on-device ML 重训了猫视角运动模式。
AI Daily Reel——每晚 9 点一段 90 秒精剪集锦。看到了哪些鸟、睡了几次、神秘的飞奔在干嘛。Beta 用户开包率 89%，比你最好朋友的 Instagram Stories 还高。
Social sharing——Beta 用户平均每周分享 4 段到社交媒体，是我们对标过的任何宠物 app 的 3 倍。
收尾：PerCam 是世界上第一台为「摄像师恰好是只猫」设计的摄像头。我们在找一位硬件顾问和一位兽医合作伙伴。来 7 号桌找我，我有猫的照片。
整段 90 秒就讲完了，还有余地呼吸。对比一下我评过那种 7 分钟 PPT 马拉松式 pitch，你就能看到这个框架到底给了你什么——时间。具体说，是给 demo 留出来的时间。
什么时候不该用这个
金字塔原理是分析型 pitch 的结构工具：hackathon、设计评审、客户提案、产品建议书。它不适合 keynote 讲故事、情绪性沟通、销售叙事这类「过程本身就是重点」的场景。如果你的目的是让人深深感受到什么，要换结构。如果你的目的是让人在听完之后立刻做点什么，这个能用。
另外，要注意你坐在 pitch 桌的哪一边。VC Demo Day（YC、Sterling Road 这种）的主流建议是 demo 时间越少越好、聚焦 traction 数字；但 Hackathon 不一样，demo 本身就是 traction。同一个框架，时间分配恰好相反。
下一步
如果你接下来 30 天内有个 pitch——hackathon、客户评审、董事会、Portfolio 评审——试一次。写下你那一句话的结论，写下三个支撑理由，把开场 90 秒里所有不属于这两件事的东西全部砍掉。然后录音听一遍。
你要么会重新发现自己想说什么，要么会发现自己还没想清楚。哪种结果都有用。
希望这期视频对你有帮助。如果你接下来有个 pitch，欢迎在评论区分享你的结构，我可能会挑 1-2 份在下个视频里拆解。
下次见。
How to Pitch in 90 Seconds Using the Pyramid Principle (After Judging 21 Hackathon Pitches)
I recently sat on the judging panel of a hackathon. Twenty-one product demos, ten minutes each, plus five minutes of Q&A. By the end of the day I'd reviewed nearly six hours of pitches. And I could clearly recall fewer than five of the products.
The teams had built real things. Some of the ideas were genuinely good. So what happened?
The problem wasn't the product. The problem was the structure.
Almost half of the teams ran out of time before they could show their demo. A few never opened the app at all. They spent the first seven minutes setting context — founder backgrounds, market size, methodology, slide design — and then, when the timer hit "Demo!", they had ninety seconds to flip through a screenshot and explain what was supposed to be the most exciting part of the entire pitch.
What a shame. You spend days, sometimes weeks, building something — and then you don't leave any room to actually show it.
I've watched the same pattern in design reviews, client pitches, conference talks, internal product proposals. People waffle on the lead-up and never get to the most interesting part of what they made. Designers, founders, consultants — almost all of us are pitching something, almost all the time. And almost all of us are doing it backwards.
The fix is fifty years old
The framework I now use, and the one I unpack in this video, was developed in 1973 by Barbara Minto, a consultant at McKinsey. It's called the Pyramid Principle, and it inverts the natural order of presentation.
Instead of building toward your conclusion, you lead with it.
Conclusion at the top. Three reasons supporting it. One piece of evidence under each reason.
That's the entire pyramid.
The shape isn't decorative. It mirrors how senior audiences — judges, executives, clients — actually process information. They want the answer first, then they decide whether the reasoning is worth their time. If you bury the conclusion on slide 12, by the time you arrive they've already left the room mentally.
How to open: SCQA
Before you can deliver your conclusion, you need thirty seconds of setup. Not seven minutes — thirty seconds. The Pyramid Principle gives you a clean recipe for that opening, called SCQA.
Situation — narrow the scope. What problem are we actually solving today?
Complication — show the gap. What is the current result, and what is the expected result, and why is the distance between them a problem?
Question — surface the obvious "How do we close that gap?"
Answer — your one-sentence conclusion.
By thirty seconds in, your audience knows the situation, feels the tension, has formed the question themselves, and is ready to hear your answer. You then spend the rest of the time defending the answer with reasons and evidence.
The three question types every pitch must answer
Once you've delivered your conclusion, the audience is silently asking one of three questions. A good pitch answers all three.
Why — why is this worth solving? This is where you justify the problem. Cite data, cite the gap, cite who suffers if it stays unsolved.
How — how does it work? This is where the demo lives. Steps, walkthrough, the actual product doing the actual thing.
How do you know — how do you know your solution works? This is where you bring proof. Beta numbers, user feedback, comparison with the previous state of the world.
Every supporting reason under your main point should answer one of these three. If a reason doesn't, it doesn't belong in the first ninety seconds.
A 5-step pitch framework
Putting the structure together, the framework I use looks like this:
Conclusion in one sentence — open the first fifteen seconds with "we built X, for Y, that solves Z."
MECE three pillars — three reasons that are mutually exclusive and collectively exhaustive. They should answer: why is this a real problem, why now, why us?
One evidence per pillar — for every reason, attach exactly one piece of demo-able evidence.
SCQA opening — pack situation, complication, question, and answer into the first thirty seconds.
30-second self-check — record yourself delivering the first ninety seconds. If you can't get through conclusion + three reasons in that window, return to step 1.
The 30-second self-check is the part that most people skip and the part that most decides whether a pitch lands. If you can't say it tightly to a phone recorder alone in your room, you can't say it on a hackathon stage with a timer counting down.
How time actually breaks down in a 10-minute pitch
Here is the time allocation I'd recommend, based on what worked in the four pitches I clearly remembered:
| Phase |
Time |
Notes |
| Hook + one-sentence conclusion |
30s |
The thing they remember if they only hear one sentence |
| Problem statement |
30s |
Who hurts, how much |
| Solution |
30s |
What you built, why this way |
| Demo |
5–6 min |
The single most important block. Never less than 50% of total time |
| Impact / traction |
1 min |
Data, beta numbers, business model |
| Call to action |
30s |
What you want from the audience |
Notice what's missing: the seven-minute "company background and methodology" preamble that killed most of the pitches I judged.
A worked example: PerCam
To make this concrete, I asked Claude to draft a one-sentence pitch for a fake product. The product is a cat-collar camera I'm calling PerCam. It's not real. It exists only as a demonstration of the structure.
The pitch, written using the framework, runs ninety seconds and looks like this in slides:
The Situation: There are over 600 million pet cats in the world. Indoor cats spend 70% of their waking hours away from their owners. Outdoor cats vanish into fences, neighbors, and the occasional bird.
The Complication: The best we can do today is a static pet camera bolted to a wall, watching an empty room while the cat is somewhere else entirely.
The Question: How do you put a camera somewhere it has never been before — on the cat itself, without the cat hating you for it?
The Answer: Meet PerCam. A 12-gram collar camera that streams your cat's day in HD, auto-edits the boring parts, and the cat doesn't even know it's there.
Then the three pillars:
Hardware — twelve grams, cat-approved, on-device ML stack retrained on cat-perspective motion patterns.
AI Daily Reel — every evening at 9pm, a ninety-second highlights reel. Birds spotted, naps logged, mystery zoomies explained. Beta open rate: 89%.
Social sharing — owners share an average of four clips per week to social, three times the rate of any pet photo app we benchmarked.
The closing: PerCam is the first camera built for the camera operator who happens to be a cat. We're looking for a hardware advisor and a veterinary partner. Find me at table 7. I'll have cat photos.
That entire pitch fits comfortably in ninety seconds with room to breathe. Compare that to the seven-minute slide marathon most teams I judged delivered, and you start to see what the framework actually buys you: time. Specifically, time to demo the thing you built.
When not to use this
The Pyramid Principle is a structural tool for analytical pitches — hackathons, design reviews, client recommendations, product proposals. It is not a tool for keynote storytelling, emotional appeals, or sales narratives where the journey is the point. If your goal is to make someone feel something deeply, structure differently. If your goal is to make someone act on information quickly, this works.
It also matters which side of the pitch table you're on. For VC demo days (YC, Sterling Road), conventional wisdom is to demo little and focus on traction. For hackathons, the demo is the traction. Same framework, opposite time allocation.
Your next step
If you have a pitch coming up in the next thirty days — a hackathon, a client review, a board meeting, a portfolio crit — try this once. Write your one-sentence conclusion. Write your three pillars under it. Cut everything from the first ninety seconds that doesn't fit. Then record yourself.
You'll either rediscover what you actually meant to say, or you'll find out you don't have a clear answer yet. Either outcome is useful.
Hope this helps. Let me know in the comments if you have a pitch coming up that you'd like to work through together — I might unpack one or two in the next video.
