Someone I worked with spent months programming how birds flocked from tree to tree.
I was a game developer then. I started a game company in high school and later joined as one of the first 20 or so people on the Xbox team. We obsessed over details — how the camera responded to the controller, the sound of a sword clanging against a shield. We played the same moments over and over until they felt right.
When I started working on consumer tech, I was surprised at how little time was spent on that craft. Every ounce of effort needed to be justified against “impact” — in pursuit of an OKR. Often, that led to products feeling Spartan — devoid of delight.
If we cut all the “nice-to-haves,” our product won’t be nice to have.
There are, of course, exceptions. At Duolingo, it’s clear that the little green bird has sway. The product is full of little love marks — details that might never justify their own engineering ticket, but together make the product worth loving.
The rational part of me understands it. For years, scarce engineering time made us ruthlessly prioritize what we built. AI is changing that constraint. Now we should be just as ruthless about how well we build it.
More engineering capacity should mean better products, not just more features.
That brings us to Product Delivery, the second of the 12 competencies essential for building remarkable products.
Join the Top 1% Builder Series on Fridays.
The Top 1% Builder Series is a free 12-part live workshop series (one week per competency) with Ravi for product managers, leaders, founders, designers, engineers, and builders who want to ship products customers love — with AI amplifying the judgment they already have. Live attendance is free. This week, on Friday, October 16, we’ll dive deep into Product Delivery. Replays and slides are available to paid Top 1% Builder Club members.
Join the Top 1% Builder Series →
Execute flawlessly
Last week, we discussed Product Definition — giving people and agents the context to build the right product. This week is about turning that shared understanding into something worth shipping.
These competencies are organized into four areas:
Product Execution — getting the right product built well
Customer Insight — understanding the people you build for
Product Strategy — choosing the outcomes that matter
Influencing People — rallying people around the org to make it so
Product Delivery sits within Product Execution: the ability to define, build, and launch well-designed, stable products. The best product builders strive to execute flawlessly. There is already enough risk in understanding customer needs and choosing a strategy. They can’t afford unforced errors.
Three competencies work together:
Product Definition — defining the right product
Product Delivery — working with people and agents to build it right
Product Quality — ensuring high quality at launch and beyond
Product Execution is the ability to work with a cross-functional team to define, build, and launch well-designed, stable products.
Product Definition establishes what to build and why. Product Delivery turns that intent into a working product, adapting as the team learns. Product Quality sets the bar and checks that the product meets it, at launch and beyond.
Product Delivery, defined
Product Delivery is the ability to work with a cross-functional team to quickly and iteratively deliver product improvements that achieve established goals.
Three parts of that definition matter:
With a cross-functional team. People bring different skills and perspectives. Strong delivery draws on those talents throughout development, rather than passing the work from one function to the next.
Quickly and iteratively. Speed shortens the distance between an idea and something the team can try. Iteration turns what it learns into a better product. The first working version is a starting point, not the finish line.
Against established goals. A finished ticket isn’t the outcome. The work needs to improve the product in a way that serves the customer and achieves what the team set out to do.
That takes organization, attention to detail, and judgment. Clear goals keep speed from becoming thrash. They help the team distinguish a change that matters from a preference that can wait.
How Product Delivery evolves with AI
“Protect the sprint” meant keeping the team focused on the work it had committed to — and keeping new requests from interrupting development.
When engineering time was scarce, that made sense. Even teams that welcomed feedback had to be careful about acting on it. A delightful interaction might take days of work, putting other commitments at risk without a clear contribution to the team’s OKRs.
That pressure encouraged a familiar habit: finish the agreed scope, ship, and put the refinements in the backlog. The ideal product always felt one sprint away.
AI creates room to change that habit. The product we kept pushing into the next sprint is now within reach — if we use the extra capacity to refine what we’re building, rather than simply starting the next thing.
Teams can begin with detailed specs, functional designs, and working prototypes. During implementation, agents can help explore alternatives, make changes, and shorten the time between feedback and a working result. More refinement can happen within the delivery cycle instead of waiting in the backlog.
Imagine using that capacity to simplify the main customer flow, clarify a confusing moment, or give an interaction the care it deserves. Those improvements can make the product more useful and enjoyable without adding another feature.
A faster first draft should give us more time to make the final draft better.
Get to a working version early enough to experience it, learn from it, and improve it before launch. Review a complete customer flow while changes are still inexpensive. Keep the shared definition current as decisions change, and judge refinements against the goal rather than someone’s latest preference.
That opportunity doesn’t mean we can hand off the work and walk away. Engineers have always written the final draft of the spec. Now agents are taking on that role.
Implementation involves countless small decisions: what customers see, how an interaction behaves, and what happens when something goes wrong. Agents need the context to make those decisions well — the customer’s goal, the intended experience, and which details are open to interpretation. Without that context, agents can produce a build that looks finished but misses the point.
Product Delivery matters more, not less, when those decisions happen faster. People and agents need clear decision rights and feedback while there is still time to act on it.
Making those decisions well requires collaboration throughout development. A designer might spot friction, prompting an engineer to suggest a simpler approach. A PM might revisit an assumption after trying the flow. Agents help the team act on those discoveries quickly.
This is why I think product development is moving from an assembly line to a jazz band. The lead can shift as the product evolves. Shared goals and clear ownership keep everyone moving in the same direction.
Probabilistic features need even more room for iteration. One successful walkthrough is not enough. The team needs time to explore different inputs, repeat interactions, and refine the feature across a broad range of use cases before putting it in front of customers.
Internal testing will never cover everything customers try. Evaluation must continue after launch. Build AI evals — repeatable tests of whether responses meet the product’s quality bar — during development, then expand them with cases drawn from real customer interactions.
The PM’s responsibility extends beyond release. We’ll explore that ongoing work next week with Product Quality.
Product Delivery used to be defined by managing a scarce resource. Now we need to rethink how we build — channeling that newfound abundance into building better, not just building more.
How it feels to master Product Delivery
You help a team turn a shared definition into a product worth shipping. People understand the goal, know which decisions they own, and raise problems while there are still options.
You stay close to the experience without becoming the approval step for every detail. You use the build to clarify intent and act on what the team learns. You know when to intervene, when to give people latitude, and how to distinguish a valuable refinement from a distraction. You help people stay motivated when the work gets difficult.
The result is not merely the product imagined before the first line of code. It is the product the team truly wants to ship — better because of what it learned while building it.
Product Delivery from APM to CPO
All 12 competencies matter at every level, but what excellence looks like changes as your scope grows. I think about this ladder as Products → Teams → Systems:
Product managers build products.
Product leaders build the teams that build products.
Product executives build the systems that build the teams that build products.
Every competency climbs the same ladder, including Product Delivery. Early product builders learn to work through the day-to-day tradeoffs that determine whether a product ships well. Product leaders create the conditions for teams to move quickly without losing quality, while executives build the operating systems, talent, and priorities that make reliable execution repeatable.
Importantly, building faster doesn’t mean everyone should become an individual contributor. Faster teams need steadier leadership to organize the work, resolve competing priorities, and help people make good decisions. More individual capacity makes leadership more consequential, not less.
The goal never changes: a team that can quickly and reliably deliver the right product. What changes is how many people — and which systems — you enable.
Early in your career, you make day-to-day tradeoffs about scope, speed, and quality with your immediate team. An APM does that with guidance; a PM takes greater ownership and knows when to escalate. As agents contribute to the build, you review their work, catch mistakes, and redirect it when it misses the intended experience.
As your scope grows, delivery depends on more than your immediate team. Senior and Principal PMs coordinate work across teams, resolve dependencies, and make sure the pieces fit together.
When you manage a team, you help others develop the same judgment. You coach people through hard tradeoffs, clarify ownership, and create room for fast iteration without constant interruption. That clarity extends to agents: which decisions they can make, when they must ask for help, and who reviews the result.
At Director and Senior Director levels, you remove recurring bottlenecks and make sure teams have the people, skills, and support to deliver. When teams’ needs conflict, you decide where shared resources will make the greatest difference.
At the executive level, you build the people, processes, and operating practices that make strong delivery repeatable. That includes governance for agents: clear decision rights and review systems that work across the organization. Agent oversight deserves attention at nearly every level. As you become more senior, your responsibility expands from reviewing the work to building the system for reviewing it.
Executives also decide how the organization uses the capacity AI creates. If every efficiency gain becomes another roadmap commitment, teams can remain just as rushed as before.
Before sprinting through the rest of your backlog, ask: “What can we improve in the product we’re already building?”
Great delivery gives teams room to make the product better before asking them to build the next thing.
Next week: Product Quality — setting the bar and keeping the product above it, at launch and long after.
Dive deeper into Product Delivery
The free Product Competency Toolkit dives deep into the 12 competencies that turn good product builders into remarkable ones. Updated entirely for the AI era, it explains how each competency is evolving — whether you want to improve your own craft, coach your team, or help your entire organization level up.
It’s for anyone building products across product, design, engineering, marketing, leadership, or a venture of their own.
Get the Product Competency Toolkit →
What do you think about product delivery of non-deterministic systems? Same processes used, or are there changes that require the PM to think beyond the release?