Product consultant Rich Mironov describes a familiar sales request: “This is a quick win! The customer says it’s trivial. Just adding a dropdown or a new data value or moving a button.” Mironov, who runs Mironov Consulting and advises product leaders, says engineers use “quick win” literally, to mean a small, safe, reversible change. Sales and marketing staff use it to ask for urgency and to skip normal scheduling and technical review. In his words, “Urgency and simplicity are in the eyes of the requestor.”
Agents remove the old excuse for saying no
Mironov writes that until 2025, “engineering throughput was the main bottleneck to getting more things done.” Over-committed roadmaps gave product managers an easy answer to a flood of requests: the team did not have the capacity.
If a coding agent can take a ticket and produce a pull request, that answer disappears. The temptation, he warns, is to let agents work through the whole backlog on their own.
Tickets describe wishes, not solutions
Mironov argues that most customer requests lack context and propose an incomplete fix for a problem the customer only partly understands. His examples include a sorting request that could force the database into extra work and multiply CPU costs by nine, and a shortcut in account creation that could break know-your-customer and anti-money-laundering rules. A third would show advanced features to lower-tier customers and undercut a €6.5M-a-year revenue model. His summary: “Tickets are wishes, not specs, and agents grant wishes literally.”
His proposed fix has two steps. Agents first screen each incoming request for conflicts with product goals, regulatory exposure, and performance risk. Product, engineering, and design leads then spend a weekly half-hour on the rejected items, approving requests that turn out to be safe and correcting the agent’s screening rules.
The screen is only as good as the constraints written down
Mironov’s examples are illustrations, not measured results, but they are plausible. A ticket usually omits the pricing, compliance, and performance constraints that a long-serving engineer would apply from memory. An agent works from what the ticket and repository contain, so constraints that live only in people’s heads are invisible to it.
The same limit applies to the screening agent: it can only flag risks someone has written down for it. The weekly review covers rejections, not approvals that slipped through. A team adopting this should also spot-check a sample of approved requests until the screening rules have a track record.
Writing down which constraints matter, such as revenue dependencies, regulated flows, and expensive queries, is work a team needs whether or not it automates its backlog. Once agents make building cheap, that written judgment is what separates a quick win from an expensive mistake.
End of article