AI makes the First Yes cheaper
AI lowers the cost of beginning things, but it does not remove the cost of owning what begins
In my experience, the hardest product conversations rarely start with someone being unreasonable. Most disagreements come from reasonable people arguing from different versions of the truth.
Stakeholder A frames urgency through their local incentive: “We need this for a customer / launch / revenue / compliance / adoption.”
Stakeholder B frames a competing request through a different local incentive:
“This other thing is more important because it protects retention / reduces cost / supports strategy / unblocks a partner.”Product or engineering translates both requests into capacity tradeoffs: “We can do one well, maybe both badly, but not both responsibly.”
A senior HIPPO tries to resolve tension by expanding the imaginary capacity:
“Can’t we just do a lightweight version of both?”
AI will make that last move more tempting: “If it’s faster now, why are we still saying no?”
At first, that sounds like it should make organizations less political. If the cost of trying goes down, maybe fewer people need to fight for roadmap space, right?
I don’t think that captures the full picture. These political patterns are mainly about the first “yes,” but organizations have to think about the answers that come after. Software creates a chain of commitments.
AI changes product politics because it makes the first yes feel cheap while leaving the second and hidden yes just as expensive as before.
The First Yes: Can We Try It?
A lot of politics in product work has historically concentrated around prioritization because building software was expensive enough that choosing one thing clearly meant not choosing something else. Quarterly planning was literally a resource allocation ritual. The leaders gathered around limited capacity and tried to decide where that capacity should go.
This is one reason product methodologies developed so many prioritization tools. RICE, MoSCoW, opportunity scoring, opportunity solution trees, cost of delay, impact-effort matrices, outcome roadmaps, OKRs, and the rest are all attempts to make political tradeoffs easier to discuss as rational decisions.
Organizations need ways to turn disagreement into action. A good prioritization process gives people a shared language for saying, “We understand your request and we still aren’t doing it right now.”
Prioritization frameworks gave politics a focused place to happen. The roadmap holds tradeoff decisions. Headcount planning holds capacity decisions. Executive steering committees hold strategic disagreement. When the organization disagreed about what mattered, those were the rooms where the disagreement showed up.
AI will weaken some of that because it weakens one of the main arguments those rooms depended on: “We don’t have capacity to build this.”
That argument will still be true more often than people think. Teams may not have the capacity to maintain the work, support the work, understand the work, or build it well. But at the surface level, “we can’t afford to try this” will become harder to defend. If a prototype can be generated quickly, if a workflow can be automated in a day, if an internal tool can be assembled without a full team, then the first yes starts to feel almost obvious.
But then you have to ask what kind of yes you just gave.
A yes to trying is not a yes to launching. It is not a yes to maintaining. It is not a yes to making the thing part of the product or operating model. The first yes is only useful if the organization treats learning and committing as different decisions.
The Second Yes: Should This Become Real?
The second yes shows up after the trial works well enough to create demand.
That is the moment product teams need to treat more seriously. Let’s say the customer responded well to the concept, or the internal workflow saved someone time. Now the question is no longer whether the team can afford to try it. The question is whether the result deserves to become real.
That decision depends on evidence, and evidence is never as neutral as organizations want it to be.
Does “working” mean users clicked it? Does it mean customers asked for it? Does it mean a directional improvement in KPIs or a statistical one? Does it mean customer service is prepared to support it? Does it mean engineering can maintain it? Does it mean the result fits the current strategy? How much certainty do we need to have?
These questions reflect incentives. Sales may care most about customer commitments. Finance may care most about near-term profitability. Engineering may care most about maintainability. Product may care most about learning speed. Support may care most about operational drag. Each view can be legitimate, and each can distort the decision if it becomes the only view that counts.
This is where the debate gets harder to see than a roadmap fight. A roadmap decision is visibly political because the tradeoff is visible. A scoring model, success metric, experiment review, governance policy, prompt library, or definition of “production-ready” can be just as political, but it often looks like process.
The second yes is where those things matter. It is the yes that says, “This is no longer just something we tried. This deserves a place in the product ecosystem.” That yes should cost more than the first one.
The Hidden Yes: Who Owns It After Launch?
Software has a long tail. The first version is only one part of the cost.
An experiment that succeeds may become part of the product, and now the feature has to be maintained. An internal automation may save time, but it has to be adjusted when the process, data, team structure, or architecture changes. A chatbot experience may be easy to launch, but it has to be continuously evaluated, governed, and explained when it behaves in ways people did not expect.
AI may reduce the cost of creating these things, but it does not magically reduce all the costs that come after creation. In many cases, it increases them because it creates more context the organization has to understand.
A stakeholder asking for “just a quick experiment” can seem harmless until the experiment succeeds. If the team builds something lightweight and people start using it, suddenly the thing is part of how work gets done and you have to make trade-offs with existing strategy and priorities. What began as a cheap experiment now needs ongoing ownership. That means maintenance, support, ownership, and measurement need to be a part of the decision about whether it deserves to keep existing.
The cost looks like it disappeared to the stakeholder because they got their idea built cheaply. But the expense is still there for the organization. It just moved into the future and landed with whoever has to keep the thing alive.
That is the hidden yes. It often happens without a meeting.
People start using the workflow. A customer sees the prototype. A dashboard becomes part of a weekly review. A temporary automation becomes the only way a process gets done. Nobody formally decided the thing was now real, but the organization begins to depend on it anyway.
This is how cheap experiments become expensive clutter. Each experiment brings new customer or stakeholder expectations before the team has decided whether the thing deserves to exist. The problem is not that teams tried something. The problem is clarifying the consequences of trying.
“Let’s Just Try It” Needs An Owner
I generally like “let’s just try it” as a product instinct. Small bets are usually better than long arguments and a cheap experiment is usually a very good thing for learning.
But “let’s just try it” becomes dangerous when nobody owns the consequences of trying.
What are we trying to learn? Who decides whether we learned it? What happens if the result is ambiguous? What happens if we succeed? Who maintains the thing and who turns it off if it half-works? What team absorbs the operational cost? What existing priority gets displaced if this becomes real? These are not bureaucratic questions, they’re ownership questions.
AI makes those questions more important because it makes trial creation easier. The organization can say yes to more experiments, which is useful, but only if it gets better at distinguishing between permission to learn, permission to scale, and permission to create a permanent responsibility.
Cheap Trials Create Cognitive Product Debt
At first, this looks like responsiveness. The team tried something quickly to make a stakeholder feel heard. Everyone feels like progress is happening without the discomfort of a harder commitment decision.
But each one adds weight because the team now has to remember why it exists, who asked for it, what it was supposed to prove, what dependencies it created, who is using it, what might break if it changes, and whether it still fits the strategy. None of that may show up as roadmap work, but it still consumes product capacity.
This is a type of cognitive debt: the accumulation of half-owned decisions, unclear evidence, stale experiments, stakeholder expectations, and small commitments that nobody wants to count as real work.
The cycle is easy to fall into. AI helps the organization create more things. More things create more context. More context reduces the team’s capacity to make good decisions. Lower decision capacity makes it harder to evaluate what deserves to continue. So more things linger, and the team has even less room for the next bet.
That is how “let’s just try it” becomes a drag on the very responsiveness it was supposed to create.
The answer is not to stop trying things, of course. The consequence of trying needs to be made explicit before the test begins. A team should be able to say yes to learning without accidentally saying yes to permanent ownership.
Governance Should Protect The Second And Hidden Yeses
The point of governance should not be to slow down every first yes. If every prototype, workflow, or AI-assisted experiment needs a committee before anyone learns anything, you’ve recreated the old bottleneck with new language.
Governance should define the boundary between learning and committing. Use it to help a team know what type of work they are starting and what happens if it succeeds or fails.
Use it to make the next decision explicit. That means asking different questions at each stage:
For the first yes: Is this safe enough to try? Is the risk contained? Is the cost of being wrong acceptable?
For the second yes: What evidence would justify scaling this? Does it fit the strategy? Are we confident enough to create a real dependency?
For the hidden yes: Who owns maintenance, support, measurement, security, and the decision to turn it off later?
This is the difference between governance as control and governance as clarity. Bad governance slows down the first yes because leaders are uncomfortable with uncertainty. Good governance protects the second and hidden yeses because that is where cheap trials become lasting obligations.
Use governance not to add approval but to make ownership impossible to skip.
Know Which Yes You’re Giving
The organizations that handle this well are those that understand the difference between creating software and owning software.
That means treating the first yes as permission to learn, not permission to commit. A prototype can be cheap. A workflow can be useful. An experiment can show promise. But none of those things automatically deserve to become part of the product, the operating model, or the team’s permanent responsibility.
The harder question comes after the trial works well enough to create demand. Is the evidence strong enough? Does this fit the product strategy? Can the system support it? Who maintains it? Who measures it? Who answers when it breaks? Who gets to decide when the thing has run its course?
AI makes the first yes easier, which means teams need more discipline around the second and hidden yeses. Otherwise organizations will create product debt that does not look like product debt at first. It will look like momentum, responsiveness, and experimentation until enough of those cheap trials become permanent responsibilities nobody clearly chose.
The old product fight was often about getting onto the roadmap. The new fight is about what happens after the roadmap no longer catches every commitment.
AI may make it easier to start, but software still has to be owned. The teams that handle this well will not be the ones that say yes to everything or no to everything. They will be the ones that know exactly which yes they are giving.