The 72-Hour Ramp
On arriving ready before you should be
By day three at Ren, I was in a product conversation that would have taken me months to participate in meaningfully at any other point in my career.
Not because the domain was simple. The company operates in a space layered with regulatory nuance, enterprise buyer complexity, and the kind of organizational friction that takes most product leaders a full quarter just to map. I’d been there seventy-two hours. I hadn’t memorized the roadmap. I hadn’t read every PRD or sat through every customer call recording.
And yet I could contribute. Really contribute, not just nod along.
That’s worth examining.
The Pattern You Carry
Over a decade of B2B product work leaves you with something that doesn’t show up on a resume: a set of instincts about how organizations actually move.
Enterprise buyers don’t want a new platform to log into. That’s not laziness, it’s rational. Every new tool is a change management problem, a training burden, a security review, a contract. Meeting customers where they are isn’t always a nice-to-have; sometimes it’s the price of admission.
Privacy and compliance aren’t features you add before launch. They’re structural decisions that shape everything downstream: how data flows, who owns what, what you can and can’t promise in a sales conversation. Treat them as afterthoughts and you’ll rebuild twice.
Security is the same. Bolting it on at the end doesn’t work in enterprise. It never did. The buyers who matter figured this out before you did.
And trust precedes product adoption. Always. In institutional markets especially, the first question isn’t “what does it do?” It’s “who else uses it?” and “who sent you?” The product has to be good, but it doesn’t matter until the relational layer is established.
These patterns don’t belong to any single industry. They travel. When I showed up, I wasn’t starting from zero. I was translating a familiar set of problems into a new vocabulary.
What AI Handled
What I couldn’t carry in was context.
How is the product actually built? Where are the architectural constraints? What decisions were made two years ago that are still shaping what’s possible today? What does the codebase say about where the team’s attention has been?
In a normal engagement, acquiring that context takes weeks. Meetings, documentation, developer walkthroughs, slowly building a mental model while trying not to ask the same question twice.
Because the right context was queryable, I could go directly to the source. One prompt and I had real answers. Not a summary someone prepared for me, not a filtered version shaped by what someone thought I needed to know. The actual architecture, the actual constraints, the actual state of things.
That changed the timeline entirely.
By day three, I had enough technical context to pair with the pattern recognition I’d walked in with. I wasn’t guessing about what was feasible. I wasn’t asking engineers to slow down and explain basics. I could engage at the level the work required.
This doesn’t require being built AI-native from day one. It requires that the right information — codebase, past decisions, architectural constraints — is accessible to AI and that someone knows how to query it. A traditional product and engineering team that has instrumented their context this way gets the same result. The setup matters more than the origin story.
Why the Combination Is the Point
Neither half of this works alone.
Pattern recognition without context is confident and wrong. You arrive knowing how enterprise buyers behave in general, but you don’t know which constraints are real at this company, which decisions are already made, which technical debts are load-bearing. You make calls that feel right and miss.
Context without pattern recognition is just information. You can read the codebase, understand how it’s built, map every dependency, and still not know what to do with it. Knowing how something works doesn’t tell you what customers actually need, which compliance issue is the one that’ll kill a deal, or why the enterprise buyer went quiet after the demo.
What made Day Three possible was both at once. And what made both at once possible was context being structured in a way that AI could actually surface it.
A lot of companies have AI tools available. Fewer have thought seriously about what information those tools can actually reach. The codebase might be there, but what about the decisions that shaped it? The constraints that aren’t written down anywhere? The reasoning behind the architecture choices made eighteen months ago? That’s the context that takes weeks to extract through meetings and walkthroughs. When it’s queryable, the timeline compresses.
What This Means
The conventional assumption in B2B product leadership is that domain expertise is the thing. Hire the person who already knows the market, the buyers, the regulatory landscape. In highly specialized or regulated industries, that instinct is often right.
But domain expertise and fresh perspective aren’t the same thing. Sometimes what a team needs is someone who can see the system without having grown up inside it. The problem has always been onboarding debt: getting a new person contextualized fast enough to contribute before their outside view gets absorbed into the existing mental model.
That usually takes months. And most organizations can’t afford to wait that long for a new perspective to activate.
What changes when context is queryable is that timeline. It doesn’t matter whether the company was built AI-native or adapted an existing setup. What matters is whether the right information is accessible, and whether someone knows how to use it. Context that used to require weeks of meetings and documentation can be acquired in days.
The bottleneck to contributing in a new market was never really domain knowledge. It was time. And that’s a different problem to solve.
Anthony Russo writes about navigating the gap between where markets are and where they need to go. Building Through Friction publishes when there’s something worth saying.
Your post reminds me of Boris Cherny’s talk on Claude code and how they use it for onboarding at Anthropic. “Before onboarding used to take 3-4 weeks, now it take 3-4 days”…it’s pretty remarkable what context has brought to the onboarding experience