We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Speed without direction
Marty Cagan put a name to what many teams are seeing: the "AI productivity paradox." Teams are "absolutely moving faster," but "they're not actually getting better results." He says McKinsey and Atlassian have both published data on it . In his view this is what you'd expect from the project model. Speed is good, but it "shines a light on the need for people to actually know the craft" .
Melissa Perri calls it the build trap again. Companies are spending "hundreds of millions and billions" on AI but aren't putting in the time to work out what to build with it . She gave an example. Usage data for a therapist product suggested nobody wanted it. Interviews showed therapists did want it but gave up because it kept breaking. Her conclusion: "AI will never set your strategy for you" .
Ravi Mehta gave practical advice on what to do with the extra capacity: "A faster first draft should give us more time to make the final draft better." Get to a working version early, review a full customer flow while changes are still cheap, and polish instead of adding features . Agents now effectively write the final draft of the spec. Without the customer's goal and the intended experience as context, they "can produce a build that looks finished but misses the point" . He warns executives that if every efficiency gain turns into another roadmap commitment, teams stay just as rushed .
On Aakash Gupta's podcast, Tim Herbig made a related point. His clients said feature adoption was already a problem a year ago, so teams shipping more must ask "did any of it make a difference?" . He uses Roger Martin's test for whether something is a real strategic choice: its opposite must not be stupid . He rejects tokens as a success metric, since tokens are "a value exchange for Anthropic," not for your customers . He also dismissed AI search as a differentiator: "No one will buy a car with you because you have an AI search" .
Shreyas Doshi argued that top-20% builders already talk to users enough, and talking more won't do much. Most content and company processes are written for the average builder, and "judgment matters most" . A Google Search AI leader said the same thing from a team's point of view. When building is fast, the question is whether an idea is worth it compared with five others, given the cost in people's attention and tokens . She runs lean, flat "SWAT team" pods: one strategic senior lead and a small bench of ICs .
A senior PM on Reddit described what this looks like on the ground. AI-generated strategy documents linked roadmaps to dependencies that "nobody had validated," and those documents may now feed decisions on investment and resources . The poster proposes requiring every document to name the decision it supports and its owner, and having a named human validate any AI analysis .
Your product already has an agent policy
A Mind the Product episode looked at agents failing partway through checkout. Walmart had a deal to welcome Meta's Muse agent, but an old "verify you're a human" check kicked it out . On September 15, Cloudflare started blocking agent and training traffic by default on pages that show ads. Nobody has confirmed that this caused Muse's failures . Meta and Sierra have proposed a protocol for authenticating agents in commerce, with a 0.1 spec planned. The host is skeptical: no spec exists yet, and it enters a crowded field . His suggestion: pick one key flow, run an agent through it, log every place it fails, and design what the customer sees when the agent gets blocked . Start agents with read-only access and require the user to grant write access deliberately .
Hiten Shah noted that in Q3, Anthropic (Claude Cowork), Grok Bot, Meta and OpenAI all shipped persistent agents that keep working after you leave . Aakash Gupta described a case where Claude ran rm -rf on a developer's home directory while testing a sandbox it had built. The model "already knew" deleting a home directory was a bad idea, but nothing outside the model checked the command. His fix is a rule enforced in code that blocks deletes outside the project folder .
Hiring signal
Gupta read 113 AI PM job listings by hand. Seven in 10 asked for prior AI experience, but only 1 in 8 required production experience. He recommends building something live that you can defend, including your model choice and evals .
- A two-week cross-functional business review can keep product, engineering, and design aligned: inspect shipped and planned work and blockers, and allow disagreement as long as each team’s position is understood. The cadence is described as limiting drift and reducing pairwise alignment conversations. A bot built from past reviews can also surface a product leader’s likely questions to PMs in advance, helping them prepare.
- For domain AI, structure knowledge for LLM consumption and focus models on a trusted corpus; the interview describes this as improving predictability and reducing hallucination risk, while enabling faster, lower-cost responses from focused small models. Teams should also track where models fail or regress and match tools to the task, rather than forcing narrative outputs into computational work.
- AI automation can uncover value in recurring manual tasks too small or overlooked to reach an engineering backlog; lower build costs let nontechnical users create workflows, and small efficiencies can compound. But easier building does not eliminate maintenance costs: rewrites should carry forward valuable knowledge while shedding technical debt.
- A path to profitable growth described in the interview combines checking unit economics, finding customers before building and developing with them, and maintaining cycle speed. The interview also cautions that software switching costs and stickiness are declining, so current retention should not be assumed durable.
- Google Search’s AI team says it saw users move from keyword queries to longer, contextual natural-language questions, followed by expectations for follow-up questions; the product challenge is combining AI with web content while meeting Search’s speed expectations.
- For new product bets, move quickly from hypothesis and definition to a prototype, real-data demo, and small beta rather than spending weeks debating; use early tests to assess usability, data quality, and whether the opportunity merits further work. Set a clear quality bar for the MVP: the team says simulations only landed because their quality was high enough to be useful.
- Faster AI-assisted building makes prioritization more important: weigh ideas against alternatives and the costs of people’s time, user attention, and tokens, without compromising quality, trust, or craft. For personalization and AI-assisted work, use real-user feedback and studies, and cross-check and stress-test tool outputs rather than relying on them uncritically.
- Google’s AI Search director favors lean, flat “SWAT team” pods with a senior strategic lead and small bench of individual contributors, plus cross-functional collaboration; she maintains durable ownership areas even as models and technical approaches change. For hiring, she looks for consumer-product instincts, awareness of AI technology and its opportunities, and zero-to-one builder mentality.
- The interview surfaced publishers’ concern that AI answers may quote content without sending click-through. Google’s response, as described by its product director, includes news in AI Overviews and AI Mode, links in responses, and model fan-outs intended to connect people with publishers and unique voices.
- Product teams should be given problems to solve, not stakeholder-defined features to build: cross-functional teams use discovery to test whether a solution is valuable, usable, feasible, and viable.
- Cagan calls AI’s speed-without-better-results effect the “AI productivity paradox”: accelerating project-model work can produce faster output without better outcomes; speed helps only when teams have the craft to choose the right direction.
- Treat an MVP as the smallest prototype that tests risks, not as a weak early product to ship. In regulated settings, separate discovery from delivery by testing safely with opt-in users; a customer discovery group can include roughly 6–15 volunteers who try versions and give feedback.
- Treat feature requests as clues, not automatic roadmap commitments: ask why the customer wants the feature, identify the underlying problem, and decide whether the requested solution is appropriate and compliant.
- AI has not removed the core product trio of product management, design, and engineering, though tools and jobs are changing. PMs need product judgment and an understanding of customers, business value, and viability; interviews can test this by asking candidates to solve a problem and demonstrate how they would prototype, test, and learn.
- Product leaders should prioritize the business outcome to pursue rather than assume that a more holistic, seamless experience is always the highest-impact work; build the vision around the chosen problem and solve it well.
- AI risks recreating the build trap: Cheaper, faster building and large corporate AI budgets do not answer what should be built; without strategy, governance, funding, and decision systems, AI can accelerate waste instead of customer value.
- Keep product judgment with people: AI can speed up synthesis of qualitative research and market analysis, but product teams must set assumptions and check its conclusions. In one therapist-product case, usage data suggested weak demand, while interviews revealed that frequent failures and poor usability—not lack of interest—were keeping therapists from using it.
- Use product ops to build the decision system: Product ops should work with data teams to instrument and connect systems so PMs and leaders can examine customer segments and track initiatives against business outcomes; it should also establish strategy governance and measure guardrails such as satisfaction and retention alongside cost reduction.
- Align functions around shared outcomes: Joint goals across product, marketing, sales, and technology can support shared accountability; siloed departmental strategies and OKRs risk pitting teams against one another.
- As teams ship faster, release volume alone does not show impact: feature adoption was already a problem for many teams, so teams must ask whether what they ship makes a difference. Treat strategy as a product for teams and stakeholders: over a horizon such as 6–18 months, it should help them make intentional yes/no decisions, with most team effort aligned to it. A useful strategy states why to act now, whom and what problems to focus on (including current alternatives), and how the product will win.
- Test whether a strategic choice is real by asking whether its opposite is also a credible option: “make salespeople more efficient” is not a choice, while choosing in-person client engagement over virtual contact is. Keep the target audience focused but viable; AI can help estimate reachable market size, and the scope can be widened if the market is too small.
- Use AI for market and competitor research, customer-evidence synthesis, scenario comparison, and pressure-testing, while retaining human accountability; treat AI as a resource that amplifies core customer value, not as the value proposition by itself. For differentiation, favor advantages that take time to build; in the hypothetical marketplace, Tim picks brand and network effects and rejects fancy AI search as a reason customers would buy.
- Measure changes in customer behavior and experienced value, not tokens or AI output: token usage is value for the model provider, while the North Star should represent value customers experience and business metrics should follow as it rises. Map every roadmap item to a strategy metric.
- A durable startup moat is a self-reinforcing advantage: distribution can supply growth, execution can buy time and more chances to succeed, and brand may eventually become a moat, but none alone guarantees durable defensibility. The four compounding mechanisms are switching costs, network effects, scale economies, and data effects, which can reinforce retention, engagement, lower costs, and product improvement over time.
- To evaluate a startup, identify its compounding advantage, assess how strong it could become, and check whether it is working using relevant KPIs and benchmarks; the benchmarks are directional because industries and business models vary.
- Lenny shared a plug-and-play AI skill for investigating whether a company someone is considering joining has a moat.
- Agent access is already a product-policy issue: human-verification checks and inconsistent merchant rules can interrupt agent purchases. Cloudflare changed its defaults to distinguish search, agent, and training traffic, blocking agent and training traffic by default on ad-supported pages for certain customer groups; the cause of Muse’s Walmart failures was not confirmed.
- Meta and Sierra announced a proposed commerce-focused personal agent protocol intended to authenticate agents and let businesses set permissions; Walmart, Stripe, and Genesis are among the reported participants, and a first 0.1 spec was planned for later that month. The proposal was not yet build-ready, entered a crowded protocol landscape, and would help only if integrated into product flows.
- Product teams can test readiness by running an agent through one important customer task, checking bot-management defaults and documenting where the flow fails. Set permissions deliberately—read-only as a starting point, with write access granted intentionally—and design blocked-flow recovery so customers can take over without starting again; measure whether the customer reaches the intended outcome. Agent-driven purchases and signups may also expose gaps in conversion and active-user analytics.
Hiten Shah suggests assessing AI-agent readiness by identifying one complete job an agent could finish without step-by-step checking; he says what shipped in Q3 changed his own answer after a year of running agents, and previews discussion of which jobs to delegate and where to step in .
Shreyas Doshi argues that while average product builders may need to talk to users more, most top-20% builders already do enough, so additional user conversations are unlikely to help much. Since much product content and many company processes are aimed at average builders, he says judgment matters most for stronger builders.
A new “Hype(less)” research project with @noamseg will collect genuine, impactful, repeatable AI workflows that create value in product, design, and engineering, with selected examples planned for a three-part newsletter. PMs, engineers, and designers are invited to submit workflows by 10/23.
- Product Delivery means a cross-functional team quickly and iteratively improves the product in service of established goals; measure outcomes by customer and product improvement, not by finishing tickets, and use clear goals to keep speed from becoming thrash.
- Mehta argues that AI-enabled faster first drafts should create time to refine the product before launch, not simply add features: get to a working version early, review the full customer flow, learn, and make improvements against the goal. Agents need context about customer goals and intended experience, plus clear decision rights and timely feedback.
- Agent oversight spans PM through executive levels: PMs review and redirect agent work, while executives build organization-wide decision rights and review systems. Leaders should avoid turning every AI efficiency gain into another roadmap commitment, which can leave teams just as rushed as before.
Shreyas Doshi argues that the Henry Ford “faster horses” quote can mislead already-above-average product people when treated as a rule or best practice; its real lesson, he says, is about judgment and skill.
Hiten Shah said he wants everyone in his family to have a bot like “Am I being Phished?” Its creator describes it as monitoring email, chat, and Slack for suspicious messages or requests and flagging them in real time using X search, RDAP lookups, and OSINT lists.
Hiten Shah draws an AI-automation boundary at consequential external actions: an agent can read and draft his email, but he wants to approve sending it; as tools improve, he is reconsidering where to set that boundary after Q3 releases.
AI could shift CRMs from passive data repositories into products that perform work historically handled by other tools; Hiten Shah says AI is making that shift possible after a two-and-a-half-year wait. The product challenge he had previously identified is that a CRM is only as good as the data it receives, and that it must evolve beyond being a data repository.
Hiten Shah picked Grok Bot as the most important AI product launch of Q3: it let users create an agent with its own computer and delegate work that continued without managing infrastructure, turning a setup he had previously operated himself with OpenClaw and Hermes into a sign-up product. Meta’s Muse and OpenAI’s dots followed, according to Shah.
Hiten Shah says four major AI companies converged in Q3 on persistent agents that have a place to work and continue after the user leaves: Claude brought Cowork to web and mobile, Grok Bot arrived with its own computer, and Meta and OpenAI introduced personal agents.
Vertical AI teams should classify target jobs as Hero’s Work (the power user’s high-stakes core work), Admin Work (painful, low-leverage work surrounding the core job), or Work Not Done (valuable work omitted for lack of time, skill, resources, or context). The category should shape research and solution expectations, including where human-in-the-loop expertise belongs in workflows that encode domain knowledge. Align the product category with the go-to-market motion and product/marketing pitch: these choices shape the operating model, and a mismatch can create sales and implementation problems.
A product-strategy question for AI builders: could valuable AI products help users become more ambitious, making expanded user ambition part of the product’s value? This is posed as a possibility, not an established trend.
- A senior PM at a large enterprise software company describes an AI-assisted strategy exercise that asked PMs to map existing roadmaps to strategic ambitions. ChatGPT generated 17 potential dependencies and polished documentation, but the author says the linked needs had not been validated with the teams involved—even as the material could inform investment and resource decisions.
- The author proposes safeguards for AI-assisted PM work: require documents to specify the decision they support, its owner, and the evidence needed; assign a human owner to validate AI analysis; bring requirement-setters into direct conversation with delivery teams; and track time spent generating, reviewing, and correcting AI-produced material. These are proposed mechanisms, not demonstrated results.
Product Delivery.
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.
Top 1% Builder with Ravi is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.
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.
Execute flawlessly
Last week, we discussed Product Definition (opens in new tab) — giving people and agents the context to build the right product. This week is about turning that shared understanding into something worth shipping.

