Why product managers need to think past the first win.
We launch. We win. We smile.
And then, something unravels. Support queues spike. Users are confused. Teams point fingers.
That’s exactly what second-order thinking is for.
It is a mental model that needs to be in every PM’s handbook. Not to ruin the party, but to make sure it doesn’t end in chaos.
Here’s how I explain it to my team:
It’s the ripple effect. Focused only on what can go wrong.
Not just what breaks in the code, but what breaks because something worked too well. It’s a survival skill. It’s the thing most people don’t make time for until it’s too late.
Let’s make time now.
The Feature That Made a Car Cheaper Than Coffee
We once worked with an OEM who wanted automatic discounts on vehicle search results. Seemed harmless. Show cheaper prices, attract clicks.
Only problem?
The price math got weird. Really weird.
Combine leasing logic with high down payments — suddenly, a luxury vehicle looked cheaper than a latte.
We had to ship a down payment targeting a hotfix in a week.
Hotfixes mean lower test coverage. That means bugs. That means fire drills.
Yes, we finally built a feature we’d been dragging our feet on.
No, that wasn’t the plan.
You get the picture. One small change. Big ripples.
The CMU Project That Almost Backfired
Back in grad school, we were designing a disaster relief system with Eaton for Puerto Rico.
Idea: pedal-powered fridges. Low tech, high value. Keeps food fresh. Keeps kids occupied.
Then we hit the session where we asked, “What could go wrong?”
Turns out — kids pedal, burn calories, get hungrier.
Food runs low. Supply chains are already broken.
And now, our solution makes the core problem worse.
We shelved it. Painful, but right.
Second-order thinking saved us from delivering a feel-good disaster.
The Standup That Spiraled
Early in my management journey, I thought it would be fun (and useful) to rotate who ran our daily standups.
The idea: everyone stays engaged, and junior PMs get a low-stakes leadership rep.
The reality: six versions of the same meeting, and zero consistency.
Some kept it short. Some added new questions. Some forgot entirely.
Updates got scattered. People followed up in DMs. A few blockers got missed completely.
The whole thing slowed us down more than it brought us together.
It wasn’t a disaster. But it made something that was supposed to build alignment quietly erode it.
That was the ripple.
One small decision, made with good intentions, led to confusion, fragmentation, and a bunch of “Did we already talk about this?” moments.
Even small rituals hold systems together. Mess with them without clarity, and you mess with everything around them.
The Project I’m in Right Now
Right now, I’m in the middle of a massive client launch. There are multiple projects running in parallel, each with its own deadlines, dependencies, and mini fires. The team’s heads are down. The finish line is getting closer.
But here’s the part no one wants to think about: what happens next?
If this launch goes well, usage will spike. That means more support tickets. More questions. More operational strain. The internal team will need to pick up the next phase. But do they even know that yet?
There’s no post-launch plan. No clear owner. No stability buffer. And that’s the problem. When you’re running this fast, second-order risk isn’t just likely. It’s guaranteed.
So, here’s what we are pushing for:
- Defining processes to support the client. Not just a handoff doc, but a real support system. One that aligns teams around onboarding, ticket triage, and customer success workflows.
- Building a pod of PMs responsible for this client. Because “who owns what next” should never be a mystery. This pod is the future spine of platform expansion. They’ll know the client, the product, and the pressure.
- Accepting the hard truth: if people don’t use this, we’re screwed. Adoption isn’t optional. It’s the only validation that matters. If we don’t plan for behavior change, we’ll be explaining metrics instead of celebrating them.
- Bake the platform impact into every feature from here on out. This isn’t just a launch. It’s a system. Every new build touches other systems, workflows, and people. Features don’t live in silos — neither can roadmaps.
This isn’t about being dramatic. This is about facing what happens when you succeed.
If success is the only thing you’re planning for, you’re setting yourself up to get blindsided by your own wins.
Use This Blueprint (Literally!)
You don’t need a strategy doc. You need a ripple check.
Blueprint Name: Ripple Radar
Focal Point:
Start with the decision. A new feature. A policy shift. A strategic bet.
Feature or execution layer:
- What visibly changes in the interface or workflow?
- If it’s a feature: what screens, steps, or flows change?
- If it’s a company decision: what roles, rituals, or rules shift?
User or stakeholder layer:
- What new behaviors, confusion, or reactions might show up?
- What will customers or end users now expect?
- What will internal teams assume, adopt, or resist?
Org layer:
- Who owns the follow-up? The fallout? The mess?
- Which teams need to respond, scale, explain, or defend this?
- Are handoffs defined or left to chance?
System layer:
- What downstream platforms, flows, or metrics take the hit?
- Where do dependencies break?
What future plans now need to shift?
You can run any feature, launch, or strategy decision through this framework. Assign owners to each layer in your pre-launch, pre-rollout, or leadership meeting.
Make it part of your product rituals.
Use it in leadership reviews.
Use it when someone says, “Let’s just try this and see.”
Because the ripple effect is already happening. You just haven’t mapped it yet.
Want to sound like a leader? Start sounding paranoid
Not about the launch.
About what happens because the launch worked.
Final Thought
Second-order thinking isn’t negativity.
It’s about building the part of the system you haven’t met yet.
You don’t win by avoiding failure. You win by anticipating it.
That’s the job. That’s product leadership.
