Home About Writing Notes Books Adventures Travel Projects Say Hello
All Writing

Strategy

Transformation Is Earned in the Foothills

A
Anup Sheshadri
Product Leader · Routespring
Jun 2026 · 7 min read
Transformation Is Earned in the Foothills

A little over a year ago, I was halfway up the via ferrata at Nelson Rocks in West Virginia, clipped to an iron rung with more air beneath my heels than I'd felt in years, when something I thought I'd lost came back.

I've spent the last few years building products, scaling teams, optimizing decisions. Good years. But somewhere in them, the part of me that wanted to be exposed, physically and consequentially, on the side of something that doesn't care about your roadmap, had gone quiet. On that rock face, it woke up. And by the time I unclipped at the top, I'd thought a sentence I hadn't let myself think in a long time:

I want to climb Everest.

Not as a metaphor. The actual mountain.

Then, about ten seconds later, came the more useful thought: I cannot just go.

That was over a year ago. I half expected the pull to fade into a nice story I'd tell at dinner. It hasn't.

The gap between the wanting and the ready

Here's the thing about Everest that the summit photos never show you. The mountain doesn't care how badly you want it. It doesn't care about your motivation, your post, or your renewed sense of purpose. Above a certain altitude, your body simply begins to fail, and the only thing standing between you and that failure is preparation you did months and years earlier, at lower and less glamorous elevations.

You don't train for Everest. You train up to it.

You summit smaller mountains first. You learn rope work and crampon technique on peaks where a mistake is survivable. You teach your body what thin air feels like before you bet your life on it. You build the hard skills slowly, on ground that forgives you. Every one of those smaller summits feels like a detour when your eyes are fixed on the big one. None of them are. They are the only path that exists.

The wanting is free. Everyone on the trail has the wanting. The progression is the whole game.

The same mountain, at work

I run product for a living, and I couldn't shake how precisely this maps onto the thing every team I know is staring at right now.

AI is rewriting the landscape under our feet. The way we build, decide, staff, and ship is changing faster than any cycle I've worked through. Navigating it well is, genuinely, our Everest: an audacious, non-optional climb the whole industry is pointing at simultaneously.

And here's where I watch good leaders go wrong: they book the Everest trip.

They announce the transformation. They set the summit date, the kind of aspirational roadmap I've argued is quietly lying to everyone who reads it. They mandate that the team "become AI-native" by some quarter, and then they're surprised when capability doesn't materialize on schedule. They skipped the acclimatization: the reps, the small wins, the skill-building on low-stakes ground where a mistake teaches instead of kills. Bodies fail at altitude that way. Teams do too.

Because ambition was never the scarce resource. Everyone can see the peak. Pointing at it requires nothing but a slide and some conviction. The rare and actually valuable work is choosing the training summit, the deliberately smaller and deliberately survivable bet where your team builds real skill before the stakes get fatal, and then being patient enough to let them earn the altitude.

Here's what that looked like for us.

Before rolling AI-augmented testing across the engineering team, I didn't announce anything. I ran one pilot. We dropped a single PRD into a folder. No configuration, no setup meeting, just the document and the tool. It generated 45 test cases, and then it cross-linked them to a dependency it found in a separate document I hadn't even pointed it to. That one run did more to demonstrate the system's value than any presentation I could have built. The capability spread from there, but only because it earned its altitude on a non-critical document first.

The temptation was to announce the transformation. The actual move was to find the one safe slope and let it prove itself. It's the same restraint I wrote about in Just Because You Can Vibe-Code It Doesn't Mean You Should Build It: the ability to do more is not a reason to do more.

"But you told us to decide now"

A fair challenge, because I've written the opposite. Not long ago I argued, in The CPO's New Reality: Decide Now or Lose the Room, that the modern product leader has to decide now or lose the room, that hesitation is its own kind of failure. So which is it? Move fast, or be patient?

Both. They're not in tension once you see what each one governs.

Speed of decision and speed of capability are different mountains. A leader should decide fast: commit to the climb, pick the route, refuse to dither in the room. But you cannot decide your team into readiness. Capability compounds at its own pace, summit by summit, and pretending urgency can skip that is how expeditions die above the death zone. You decide fast. You let the team climb slow. Confusing the two, demanding capability on the timeline of a decision, is the most common way I see ambitious leaders hurt the very teams they're trying to elevate.

Patience, here, isn't the opposite of urgency. It's what urgency looks like when you're responsible for other people's altitude.

The part nobody tells you: even the strategy is earned on the foothills

There's a deeper version of this that I only understood in hindsight.

We're working toward a thesis that our platform needs to expose itself to agents, not just humans. It's a real strategic bet about where the commercial ground shifts next. And if you'd asked me to write that memo on Day 1, I couldn't have. Not because I lacked the intelligence to reason about it, but because I lacked the reps.

The conviction didn't come from a strategy document. It came from months of personally living in this world: running SQL queries without writing SQL, pulling health data off my wearables, extracting transcripts, wiring up scheduling workflows. The intuition built one small climb at a time. And the moment the thesis actually crystallized wasn't in a product meeting. It was noticing that one product was effortless for an agent to navigate (clean DOM, inspectable structure) and another was a wall, and understanding in my gut why that distinction would matter commercially within a year.

That's the part the summit-photo crowd misses. The foothills aren't just where you build skill. They're where you build judgment, the strategic insight that looks like vision from the outside but is really just accumulated reps. You couldn't have written the memo on Day 1. The foothills were the research.

What I'm actually doing about it

So I'm not booking Everest. Not this year, maybe not for several. I'm picking smaller mountains, real ones, and learning to suffer correctly on each, building the body and the hard skills the death zone will eventually demand, on slopes that let me make new mistakes instead of repeating fatal ones.

I'm trying to lead the same way. Less pointing at the peak. More choosing the next honest foothill, and protecting the time it takes my team, and me, to climb it.

Ambition sets the destination. Progression is the only thing that gets you there.

Lead the foothills, not the summit photo.

Originally published on LinkedIn. View the original →

Strategy
A
Anup Sheshadri
Product leader at Routespring. Creator of the SU-RICE prioritization framework. Author of three books on product and adventure. When not building, hiking solo through national parks.