Stop Being the Cook — Sell the Experience, Not the Recipe
A sushi chef's job was never to explain the rice. The solution narrative above has a companion discipline for the room where you get ten minutes and no more: stay at the outcome, and refuse to drop into the mechanism before it's asked for.
Abhineet Srivastava's account of failing, then correcting, an executive pitch turns on one metaphor worth carrying into every discovery call and every demo: a sushi chef's job is not to explain the recipe, it's to create an experience. Nobody at the counter wants a lecture on rice temperature and knife angle. They want to experience the outcome — a beautiful meal that makes them feel something. The same split runs straight through pre‑sales, and it's the reason a technically excellent answer routinely loses to a shorter, vaguer one that stayed at the level of outcome.
Symptom vs. pain
His own failure is the clean version of a mistake most technical people make at least once: he walked into a CIO conversation armed with low CSAT and NPS scores, and pitched against the scores. The scores were never the pain — they were a symptom of it, and the CIO's actual priority sat one level further up, in a business consequence the scores only gestured at. Confusing a measured symptom for the underlying pain is a diagnostic error, not a presentation error, and no amount of polish on the pitch fixes it.
Command of the Message, made executable
The methodology row in Module 07 names Command of the Message as one discipline among several. This is what it looks like as a four‑question prep routine, done before the meeting rather than during it:
| # | Question | What it forces |
|---|---|---|
| 1 | What are this executive's top two or three business outcomes right now? | Anchors the whole conversation to their scorecard, not your product's |
| 2 | What specific operational gaps sit under those outcomes — not feature gaps? | Keeps the diagnosis at the level the executive actually experiences it |
| 3 | What's one comparable customer proof point, with real metrics? | Replaces a claim with evidence before anyone has to ask for it |
| 4 | What's the lowest‑friction next step that would validate this? | Ends the meeting on a decision, not a follow‑up deck |
Ten minutes, four movements
The shape that follows from those four answers is short on purpose — an executive audience punishes length exactly as Module 18 describes:
- 0–2 minutes — show you understand their industry's actual pressures, in their vocabulary, before you say anything about your own solution
- 2–5 minutes — contrast current state against future state, plainly, as two pictures rather than a feature bridge between them
- 5–8 minutes — state your point of view on why, and back it with the one proof point from the prep above
- 8–10 minutes — ask for a team validation session, not a product demo. The demo is a later, smaller room's job
Three execution habits that carry the words
- Spatial contrast. Use one side of the room, or one side of the screen, for the current state and the other for the future state — a physical anchor makes the contrast legible faster than a sentence does.
- Cadence control. Slow down by roughly a tenth when a number lands, and let silence sit after it. A number said at normal pace reads as one more fact; the same number said slower reads as the fact.
- Listen without interrupting. Let the executive finish describing their own pain uninterrupted, even past the point where you've understood it — the person who was allowed to finish their own diagnosis becomes the internal advocate for yours.