I spent most of 2025 staring at a backlog that never dropped below 147 items, convincing myself the problem was prioritisation.
It wasn't and the math wasn’t mathing.
We had limited engineers. The backlog represented 60 months of work yet everything had be delivered next quarter.
No amount of prioritisation fixes a 30x resource gap. You just shuffle which stakeholders you disappoint first.
Most product managers I know have learned to live with that. Eighty per cent of the job is explaining why things can't be built, managing stakeholder disappointment, and doing competitive research on startups with zero tech debt, engineers for days and fifty million dollars in the bank. Twenty per cent is the actual work.
That ratio is backwards. For a long time, I thought the only honest answer was, this is just the job now.
Then AI started changing the equation. It cut the busywork that has plagued PMs for years, and it cut the time it takes to build. It didn't solve everything, and the part it didn't solve turned out to be something unexpected.
What AI changed
The first shift was in the low-value, high-volume work that used to eat hours every week.
Support ticket analysis used to mean reading hundreds of submissions by hand, looking for patterns and trying to separate signal from noise. Now I can collate, categorise and summarise them in minutes. Customer feedback used to sit in a spreadsheet for months before anyone synthesised it properly. Now it's done in an afternoon.
The bigger shift was in how ideas move from concept to specification.
I used to iterate endlessly with design and development before we had anything tangible to evaluate. Now I can take a rough idea, work it through with AI, and have a working prototype, something you can see and click through, before the team is involved. Instead of trying to describe what something might be, I'm showing what it is. Feedback comes faster and it's clearer and more useful.
The PRD process changed too. I can work through a specification with AI, surface problems before engineering touches it, and produce a document that serves every internal team, not only development. Sales understands what's coming and why. Support can prepare. Marketing can plan. Services knows what to expect. A spec that used to take days to write, circulate and revise now takes hours.
Then engineering sped up. AI-assisted development means a six-month roadmap that once felt like a reasonable target can now be built in weeks.
Sounds like all your dreams have come true. They haven't.
Where the pressure and debt went
AI took debt out of engineering and put it somewhere else. Over the past few months I've watched it land in three places.
Design. I built a 19-screen chatbot and admin portal, gave the AI a style guide, and asked it to build a reusable design system. Eighteen screens drifted anyway, with 873 off-script design decisions, including the same grey written four different ways. I wrote that up in How One Blue Became Four Blues .
The product foundation. On a platform rebuild, development outran product, design and QA. We got a working technical MVP without a coherent product underneath it: inconsistent flows, unclear error states, no shared definition of done. That's A Technical MVP Isn't a Product .
Product decisions. This is the one this piece is about. When building is cheap, the hard part is deciding what gets built at all, and how much of it.
None of these were in the AI playbooks.
The new problem is over-engineering
When building was slow and expensive, the hard decisions made themselves. You didn't have the people or the time, so you cut scope and shipped the simplest thing that would work.
Take that constraint away and something else happens. AI-assisted development makes things that used to be hard feel easy, so the instinct is to keep going. Add another feature. Extend the integration. Make it more configurable. Handle one more edge case. Each addition takes an afternoon, so none of them feels like a decision.
The first time I noticed it was our engineering team building because they could, not because they should. We had a sprint with one job a simple bug fix. Engineering decided to pull in a tech debt item we'd shelved months earlier, because with AI it suddenly looked quick to knock over. Nobody needed it for the fix.
That one decision brought back complexity and risk we had deliberately parked. QA now had a much bigger change to validate, and the simple fix customers were waiting for got delayed.
A simple build turned into a complicated one that took just as long as the old way, and came with more complexity to test, document, support and maintain. We'd saved the time on building and spent it again on scope creep.
AI makes ideas cheap and plentiful. Everyone has more of them, and they arrive faster and more confident than anyone can decide whether they're worth pursuing. Ideas that would never have made it past a planning meeting when engineering time was scarce now get built because it's quicker to build than to talk about them.
The one I didn't see coming
The pressure also moved to our customers. Some of them struggle with their own internal change management. For them, frequent releases are a burden. Every update means internal communications, retraining and updated documentation. We could ship three times as fast. That doesn't mean we should.
Is shipping the goal?
Is shipping things customers never asked for, never expected and don't use a successful product?
I've watched teams celebrate release cadence as though shipping is the goal. It isn't. The goal is customers getting real value and using what you've built.
A product that ships constantly but delivers nothing anyone wanted is noise.
So you still have to ask yourself. Is this solving a real problem? Will people use it? Is this the simplest version that does the job? Building faster makes those questions more urgent, because the cost of skipping them now shows up as complexity as well as delay.
Engineering can build almost anything now, so the question is whether it should be built at all. That takes real conviction.
The same lesson has come up in design work, the MVP rebuild and here.
The faster we can build, the more deliberate we need to be.
What doing the job properly looks like
I'm not going to claim I've solved it. But I can tell you what's different.
I'm not chasing my tail any more. I have automated insight into what customers are experiencing, so I'm not relying on escalations and gut feel. I have specifications that take hours instead of days, and that brief every team instead of only engineering. I can prototype and test ideas with customers before they consume sprint capacity.
That gives me time I didn't have before. Time to talk to customers properly. Time to think about where the market is going. Time to decide what to build and what to leave alone.
It turns out it was always a prioritisation problem. What changed is the reason. I used to decide what not to build because we didn't have the people or the time. Now I decide what not to build because it isn't needed, even when we easily could.
That's the actual work today, validating that something is worth building, keeping it as simple as it needs to be, and defending that decision even when engineering says "we could ship this by Friday".
For the first time in a long time, the PM role looks like the job it was actually supposed to be.
I kept asking what this looks like in practice, so I built something. Next up is Product Forge , an AI-first product tool for PM teams, and how I fell into the very trap I just described.
