skip to content

Search

Second-Order Effects: The Decisions Behind the Decisions

Less than one minute read Updated:

Most product failures are not caused by the obvious mistake, but by a decision two or three layers back that nobody examined.

# product-management
# strategy
# leadership
# systems-thinking
# decision-making
Not in series

The bug that shipped last month was written into the roadmap eighteen months ago.

Every postmortem I have sat through at InMobi, Pixis, and Dell names the same kind of cause: a bad estimate, a missed edge case, a customer who churned in week three. Nine years into product work across those three companies, I have learned to distrust that name. The real fork is usually two or three decisions back, and nobody wrote it down.

At Pixis, I own the decision that let a team kill a manual QA gate for good, and the decision that made killing it safe was made months earlier, for a different reason entirely. This post is about the gap between those two moments, the question that closes it, and a fourth-order example still resolving on a product I shipped this month.

So that’s today’s post.

Today’s Post

The question that turns a guess into a chain, and the four reasons organizations refuse to ask it, in six sections.

  • Why the postmortem stops at the last click
  • The question, asked twice: “and then what?”
  • Why organizations punish the people who see the next ripple
  • A decision still paying rent four steps later, on a product live today
  • Reactive product management versus strategic product management
  • What leadership has to change for the discipline to survive

1. The postmortem that stops at the last click

Most postmortems name the last click: a wrong estimate, a slow rollout, a customer who churned in week three. Ask what made that click cheap, and the room goes quiet.

Churn is rarely the first fork. It is usually the third or fourth, downstream of a packaging call, an onboarding shortcut, or a support commitment nobody costed at the time. The measurement post on this site covers the review half of this problem: define success, instrument, review, record. This post is about the fork upstream of all four, the decision that made the eventual review necessary in the first place.

My own rule from the home page applies here too: unwritten means undecided. A team that cannot point to the fork two quarters back is not learning from its postmortem. It is narrating one.

2. The question, asked twice: “and then what?”

The practice is one question, asked twice. For any decision that ships, ask what it changes beyond the metric on the slide that approved it. The first answer is usually obvious. The second is where the real trade lives.

At Pixis, the first-order decision on AdRoom was narrow: enforce brand guidelines at generation time, not after a human check. First answer to “and then what”: the manual QA gate that used to sit between a marketer and a live ad could go. Second answer: designer workload dropped 80% company-wide, and marketers using AdRoom stopped routing work back through design at all.

One decision, two questions past the slide Enforcing brand guidelines at generation time was approved for one reason and paid off for two more. Grey monospace text names the real figures from the AdRoom rollout. The decision on the slide Enforce brand rules at generation, not after a check AdRoom, brand-guideline rule 1st First-order effect The manual QA gate between marketer and ad is gone designer workload down 80% 2nd Second-order effect Marketers trust self-serve; design stops taking the tickets $10M ARR in 5 months, 20-person team the decision approved on the slide the answer the slide already asked about the answer nobody on that call was asked
The slide asked whether generation-time enforcement was technically feasible. Nobody on that call was asked what happens to the marketer or the designer on either side of it. PNG ↓

Neither the 80% figure nor the trust shift showed up on the slide that approved the brand-guideline rule. Four automotive and consumer-tech brands into the rollout, the same decision had already produced $800K ARR in two months, and the wider motion ran to $10M ARR in five months with a 20-person team. None of that traces to the AI model underneath AdRoom. It traces to the fork about where the check happens.

3. Why organizations punish the people who see the next ripple

Second-order thinking should be common if it is this valuable. Four forces keep it rare.

It is slower in the room. A leader wants a recommendation crisp enough to fit a thirty-second slide. A second-order answer sounds like a preamble with contingencies attached, even when the person raising it is right.

It is harder to explain upward. A first-order story maps cleanly onto a hero arc: we saw a problem, we shipped, it worked. A second-order story implicates a hiring plan or a roadmap quarter that has not happened yet.

It costs something to say out loud. At Pixis, fifteen-plus voice-of-customer interviews on the Prism launch surfaced 55 requested features. Five made the roadmap. The discipline was declining the other 40, in front of the customers who asked for them, and that is not a comfortable Tuesday for anyone in the room.

Accountability is misaligned. The person who approves the first-order win rarely owns the third-order bill. By the time the bill lands, the champion has rotated roles, and the retro calls it “execution.”

4. A decision still paying rent four steps later

Some chains run long enough that you can watch every link resolve on a real product, live today. VocalApply, a voice agent I built this month to fill out job applications by conversation, is one.

The first-order decision was architectural: no backend holds the applicant’s data, so the app runs on WebMCP calls straight from the browser. Second order: a browser cannot hold an API key safely, so the app needs a way to reach a voice model without ever shipping that key to the page. Third order: OpenAI’s Realtime path has an answer, a server mints a token that expires in minutes, so the audio still never crosses a server I control. Fourth order: Gemini Live has no equivalent path on that same kind of socket. Every combination of a minted token, a key, and an API version was tried, and each one closes with error 1008, “unregistered callers.”

One architecture call, resolving four steps later No backend was decided for the data. It ends up deciding which provider asks you for a key. Grey monospace text is the real error and the real screen a user sees. Scroll slowly, this plays once. No backend, by design WebMCP calls run straight from the browser no server holds applicant data OpenAI mints a token A server issues a token that expires in minutes audio never crosses that server Gemini Live: no match Every token, key, and API version tried, same result error 1008, unregistered callers What the user sees OpenAI needs no key from you Gemini asks for your own four steps upstream of this screen the decision, made once, for the data the provider the decision happens to fit the provider it does not, and the screen that shows it Nobody approved "make Gemini the less convenient provider." That is four steps downstream of what was approved.
Nobody chose to make Gemini the less convenient provider. The choice that produced it, no backend, was made four steps upstream, for a reason that had nothing to do with either provider. (animates as you scroll to it) PNG ↓

