On AI, hold your horses has never been truer. The hype moves faster than most people's ability to use it well. But holding your horses only works if you have a stable to put them in.
Every experiment you run, every tool you try, every workflow you test, that is how the stable gets built. The infrastructure doesn't come first. It emerges from the doing. So don't wait on the sidelines. Experiment now, precisely because you're not ready. That's the point.
Leaders treat onboarding as something that happens to them. It isn't.
Most leaders ramp up by osmosis. Meetings, gradual pickup, weeks of piecing things together. There is a better frame for this: High Velocity Context Acquisition. Absorbing institutional knowledge deliberately and fast, rather than waiting for it to come to you.
A strong engineer joining a new codebase doesn't read every file. They map the architecture, find the hot paths, ask targeted questions. A new PM pulls the roadmap, the OKRs, and the last three retros before anyone briefs them. Context first, contribution second.
Ramping up is not something that happens to you. It's something you do aggressively and intentionally.
Product and Engineering often get trapped in a mirror-image reactive loop, both prioritizing immediate noise over market-shifting bets. The side effect is that the entire organization then starts optimizing for the present, while the future gets starved.
The result is planned self-obsolescence: solving problems with precision while competitors build what the market actually needs next.
We are recreating every anti-pattern from software engineering.
Teams are grouping AI tools into generic buckets:
❌ "utility_skills"
❌ "helper_agents"
❌ "common_prompts"
THE SAME MISTAKE we spent years unlearning in code!
Generic groupings hide intent. A skill called "data_processor" could do anything. An agent in "helpers" reveals nothing about its purpose.
Specificity forces clarity. Name it for what it does. Period.
The pattern that killed maintainability in codebases is now killing discoverability in AI.
Why is it that engineering refactors code continuously without hesitation, but Product keeps legacy features running for years?
Because removing doesn't feel like progress. And it's rarely treated as such.
But what you miss is that the features you aren't touching are accruing debt.
It's called Product Debt.
Just like engineering debt slows development, product debt slows everything. Velocity. Clarity. User experience.
The difference? Engineers inherently know when code might break. PMs rarely see when features are breaking the product.
Picture this: Your team built an internal analytics dashboard two years ago. Usage is low but consistent. A vendor now offers the same capability, better integrated, at lower cost.
The team says: "It's working. Why risk the migration?"
So you keep maintaining it. Small bugs get fixed. Edge cases handled. New hires get onboarded to "how our dashboard works."
❌ Meanwhile:
That's product debt compounding!
🎯 Here's what removal actually unlocks:
The features blocking your roadmap aren't the ones you haven't built yet. They're the ones you're afraid to remove.
Engineers refactor to ship faster. PMs need the same instinct—prune to scale.
What feature in your product is accruing debt right now?
Stop trying to think outside the box. Build a smaller box.
Struggling to find ideas? You have a constraint problem. Either you lack them, or you are honoring fake ones.
Take product work. Your team is stuck on reducing abandoned carts.
Everyone agrees the checkout needs to be "smoother" and "more intuitive." But you can't arrive at a specific direction.
Apply a hard boundary: "Reduce abandoned carts using only email. Zero changes to the codebase."
The problem sharpens immediately. You can't hide behind vague UX improvements. The constraint forces actual ideas.
It also works in reverse.
You won't ship until the backend "scales properly." You are optimizing for traffic you don't have.
Challenge that. Are you solving tomorrow's problem while today's users wait? Let real usage expose the bottlenecks.
Premature optimization isn't protecting quality. It delays learning.
When the problem is too open, you drift.
When it is tightly bounded, or when fake boundaries are removed, you build.
Most product teams treat outcomes like a report card. Did we hit the number? Did we pass or fail?
But an outcome isn't a grade. It's how you settle a bet.
Every item on your roadmap exists because someone made a hypothesis: "If we build this, user behavior will change in this specific way."
That is a bet. The roadmap is simply how you fund it.
Consider a standard activation problem:
🎯 The bet: Removing friction from onboarding will grow our market share.
🛠️ The output: Shipping the shortened onboarding flow.
📊 The target outcome: A 5% increase in new user activation.
If you hit that 5% activation target, but your market share doesn't move at all, you didn't fail at execution. You just lost the bet. Your hypothesis about what actually drives market share was wrong.
That is the actual feedback loop of product development.
When you treat outcomes as a report card, a missed target means the development team failed. When you treat outcomes as the settlement of a bet, a missed target means the strategy failed.
One punishes the team. The other corrects the system.
Once during a call, a customer walked me through a problem they were stuck on. Halfway through though, I had to interrupt them.
"We built that." I said, "Six months ago". Well, no I didn't mention "Six Months ago" That was me repenting.
Their face lit up. Problem solved.
But in my head I kept thinking — SIX MONTHS. Six months they worked around this. Six months of value sitting there unclaimed.
We shipped it. Watched the Dashboard. Numbers moved. Just not the way we expected.
We had strong signals when we prioritized that problem, but we shrugged and moved on to the next thing that was also giving us strong signals. Probably to repeat the whole thing again 🤷🏼♂️
Just because you have solved the problem, does not mean that the problem is solved for your customers.
Shipping is not done. Done is when the customer's behavior changes.
Everything before that is just work in progress.
Agentic Products are the future, we need to pivot immediately. Let's put a strategy together to become a market leader.
vs
We know AI agents are growing fast, let's find out which of our customers are demanding it, deliver a small slice in next 4 weeks and measure adoption.
At the end of the quarter, one of them has the data, the other has the deck.
Snap.
The pencil tip shattered.
Marcus didn't notice. He was stabbing "FOLLOW-UP MEETING" into his notebook for the third time this month.
Same problem. Different Tuesday. Eleven people with eleven solutions and nowhere to put them.
The pencil had seen it coming since 2 PM.
Mike wanted a redesigned onboarding flow. Someone pitched better email campaigns. Another PM had activation metrics pulled up. Nurture sequences. Pricing experiments. Feature discovery improvements. The solutions kept multiplying.
By 2:47, everyone was talking over each other. Confident. Certain. Unheard.
The pencil understood what they didn't: "increase user retention" wasn't a problem. It was a mirror.
Marketing saw email engagement. Marcus saw product stickiness. Mike saw first-run experience. Three different interpretations of the same vague goal.
When someone said "let's regroup next week," Marcus pressed down hard.
The graphite couldn't take it anymore.
Two weeks later, he found the broken pencil in his drawer. Sharpened it. Walked into the meeting room.
"Get trial users to create their first project within 48 hours."
Twenty minutes. Two options. Done.
The pencil stayed whole that day. Turns out it only breaks when the problem's too blunt to solve.
The magic is in how fast you complete the loop.
Sounds simple, rarely is.
