AI-Native Product Organizations

AI raises the ceiling for what your product organization can achieve.

When building gets much cheaper, a SaaS company can aim higher: solve bigger customer problems, test far more ideas, and go after opportunities that used to be too expensive to pursue. The same applies to your competitors, and to customers who can now build some of it themselves.

Getting there takes more than faster engineering. When building speeds up, the bottleneck moves to product decisions, discovery and how quickly the organization learns. If nothing else changes, you get roughly the same results a bit sooner.

I help B2B SaaS leadership teams change how their product organization works so it can reach for more, and test those changes in practice.

Where it tends to show up

Faster engineering doesn't mean faster delivery

Coding assistants can make engineers several times more productive. From idea to something customers actually use, the gain is much smaller. The work now waits on product decisions and on the level of detail engineers need to build the right thing. Product managers feel the pressure to keep up, and decisions start getting made faster with less behind them.

Extra capacity goes to the bottom of the backlog

When a team can suddenly build more, it works its way further down the backlog. Those items sat low for a reason, and many were never worth building. A clear longer-term direction matters more than before, since it decides where the extra capacity goes. Without it, the team ships more and the product barely moves.

Knowing what to build becomes the limiting factor

If you can build in days, learning what to build can’t take a quarter. AI can help gather and make sense of far more input from the market, prospects and existing customers. Few teams have connected that to how quickly insight turns into an experiment, so decisions still rest on the same few sales calls and support tickets.

Experiments get cheap, and learning needs more care

When a prototype costs a day instead of a sprint, you can afford to build many and throw most of them away. That only pays off if they test the right hypotheses, and someone captures what was learned. Without that, you end up with a folder of impressive demos and no clearer view of what to build next.

What we typically work on

Decisions and scoping - who decides what, with what information, and how product and engineering scope together so speed doesn't cost judgment
Roadmap and backlog - a direction clear enough to say no to what sits further down the list
Discovery - AI-supported customer and market insight, connected directly to what gets built next
Experiments - running many small ones with explicit hypotheses, and a habit of recording what each one taught you
Roles and teams - where broader builder roles make sense, and where deep expertise still matters

Ways to start

Most engagements start with a conversation about where you are, what you’ve already tried, and where things are getting stuck. What comes next depends on that conversation, and is often shaped around your specific situation. Three examples of what it can look like:

🛠️ Product (AI) Ops

When the day-to-day product process is what's slowing you down. A fixed, hands-on engagement to assess, improve and embed how your team works with AI, ending with your team owning it.

🧪 Your AI Lab

When nobody has had the time to find out what AI makes possible for your product and your teams. A temporary lab that runs focused experiments and is handed over to someone on your side.

🎯 Ongoing sparring or fractional leadership

When the questions are about structure, roles, strategy and hiring, and they keep coming. Recurring sparring with founders, executives and boards, or an embedded fractional role.

Why I work on this

I've spent 25+ years building and leading technology organizations, most recently as CPTO, CPO, VP Product & Engineering and CTO. At Zensai, I scaled Learn365 to 3,000+ customers, 2.5 million users and €25M+ ARR.

I also build with these methods myself. For Work2gether AI, a live AI product I built and run, I've set up a product context layer, structured product documentation that AI agents use as their working context, and an agent-led discovery process that turns a rough idea into a scoped brief before anything gets built.

It keeps my advice tied to what I've seen work in practice.

Questions worth asking your leadership team

What would we aim for if building were much cheaper, and what’s actually stopping us from aiming for it today?
If a competitor, or a customer’s own team, can build much of what we offer, what keeps us relevant in two years?
If engineering became twice as fast tomorrow, what would we be waiting on?
How long does it take from an insight to a working experiment?

Where would your product organization get stuck?

You don't need a clear answer before we talk. A rough sense of where things slow down is enough.

Let's talk about it