The decision made at the start of the build resolves onto the fourth screen a user sees: Gemini asks the reader for their own key, and OpenAI does not. That difference is documented on VocalApply’s own project page rather than smoothed into a changelog line, because the honest version is more useful than the tidy one.

5. Reactive product management versus strategic product management

Reactive product management treats a constraint as a command. The customer is loud, the quarter is ending, the lever closest to the pain gets pulled, and it works, once.

Strategic product management treats the same constraint as data. It still ships on the same clock. It asks what kind of team and what kind of product this decision manufactures six months out, before agreeing to pull the lever.

Reactive and strategic, row by row Same four questions. One column answers them at approval time; the other answers them at the postmortem. Grey monospace text names this post's own example of each row. CONSTRAINT AS OPTIMIZES FOR NAMES THE BILL A REAL CASE REACTIVE STRATEGIC A command to obey the lever closest to the pain, pulled works once, on this quarter's fire The metric on this slide the recommendation that fits 30 seconds a smarter model, no reliability target After the postmortem the champion has already rotated roles the retro calls it "execution" A demo everyone wanted first Data to weigh what team and product this manufactures still ships, on the same clock The team, six months out a target nobody in the room asked for 4 hours to under 15 minutes, 400+ customers At approval time the downstream owner is in the doc already named before the bill, not after Pixis: reliability SLA before the AI layer reactive: the answer named at the postmortem strategic: the answer named at approval the case this section is built on
The Advance AI layer was the part that demoed well. The first mandate I gave the pod underneath it was a reliability number nobody in the room had asked for. PNG ↓

The Pixis reliability bet is the clearest case I have run personally. Advance, the optimization layer on top, was the part that demoed well. The first mandate I gave the twelve-person data pod underneath it was not a model improvement. It was a service-level target: cut data availability delay from four hours to under fifteen minutes across 400-plus enterprise customers. Nobody in the room asking for a smarter model was asking for that target. It is the reason the smarter model’s recommendations were worth acting on a year later.

6. What leadership has to change

Second-order thinking does not need a rare mind. It needs a rare tolerance for writing something down before it is interesting.

A decision record with four fields beats a good instinct every time: what we decided, what we believed would happen next, what would prove that belief wrong, and who owns the downstream effect if it does. That fourth field is the one most teams skip, and it is the one that keeps a launch from becoming a “we thought” six months later.

Four changes make the record worth keeping:

  • Ask “and then what,” not just “did it ship.” A launch review that stops at ship date optimizes the team for launching.
  • Reward the decline. Fifteen-plus voice-of-customer interviews only produce five good features if declining the other 40 carries no penalty for the PM who says no.
  • Put the third-order owner in the doc, not just the first-order approver. The name closest to the eventual bill should be visible at approval time, not discovered at the postmortem.
  • Tolerate “we were wrong.” VocalApply’s Gemini limitation lives on its own project page instead of a buried changelog line. That is the same habit, at a smaller scale, that a decision record asks a whole team to keep.

Takeaways

The decisions behind the decisions Six sections on the second-order effects nobody put on the approval slide Hoshank Ailani · hoshank.vercel.app 1. The postmortem lie Names the last click, not the fork The fork is usually two or three back A decision log catches it; a launch review does not unwritten means undecided nine years, three companies, same missing fork 2. Ask "and then what" twice Decision → brand rules at generation time 1st order → QA gate removed, -80% design load 2nd order → self-serve trusted, ARR follows $10M ARR in 5 months, 20-person team 4-brand pilot, $800K ARR in 2 months 3. Four reasons it gets punished 1 Slower in the room than a crisp slide 2 Harder to explain upward than a hero arc 3 Costs something: 40 declined features 4 The approver rarely owns the bill 55 features surfaced, 5 kept 15+ voice-of-customer interviews, one launch 4. A chain, four steps deep 1. No backend, by design 2. OpenAI mints a short-lived token 3. Gemini Live: error 1008, every time 4. Gemini asks the reader for a key unregistered callers, on every combination tried OpenAI never asks; the gap is four steps upstream 5. Reactive vs strategic Constraint as a command Constraint as data to weigh This quarter's metric The team, six months out Pixis: SLA set before the AI layer it fed 4 hours to under 15 minutes, 400+ customers 6. Leadership's four asks Ask "and then what," not just "did it ship" Reward the decline, not just the launch Name the downstream owner in the doc Tolerate "we were wrong" a four-field decision record beats a good instinct decided, believed, falsifier, downstream owner The bug that shipped last month was written into the roadmap eighteen months ago. The test: pick the last decision your team approved on a slide, and write the answer that never made it. Full post: hoshank.vercel.app/posts/second-order-effects Takeaways
The whole post on one card. Save it, share it, argue with it. PNG ↓

Six panels, one per section. The callout is the thesis, and the test to run on the last decision your team approved without asking what it changes downstream.

Final Words

Pick the last decision your team approved on a thirty-second slide. Write the second-order answer that never made that slide, and check who is holding it now.

Reply and tell me what you found. I am collecting the misses for a follow-up.

Cheers, Hoshank