There's a question I kept coming back to when I took over product operations at Komodo a couple of years ago: where are product managers actually spending their time?

When I started interviewing the team, I quickly got a clearer picture, and the answer made me uncomfortable. Honestly, it should probably make you uncomfortable too.

The number one complaint? Process. PMs were drowning in it. Writing documents. Rewriting documents. Four-pagers, ten-pagers, intake forms, prioritization frameworks, design review meetings, estimation sessions. The list went on. 

When I asked how much time they were spending with customers, on discovery, on actually thinking through insights, the answer was sobering: about 25% of their time. That's it. The rest was going to documentation and specs (35%), stakeholder alignment (25%), and general product management overhead (15%). 

Bar chart titled "Where PM time actually goes," showing PM time split across four categories: documentation and specs, 35%; stakeholder alignment, 25%; project management overhead, 15%; discovery and validation, 25%. Caption below reads: only 25% of PM time goes to the work that determines if you're building the right thing.

PMs’ work should be all about making life better for the customer. By creating a system that limits their ability to do that, we were doing our customers a disservice. So, we rebuilt the process from the ground up. In this article, I'll show you how. 

Here’s what we’ll cover:

  • What was driving the old process, and why it stopped making sense
  • The three things AI changed that made a new approach possible
  • The AI-native release loop we built to replace the old process
  • How we built Navi, our internal AI PM assistant, to guide and enforce the new process
  • Five things you can try next week if your own process feels overdue a rethink

The process tax was real

As flawed as our old process was, every layer of it existed for a good reason. When engineering time is limited, and build cycles are long, you need checks and balances. You need rigor. The stage-gate compliance, the design review cycles, the product requirements doc (PRD) sign-offs, all of it made sense in a world where getting something wrong meant weeks of wasted engineering effort.

But that world has changed.

Here's what our product development lifecycle (PDLC) looked like before we started rethinking things. An idea would come in through intake, get validated, go through a prioritization framework, move into a PRD that went through three review cycles, then into design where the PM and designer would go back and forth on wireframes, then into estimation sessions with engineering, and finally into a sprint. 

All this while PMs were also managing roadmaps and product strategy work.

Diagram titled "The process tax: everything we built with good intentions." Lists eight process layers as stacked bars of increasing length: post-launch review cadences, launch readiness checklists, estimation sessions, design review meetings, PRD templates (5+ pages), stage-gate reviews, prioritization frameworks, and intake forms/Slack requests. A callout box reads: each layer added for good reason. Together? 4 to 6 weeks from idea to first line of code.

The feedback loop was long. The misalignment between what PMs were spending time on and what actually created value for customers was huge. And the artifacts – the PRDs, the Figma files, the spec documents – were becoming the goal rather than the means to a goal.

That's the thing about process tax. It compounds. Every meeting, every document, every review cycle pulls your PMs further away from the work that actually matters: understanding customers and building things that help them.

CTA Image

For expert advice like this straight to your inbox twice a month, sign up for Pro+ membership.

You'll also get access to 10 certifications, a complimentary Summit ticket, and 100+ tried-and-true templates.

This month only: Save up to 199 USD with code SUMMER26.

Get Pro+

Three things AI changed for product

To tackle the process tax, in late 2024, we started seriously evaluating AI tools. We weren't looking to bolt AI onto our existing process. We were asking a more fundamental question: what does the product development lifecycle look like when prototyping is cheap and fast?

Four things shifted:

1. Prototyping cost collapsed 

In early 2025, we introduced Cursor across the organization, and we made a deliberate decision to enable product as well as engineering. 

The reason for this was simple but important. AI has given non-technical people the ability to be more technical, and ideas come from everywhere. If it’s only engineers who can build prototypes, you're leaving a lot of creative capacity on the table.

2. Validation fidelity increased 

Previously, validation happened in scrum meetings – 30 to 45 minutes talking to QA and engineers about whether something worked. 

Now, PMs can build a prototype, validate it themselves, and walk into a meeting with something real to show. That's a fundamentally different kind of conversation.

3. Documentation got much simpler

A lot of the process tax was around creating specs and documentation. When you have a working prototype, you can point at it and say, "Write a document about this." 

The prototype becomes the source of truth, and the documentation flows from it rather than the other way around.

4. Shipping speed grew 10x