There is something interesting happening with AI. Developers are vibe coding entire applications, lawyers can get AI to analyse contracts, and doctors can use AI to help diagnose patients. Knowledge that previously took years to acquire is becoming much more accessible.
This is obviously going to change how we work. But I think we might be looking at the wrong part of the equation if we focus primarily on how much faster AI allows us to produce things.
What happens when producing the answer is no longer the hard part?
If you can get an answer to almost any question, perhaps the more important skill is knowing which questions to ask. Not just asking better questions, but asking the questions nobody else thought of asking. To borrow the idea behind Steve Jobs’ famous quote about hiring people who can tell you what to do, rather than simply following instructions, the value shifts towards people who can identify what should happen next.
And I think this has some pretty interesting implications for Product Management.
The feature factory on steroids
Let’s start with software development.
For years, one of the constraints in software development has been the time and effort required to implement a feature. There were only so many developers, only so many hours in a sprint, and only so much that could be delivered in a quarter. AI is changing that equation. A developer can now build a prototype in hours that might previously have taken days or weeks.
Sounds great, right?
Well, imagine a product team where everyone can suddenly build almost anything they can think of. Sales wants a new dashboard. Marketing wants an AI assistant. A customer asks for five new filters. Management has an idea for a new workflow. And why not build it? With AI, it is suddenly cheap and easy. The problem is that the cost of implementing a feature is only a small part of the total cost of having it.
Every feature adds complexity. It needs to be understood, tested, maintained, documented, and sometimes integrated with other functionality. It competes for the user’s attention. And the more features we add, the harder it becomes to make the product intuitive. We could easily end up with products that are technically more capable but actually less useful.
In other words, AI could give us the Feature Factory on steroids. We would be producing more features than ever, without necessarily creating more value for customers. And the irony is that the easier it becomes to build software, the more disciplined we need to become about what we choose to build.
But it only takes a few hours!
There is another challenge. Stakeholder management.
For years, product managers could point to development capacity as a constraint. We simply didn’t have the time to build everything, and prioritisation was necessary. But what happens when a stakeholder comes to you with a working prototype and says: “Look, I built this over the weekend. Why can’t we just put it into the product?”
Arguing that the development team is busy suddenly becomes a much weaker argument. And perhaps the stakeholder is right. Maybe it really would take only a few hours to implement the feature. But that doesn’t tell us whether customers need it, whether it supports our product strategy, or whether it is the best way to solve the underlying problem. A working prototype proves that something can be built. It doesn’t prove that it should be built.
This means that product managers need to become better at explaining why the answer is no, even when the implementation effort is almost negligible. And not just saying no because we have other things on the roadmap. We need to explain the opportunity cost, the impact on the product, and what we have learned about the problem we are trying to solve.
Perhaps the right answer is to test the idea with customers. Perhaps we can solve the problem by improving an existing feature. Perhaps the problem isn’t important enough to solve at all. The objective isn’t to stop people from experimenting with AI. Quite the opposite. Let everyone experiment. But we need to distinguish between building a prototype and deciding to add permanent functionality to a product. The role will become increasingly strategic.
What happens to prioritisation?
This also challenges some of the assumptions behind our traditional prioritisation frameworks.
Take RICE, for example, where we consider Reach, Impact, Confidence, and Effort.
If AI reduces implementation time from weeks to hours, effort becomes a much less useful differentiator. A feature that previously looked expensive might suddenly appear almost free. But the effort required to understand the problem hasn’t necessarily changed. Neither has the work required to validate assumptions, understand customer behaviour, or determine whether a solution will actually create value.
We need to think differently about effort. The relevant investment is not just the time required to write the code. It includes discovery, validation, implementation, and the ongoing cost of maintaining the solution. Sometimes the best investment is a few customer interviews. Sometimes it is analysing existing usage data. Sometimes it is building a prototype in an afternoon. And sometimes it is deciding not to pursue an opportunity.
We should be asking: What is the cheapest way to reduce the uncertainty that prevents us from making a good decision? And that is a very different mindset from estimating how long it will take to implement a feature.
And what about the developers?
I think this is equally interesting from the developer’s perspective.
For a long time, developer productivity has often been associated with writing code, solving technical problems, and delivering functionality. And rightly so. These are difficult skills that create enormous value.
But if AI can generate a substantial amount of the code in minutes, we need to rethink what it means to be a productive developer. I don’t think the answer is that technical skills become less important. Quite the opposite.. Having technical knowledge about what can be done, what cannot be done, and what is likely to cause problems becomes even more important when AI can generate plausible solutions so quickly.
Someone still needs to understand architecture, security, integration, performance, and maintainability. Someone needs to recognise when the generated solution is fundamentally wrong, even if the prototype looks impressive. The difference is that technical expertise becomes less about the mechanics of producing code and more about using that expertise to make better decisions.
And there is another opportunity here. Why should developers only become involved once the requirements have been defined? Developers often have valuable insights into the problem itself. They may recognise that a requested feature is unnecessarily complicated, that an existing capability could solve the problem, or that a completely different approach would work better.
In an empowered product team, those insights should be part of discovery, not something we wait for until implementation begins.. A developer who helps the team avoid building ten unnecessary features and instead delivers one solution that genuinely improves the customer experience may create far more value than someone who writes thousands of lines of code. That doesn’t mean every developer needs to become a product manager. But it does mean that we should stop treating code production as the primary evidence of developer productivity.
This is why the Product Operating Model matters
And this brings me back to the Product Operating Model.
If we continue operating as a Feature Factory, AI will simply allow us to produce more output, faster. We will still have stakeholders pushing for features, teams working from requirements, and roadmaps filled with commitments that may or may not create value.. We will just do it more efficiently.
The Product Operating Model offers a different approach. Empowered, cross-functional teams work towards outcomes rather than simply delivering features. Continuous discovery helps us understand customer problems before committing to solutions. Product vision and strategy provide direction, while outcome-driven OKRs help us understand whether we are actually making a difference.
The Product Trio can explore alternatives together, using AI to prototype ideas, test assumptions, and learn faster. Opportunity Solution Trees can help us connect customer opportunities to potential solutions rather than jumping straight to the first idea someone suggests.. And perhaps most importantly, the organisation needs to understand that product teams are accountable for creating value, not for implementing every request that comes their way.
This requires better stakeholder communication, stronger product leadership, and a shared understanding of how prioritisation decisions are made. And it also requires a different way of measuring productivity. If we reward teams primarily for the number of features shipped, we shouldn’t be surprised when they ship more features. If we want better outcomes, we need to measure and discuss those outcomes.
AI doesn’t eliminate the need for a good operating model. It exposes the weaknesses of a bad one.
So what becomes valuable?
I think we are moving towards a world where execution becomes cheaper, while judgement, problem framing, and the ability to recognise valuable opportunities become relatively more important.
The ability to ask good questions has always mattered. But when answers become cheap and readily available, the ability to identify the right questions becomes a much more powerful differentiator.
For developers, that means combining technical expertise with a deeper understanding of the problems they are solving. For product managers, it means spending less time coordinating output and more time discovering opportunities, challenging assumptions, and helping the organisation make better decisions.
And for leadership, it means creating an environment where people are rewarded for solving the right problems, rather than simply producing more stuff.
Because in the end, the objective was never to build more software. It was to create better products that solve meaningful problems for customers.
AI just makes it harder to use the cost of implementation as an excuse for not making the right decisions.
When everyone can build, the real competitive advantage is knowing what is worth building.
Leave a Reply