Don't just tolerate your product people having a side project, startup, or something they're building on their own time. Within reasonable conflict-of-interest boundaries, actively encourage it.
I've spent decades in Product, and I've always considered my purview unusually broad: requirements and user stories, yes, but also positioning, pricing, marketing, selling, adoption - the whole thing.
Years ago, I argued with a leader who became a lifelong mentor about this. I told him I tried to operate as though I were the CEO of my product line.
He reminded me that I couldn't truly claim that perspective because I didn't own the P&L.
Fair enough.
But I still think that mindset made me a better product leader.
Founding, though, is next level.
When it's your company, you can't say:
"Engineering needs to figure that out."
You have to understand why something is hard. What are the alternatives? What are you trading away? Should the integration be built or bought? Is the architecture creating constraints you're going to regret later?
And when the engineering work is happening on your own precious nights and weekends, "three weeks of development" becomes very, very real.
AI makes all of this even more consequential because the distance between idea and implementation is collapsing.
And I've noticed something unexpected: building ScopeAccord is changing how I lead Product in my day job.
01
I'm becoming much less tolerant of abstraction.
As a product leader, it's easy to operate one level above implementation.
"We need an integration."
"The agent should be able to access this."
"It's complicated."
As a founder, those statements aren't sufficient.
I find myself asking much more often: What specifically is difficult? What permissions are required? What data model are we assuming? What happens when it fails? What are we buying versus building?
That technical curiosity has followed me straight back into my day job.
02
Engineering capacity became economically real.
This may be the biggest lesson.
In a large company, engineering capacity can start to feel like an organizational resource.
As a founder, every story represents my time, my money, or both.
That changes prioritization dramatically.
The question stops being:
"Would this be useful?"
and becomes:
"Is this valuable enough to justify what we won't build instead?"
As product and engineering organizations become leaner, I think that founder discipline becomes increasingly important inside larger companies too.
03
I'm even more convinced that Product's job continues long after launch day.
The founder version of Product owns the result.
Not the PRD.
Not the roadmap item.
Not whether the feature shipped on time.
Did it work? Did someone understand it? Did they use it? Did they pay for it?
That accountability is sharpening something I've always considered one of my strengths: making informed but sometimes ruthless bets about where the market is going and thinking hard about who the future user actually is.
Increasingly, that user may not even be human.
04
AI has made technical fluency more important, not less.
There's a narrative that AI will allow product people to become less technical because anyone can prototype or build.
My experience has been almost the opposite.
AI makes creation cheaper.
Which means judgment becomes more expensive.
When there are ten technically plausible ways to solve a problem, the product leader needs enough understanding to interrogate the choices.
I don't need to become the best engineer in the room.
But I'm increasingly convinced that "engineering is a black box" is no longer a viable stance for Product.
05
The boundaries between product, technology, and business are starting to collapse.
A founder doesn't get separate boxes labeled Product Strategy, Engineering Strategy, GTM, Pricing, Customer Success, and Finance.
They are one interconnected problem.
I suspect AI-native product leadership is going to look increasingly like that too.
Not everyone needs to become a founder.
But perhaps more product leaders need to think like someone who cannot hand the consequences to another department.
Because AI may reduce the number of people required to build software. I don't yet know what that means for Product Management as a profession.
But I'm increasingly convinced that the product leaders who remain will need to own more of the whole problem, not less.
Building ScopeAccord has made me uncomfortable in exactly the right ways.
I understand more clearly what I don't understand. I ask harder questions of engineering. I'm less impressed by activity that doesn't produce an outcome. And I'm much less willing to hand ambiguity across an organizational boundary and declare my part finished.
