
Recently, our CEO sent a note to the Product leadership team that really made me stop and reflect.
He made a simple but powerful point: AI-native companies don’t need leaders who have “been there, done that.” They need first-principles thinkers, because at this layer, nothing has really been done before.
That message stuck with me, and as I said, I've been noodling (obsessing even) on it ever since.
It made me reflect on where I’ve been, where I am today, and where I’m headed. Because for most of my career, experience was the currency.
You built credibility by having seen the movie before. You’d launched products, scaled teams, navigated trade-offs. You had pattern recognition. You had scar tissue. You had, as the saying goes, “been there, done that.” And if you were lucky, maybe you even got the t-shirt. For my long-time readers, that might ring a familiar bell.
But AI is forcing a reset.
Because the uncomfortable truth is this: none of us have been here before.
Not really.
Yes, we’ve built software. Yes, we’ve shipped features. Yes, we understand customers. But AI-native product development isn’t just an evolution. It’s a reorientation. And to be fair, we’ve already started making that shift.
My work on the AI effort at Bloomerang, particularly with Penny, has pushed me (and our team) to rethink how we build. We’ve stepped away from the comfort of a traditional, linear PDLC and moved toward something far more fluid. An AI-assisted approach grounded in experimentation, rapid feedback, and continuous learning.
Believe me when I say that the transition wasn’t comfortable, nor is it complete.
It challenged how we plan, how we measure progress, and even how we define “done.” There were moments where the lack of a clear, step-by-step path felt disorienting. The instinct to fall back on familiar processes was strong.
But this evolution was very necessary. Because the reality is, the old model assumes a level of certainty that simply doesn’t exist anymore. When the capabilities themselves are evolving weekly, a rigid process becomes a constraint, not a safeguard.
And now, having operated in this new mode, I can say with confidence: I wouldn’t go back.
Not because the old way was wrong, but because it’s no longer sufficient.
If we want to move faster, learn faster, and deliver truly differentiated capabilities, we have to embrace a model that’s built for discovery, not just delivery. This isn’t about abandoning discipline. It’s about evolving it to match the pace and potential of AI.
And even with that progress, we’re still early.
There’s more change required across the board. And more importantly, a deeper, more foundational transformation is still ahead of us. Not just in how we build products, but in how we think about them altogether.
Experience still matters. Just differently
There’s a narrative emerging that experience is less valuable in an AI-native world. I don’t buy that exactly. What’s less valuable is experience applied rigidly.
What’s more valuable than ever is:
- Knowing how to get to the root problem, not just the symptom.
- Understanding how work actually happens in a customer’s day-to-day.
- Being able to guide messy, ambiguous conversations toward clarity.
- Having the judgment to say, “this is interesting, but it’s not valuable”.
Those aren’t outdated skills. They’re foundational. But they have to be paired with a willingness to rethink everything else.
The UI is no longer the product
For years, we obsessed over flows, clicks, and screens.
How many steps does it take to complete a task?
How do we reduce friction in the interface?
But when agents can execute tasks on behalf of users, the interface becomes optional.
The real product becomes:
- The intent
- The context
- The outcome
Not the buttons in between. This opens up an entirely new design space which requires product managers to think beyond traditional patterns. It’s no longer about optimizing screens. It’s about orchestrating outcomes.
From certainty to experimentation
We’ve moved from a world where product managers were expected to have answers…
…to one where the best product managers are the ones who can run the best experiments.
But experimentation doesn’t start in a vacuum. It starts with deep, almost obsessive customer understanding.
That means developing a deep, firsthand understanding of how your customers actually work. Not how they say they work. Not how your product assumes they work. But how the work really happens. Step by step, workaround by workaround, frustration by frustration.
Where do they hesitate? Where do they context-switch? Where do they create manual patches just to get something done?
Those are the signals. Because if you don’t understand the workflow, you end up optimizing the surface. Treating symptoms instead of solving the root problem.
And getting there requires more than just asking questions. It requires guiding the conversation. Knowing when to dig deeper. When to challenge an assumption. When to pause and say, “Wait, why do you do it that way?”
The goal isn’t just to collect feedback. It’s to uncover truth.
Only then can you form hypotheses that actually matter, and run experiments that move the needle.
So what’s the new tagline you ask?
If I had to rewrite my own, I'd retire the old “Been there, Done that. Still waiting for the t-shirt.”
It would be something closer to:
“Haven’t done this before, but I sure as hell know how to figure it out.”
Because that’s the job now.
Not to rely on playbooks. But to write them.
Thanks for taking the time to read.
Wishing you all the best
Mike
Continue exploring

August 17, 2026
When Architecture Becomes Experience
One of the more interesting things I’ve noticed over the years is that software companies and customers often define the word platform very differently.

July 21, 2026
When a Suite Becomes a Platform
Spend enough time in enterprise software and you’ll eventually notice that certain words begin to lose their meaning. "Innovation" is one of them. "Transformation" is another. Lately, I think "platform" belongs on that l...

July 6, 2026
Invisible During the Work. Visible in the Value.
One of the more interesting conversations I've been having lately starts with a deceptively simple question. Should AI be visible?