The Product Competency Toolkit maps 12 competencies across four areas of product work.
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.

Product Delivery is one of three Product Execution competencies, alongside Product Definition and Product Quality.
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, not just start the next thing.
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, 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.
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 inside the delivery cycle instead of waiting in the backlog.
Imagine using that capacity to make the main customer flow simpler, make a confusing moment clear, or give an interaction the care it deserves. Those improvements can make the product more useful and more enjoyable without adding another feature.
A faster first draft should give us more time to make the final draft better.

AI gets you to a working version sooner. Spend that time making it better, not adding more, and you ship a better product on the same date.
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.
Engineering expertise and team attention still matter. Architecture, security, and dependencies don’t disappear. Neither does the need to make hard tradeoffs. But as implementation becomes cheaper, we can revisit compromises we once had to accept.
This also changes how the team works together. Product, design, and engineering can respond throughout the build. A designer might spot friction that leads 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.
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.

Product Delivery expectations by level: from launching improvements with your immediate team to building systems that improve execution across the organization.
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.

The emphasis of Product Delivery shifts with seniority. Agent oversight spans PM through VP, while resourcing, bottlenecks, and cross-team prioritization become leadership responsibilities.
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.
Top 1% Builder with Ravi is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.
- Product Delivery means a cross-functional team quickly and iteratively improves the product in service of established goals; measure outcomes by customer and product improvement, not by finishing tickets, and use clear goals to keep speed from becoming thrash.
- Mehta argues that AI-enabled faster first drafts should create time to refine the product before launch, not simply add features: get to a working version early, review the full customer flow, learn, and make improvements against the goal. Agents need context about customer goals and intended experience, plus clear decision rights and timely feedback.
- Agent oversight spans PM through executive levels: PMs review and redirect agent work, while executives build organization-wide decision rights and review systems. Leaders should avoid turning every AI efficiency gain into another roadmap commitment, which can leave teams just as rushed as before.