“This is a quick win! The customer says it’s trivial. Just adding a dropdown or a new data value or moving a button. Probably only 10 lines of code. Your team can knock this out in an hour.”
There are quick wins, even in Engineering and Product and Design. But the revenue side of the house doesn’t mean what we mean by “quick wins.”
On the R&D side, we use those words literally. Small, easy, safe, reversible changes to our complex applications. But our sales and marketing folks say “quick wins” to convey urgency and an unwillingness to go through the regular development process. They push us to agree that something should skip our regular scheduling and technical review. Sometimes they even say the last part out loud… “We might have already committed to it for delivery next week.”
Urgency and simplicity are in the eyes of the requestor. And overall demand is infinite. Every customer-facing person at your company has a shopping list of critical things for us. And when we deliver a few quick wins, we reinforce the idea that we could do even more of them – if only we appreciated how truly important that next request is.
The Old World
Until a year ago (2025), engineering throughput was the main bottleneck to getting more things done. So the bottomless appetite for “just one more urgent, trivial-to-do thing” from every customer and executive ran smack into over-committed roadmaps. Product managers had the easy excuse of limited resources. We pushed thousands of unscrubbed requests deep into the backlog, never to be seen again.
I traditionally recommended sliding a few quick wins into each sprint:
- Budget a little time each week for good hygiene
- Have the team keep a list of known bugs, small UI improvements, minor refactoring, pet peeves, really-will-take-an-hour stuff for hygiene time
- When someone is blocked elsewhere, they can also pull from that list
The New World
Now, auto-generating code from one-line requirements is almost instantaneous. Delivery expectations are way ahead of reality. And there’s a temptation to pipe our backlogs directly into Claude Code – to autonomously build and ship everything that any customer has ever asked for. Here’s why that will be a disaster. [1]
We know – but rarely say – that most customer requests should never be implemented exactly as written. That they lack context. That most tickets propose a wrong or incomplete solution to a partially understood problem. That judgment, interpretation, impact analysis and thoughtful discards are still needed in the AI age. For instance:
- “I need that report sorted this other way.” Blows up the database by sorting 22M rows on an unindexed field every 3 minutes, slows all users down to a crawl, 9x CPU costs.
- “We’re getting lots of complaints about our password recovery process.” Which our cybersecurity team put in place to balance ease of use against AI bot intrusions.
- “Users in our Bronze pricing tier need access to that advanced analysis feature.” But that feature drives most of the upsell to our Silver tier, and brings in €6.5M/year. Giving it away would crush our revenue model.
- “We need to skip Step 6 in our bank account creation step for certain customers.” Might violate Know Your Customer/Anti-Money Laundering laws and put our CFO in jail.
- “Add ‘Bad economy’ to the list of reasons customers say they cancel subscriptions.” Sensible, but it would return a new value from our Closed_Account API. Other internal and partner apps won’t expect it, so may error out.
- Ticket A: “Add these two menu items.” Ticket B: “Reorganize menus into more intuitive groups.” Ticket C: “Hide rarely used commands in an ‘Other’ dropdown.” Ticket D: “Give users a choice of British English or American English spelling on menus: Colour/Color, Analyse/Analyze.” One of our design/UX leads needs to own a sane and stable list of commands.
Of course, there are a lot of safe, thoughtful, low-impact tickets and requests. But not all of the obvious no-brainers are actually no-brainers. Product managers and maker teams have a deep understanding of how the system should work. And know where some of the landmines are buried.
The push to fully autonomous code creation is relentless. Every AI frontier company and strategic consulting firm is selling it; GTM executives are embracing it. It addresses real costs and also the perceived time-wasting of product-side processes. And is not going away. But it conflates speed with value; code with product; expert judgment with inefficiency. Slogans with realities.
A Two-Step Filter
- Agents do triage on incoming requests. They can flag or annotate or reject tickets. Good criteria include violation of stated product goals, impact on metrics and tests, visible UX changes, scope, number of other apps/modules affected, performance hits, obvious regulatory problems, contradictions with other changes. Then group similar items for bulk review. Quickly returning an explanation to the requestor would show that we’re not sitting on our hands.
- Humans review. Once agents politely decline nine out of ten suggestions, we need a weekly half-hour for a product manager, engineering lead, and UX/designer to quickly scan the good stuff. Big, interesting, clever, complex, thought-provoking? Into our careful consideration process. A bad idea for reasons our agent missed? Reject, expand our agent logic. Seems small, safe, reversible, an obvious fix? Into the autonomous queue! (YOLO)
Let the agents do most of the heavy lifting, but don’t cede full control. We need to avoid expensive, unforced errors like executive jail time.
SOUND BYTE
Tickets are wishes, not specs, and agents grant wishes literally.
[1] This my latest Cassandra moment: saying what no one wants to hear.