We’re Not Paid to Practice Scrum, but Answer 5 Product Questions

TL;DR: Five Product Questions Cheap Code Makes More Expensive to Skip

For decades, the cost of building software rationed what an organization could start: nobody could afford to build everything, so somebody had to choose, however crudely. AI has weakened that rationing; the frontier labs need your organization to use more AI with every model generation, and the product operating model promises to fix what Agile supposedly broke. None of this guarantees that anyone asks whether the work solves a customer problem, nor whether solving it was worth the cost. You need to address these product questions yourself.

These product questions become more expensive to skip when starting work gets cheap: which problem is worth solving, whether the work is the best use of the team’s time, whether it is good enough for the people who will see it, whether it solved the problem, and whether the team’s way of working still fits. AI agents can prepare evidence under the A3 Framework’s Assist category, where the agent analyzes and people decide, while explicit standards for AI-assisted work, such as the AI Definition of Done, and recurring inspections, such as the AI Delegation Audit, keep the answers honest. Whether you call any of this Scrum is the least interesting question of all.

Thesis: This article explains five product questions that become more consequential when AI makes software implementation cheap, why falling AI costs increase the volume of work those questions must filter, and how teams set working principles during early AI adoption.

Disclaimer: I read Charniak/McDermott’s book on “Artificial Intelligence” decades ago; of course, I use AI for research, translations, proofreading, challenging story arcs and article structures, creating artifacts such as graphics, and summarization. It is a production tool, not a substitute for thinking.

---

🎓 🇬🇧 The AI4Agile Online Course v4 — November 27, 2026, at $149 — Join the Waitlist

Sooner or later, a CFO will ask what your AI use actually returns. “It saves me time” will not survive that meeting.

The first wave of AI adoption rewarded practitioners who learned to prompt. That skill still matters, and this course still teaches it. The second wave rewards something rarer: people who can turn individual AI use into knowledge that survives departures, spend that can be explained and steered, and output that organizations can trust. That work is process design and change management. You have been doing both for years, on harder problems than this.

EXCLUSIVE: The new A3 Delegation Lifecycle System with seven ready-to-use templates, from the AI Workflow Inventory to the AI Definition of Done to the AI Working Agreement, to make sense of delegating work to AI models.

BRAND-NEW: Hands-on exercises to build AI Agents, with your tactical work, covering, for example, Jira-based stakeholder reports, product discovery, AI Impact on metrics, or preparation for backlog refinement. All exercises use realistic data and context to simulate reality as closely as possible in a fail-safe environment.

The AI 4 Agile Online Course v4 is in English. 🇬🇧

What You Will Get:

✅ 20+ hours of self-paced video modules ✅ 4 Live onboarding session ✅ A cohort-hardened​, proven course design ✅ Learn to 10x your effectiveness with AI; your stakeholder will be grateful ✅ Apply AI to classic use cases of “Agile” ✅ The A3 Delegation System comprising seven ready-to-use templates ✅ All texts, slides, prompts, and graphics ✅ Access custom GPTs, including the “Scrum Anti-Patterns Guide GTP” ✅ Guaranteed: Lifetime access to v4 ✅ AI4Agile Foundation Certificate: 40 questions in 45 minutes.

👉 Please note: The course will be available for $149 from November 27-30, 2026! (After that, $249.) 👈

🎓 Join the Waitlist now and be the first to know: The AI4Agile Online Course v4 — November 27, 2026, at $149 — No Coding Required!

---

🇩🇪 Zur deutschsprachigen Version des Artikels: Niemand bezahlt uns, um Agile zu praktizieren: Fünf Produktfragen, die stattdessen zählen.

🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 35,000-plus subscribers.

🎓 Join Stefan in one of his upcoming training classes!

---

If We’re Not Paid to Practice Scrum, What Are We Paid For?

If you work in product, you probably believe that the slow, expensive build was the big problem of software development and that AI coding agents are finally solving it. Half of that belief holds up: building was slow and expensive, and agents have made writing code much cheaper. The other half deserves more scrutiny, because the expense was doing a crude rationing job that many organizations never replaced with anything better.

When a feature took a team several weeks, somebody had to decide which idea got those weeks, and some weak ideas died in a prioritization meeting before anyone wrote a line of code. (Not many, admittedly; the ones with a senior sponsor and budget authority usually survived, and being chosen said nothing about whether an idea addressed a worthwhile problem.) The same expense also did damage, discouraging cheap experiments and pushing organizations to defend features they had already paid for in a prime example of submitting to the sunk cost fallacy. Product management has a name for the discipline that rationing never supplied on its own, and Uri Levine, the co-founder of Waze, put it into the title of his 2023 book, Fall in Love with the Problem, Not the Solution. When writing code costs next to nothing, falling in love with your own solution becomes affordable again. At the same time, testing whether customers care becomes cheaper than ever.

For years, I have used one sentence to describe what agile practitioners are actually paid for: We are not paid to practice Scrum but to solve our customers’ problems within the given constraints while contributing to the organization’s sustainability. That sentence seems more useful now than ever, as Agile in general and Scrum in particular are under pressure from two sides at once.

Two Promises of Speed, and What Adoption Does Not Guarantee

The first pressure comes from the product operating model Marty Cagan popularized. He made the point plainly when I interviewed him in 2024: “To be blunt, a Scrum team is quite amateur compared to a professional product team,” as he put it in our interview on the product operating model and Scrum’s future. On paper, the model covers the questions this article is about. SVPG’s introduction to the product operating model states that “leaders in product management, technology, and design are responsible for deciding which problems to solve,” and it asks teams to find solutions that are valuable, usable, feasible, and viable.

Adoption is a different matter. In my August 2026 survey of 48 practitioners, only 1 of the 26 respondents whose organizations had adopted the model or were moving toward it reported “a fundamental change in how build decisions are made.” Of the others, 9 described mostly relabeling, 9 a mix of real change and relabeling, and 7 said it was too early to tell. The respondents report on their organizations, though, and the survey did not verify 26 distinct organizations. Putting the model’s vocabulary on the slides seems to be easy, whereas changing who decides what to build, and on which evidence, is hard.

The second pressure comes from AI in all its forms, from coding agents that build a working prototype in an afternoon to agents that promise to take over product decisions as well. If an agent can ship a feature by Friday, a two-week Sprint looks slow to many stakeholders, which is a misreading, because the Scrum Guide states that “an Increment may be delivered to stakeholders prior to the end of the Sprint.” In many organizations, a coding agent that receives a feature request delivers exactly that feature, and nobody asks whether the request addressed the right problem.

Cannot see the form? Please click here.

Cheaper AI, More Work to Evaluate

In 1865, William Stanley Jevons warned in ‘The Coal Question’ that Britain would exhaust the coal fueling its growth. As Yale’s Energy History project summarizes, “increased efficiency in consumption would not reduce demand for energy.” Efficiency can stimulate demand, and whether it does depends on the market; the AI industry, however, seems to be running through the Jevons Paradox at high speed.

Epoch AI’s The plunging price of thought, published on September 22, 2026, estimates that “the cost of a given level of AI performance has fallen about 47% per quarter,” measured on five benchmarks in math, science, and games. The authors caution that benchmarks are imperfect proxies for useful work and that their figures “should not be read as exact.” Anthropic’s S-1 Form, filed on October 26, 2026, reports that Claude Opus 5.5 “reduced customer costs per task by approximately 40% compared to Claude Opus 5,” followed by a sentence Jevons would have recognized: “Lower costs per task drive greater usage, which in turn drives broader diffusion of Claude.” The filing names other growth drivers, above all more capable models, whose turnover is fast: “model versions released in the six months ended September 30, 2026 accounted for over 80% of our revenue for the three months ended September 30, 2026.”

Taken together, the figures describe a supplier whose growth depends on customers using more AI, for more purposes, with every model generation. (That is my reading of the numbers, and no accusation.) For a product team, cheaper implementation can make customer problems worth solving that used to be uneconomic, which is good news. However, customers’ attention, their capacity to adopt change, and the organization’s capacity to review, support, and maintain what it ships do not grow automatically with the number of agents. That gap is where the five questions come in.

Five Product Questions in One Picture

In AI-Assisted Product Discovery, I argued that once the cost of building falls, the constraint moves to judgment. My own survey complicates that: asked about the scarcest capability, the 26 respondents most often named stakeholder alignment and decision speed (7), delivery capacity (6), and product judgment (6), and among the seven whose move was AI-driven, delivery capacity (3) outranked product judgment (2), so my hypothesis that judgment would come out on top did not hold. Where implementation gets substantially faster, something else becomes the limit, whether review, integration, decision speed, customer learning, or judgment, and the five questions are where those limits show up.

Engineering leaders will rightly add that integrating, securing, debugging, and maintaining AI-written code still costs money, and DORA associates higher AI adoption with higher delivery instability. A team can anticipate those costs before it starts; however, when the decision to start rests on how cheaply an agent produced the first version, the visible savings get the attention, and the lifetime costs lose their restraining effect.

The following sketch combines two drawings from my classes: my Product Backlog management sketch, with its discovery funnel and refinement stages, and the loop that turns a Product Backlog into a source of solutions to customer problem and feeds what the team learned back into the funnel. Instead of event names, it carries the five questions where they arise. (If you know the original Scrum.org drawing, you will recognize the loop; only the labels changed.) Read the arrows as carefully as the boxes: every answer feeds back into the funnel and can reopen an earlier decision.

The 5 Product Questions

The five product questions we are paid to answer are as follows:

1. Which Customer Problem Is Worth Solving?

The question lives at the neck of the funnel, where the product vision and the Product Goal/objective decide which ideas, requests, and data points earn a place in the work, and its answer has two parts: why customers care about the problem, and why solving it is worth it to the organization. The agent from my discovery article reads far more customer evidence than any product person and compares it with what the organization has already committed to, working in the A3 Framework’s Assist category: the agent analyzes and prepares, and the humans decide. Assist has a catch, however: an agent that condenses a few hundred support tickets into three problem statements has already decided what to weigh and what to drop, so the humans also need to check which evidence the agent used and which it left out.

Cheap code also changes this question for the better: a prototype built in an afternoon is a legitimate way to learn whether customers care, in the experiments and validation step of the sketch. The trouble starts when the organization can no longer tell a probe built to learn from software built for production, and the two-hour prototype ships because “it already works.”

2. Is This the Best Use of Our Time Right Now?

The best use of time covers far more than new features: maintenance, reliability, technical debt, and the cost of operating and supporting whatever the team ships all compete for the same capacity. Product Backlog refinement extends discovery, and its outcome is a shared understanding sufficient to make the next investment decision, including the decision not to build. A refinement preparation agent can flag the anti-patterns in a Product Backlog before the team meets; it marks them without fixing them, because fixing them is the team’s job. Part of the shared understanding is now also what an item is for: a probe to learn from or work headed into the product, because each needs a different standard.

3. Is It Good Enough for the People Who Will See It?

The 2025 DORA report found that AI adoption now goes along with higher delivery throughput, while “software delivery instability continues to rise,” as InfoQ reported. The report itself sums up its interpretation: “AI’s primary role is as an amplifier, magnifying an organization’s existing strengths and weaknesses.” DORA’s article Balancing AI tensions adds the mechanism every reviewer knows: “Velocity gains for an individual author frequently translate into a significantly increased cognitive load for the reviewer.”

Good enough depends on the purpose, and each purpose needs its own standard instead of an exemption from standards. Product code has to meet the product’s Definition of Done, regardless of who wrote it, and the Scrum Guide is explicit: If a Product Backlog item does not meet the Definition of Done, “it cannot be released or even presented at the Sprint Review.” An experiment shown to customers needs a standard appropriate to its purpose and exposure, covering what customers see, what data the experiment uses, and whether its results can support the conclusions the team wants to draw. AI-assisted outputs that the product’s Definition of Done does not cover, such as a discovery analysis, a status report, or drafted Product Backlog items, are what the AI Definition of Done is for: a one-page standard the team agrees on before such an output leaves the team, because “it looks good” is not a quality standard.

4. Did It Solve the Problem?

Output is easy to count, which is why so many organizations count it: tickets closed, features shipped, or story points burned. None of these numbers tell you whether a customer’s problem got smaller, nor whether the improvement is worth what it costs to build, support, and run. The usual substitute, the before-and-after velocity chart, is what I took apart in my article on Measuring AI Impact.

A hypothetical example shows what an adequate answer needs. Suppose a team wants fewer new customers to get stuck during onboarding, and an agent builds a guided walkthrough in two days. Shipping the walkthrough is output. Before it ships, the team writes down four things:

• Baseline: The current share of new customers who abandon onboarding before they reach their first useful result.
• Worthwhile change: The improvement that would justify keeping the walkthrough, including its support and maintenance, without more support tickets.
• Observation period: Several weeks, because onboarding cohorts take time to show a pattern.
• Decision rules: Which result supports keeping, changing, or removing the walkthrough, and what the team does if it still cannot tell, for example, observing one more cohort.

The decision rules are the part most teams skip, because removing something that “already works” feels like waste, and an inconclusive result is easily mistaken for evidence of no benefit, or of success. The baseline ties abandonment to reaching a useful result, because a walkthrough that only gets more people through more screens turns abandonment into one more proxy. The Scrum Guide says the purpose of the Sprint Review “is to inspect the outcome of the Sprint and determine future adaptations.” Customer effects often take longer than one Sprint to show, so the review is where the team checks what the evidence says so far and decides what to adapt. The problem with this traditional approach is obvious: stronger evidence of impact may emerge only several Sprints later.

5. Is the Way We Work Still the Best Way?

AI changes this inward-looking question the most, because a team’s way of working now shifts with every model release and every new agent. Scrum’s Retrospective exists for this purpose, “to plan ways to increase quality and effectiveness,” and any team that already sets aside time to inspect its own way of working starts with an advantage, whatever it calls the meeting.

The AI Delegation Audit extends that inspection to the work a team has delegated to AI. It is a recurring meeting of 45 to 60 minutes, monthly or every other Sprint, that checks whether each delegated workflow still meets its AI Definition of Done, whether the assigned model still fits, whether the team could stop each automation today, and whether Assist work has quietly become unreviewed Automate work, with review time per output trending toward zero as the warning sign.

Where Teams Get Stuck When Answering the 5 Product Questions

Each of the five product questions comes with a familiar failure, and AI makes every one of them cheaper to commit:

• Which problem: Stakeholder requests skip the funnel and arrive in the Product Backlog with a deadline attached, because the stakeholder outranks the evidence.
• Best use of time: A tidy Product Backlog passes for good refinement, although polished items are exactly what an agent produces fastest, and maintenance work loses every comparison with a new feature.
• Good enough: Review fatigue sets in, and “looks good” becomes the only “standard” after the twentieth agent output of the day.
• Did it work: The Sprint Review turns into a demo of what was built, and stakeholders applaud the increment instead of asking what changed for the customer and what the organization’s ROI of this change is.
• How we work: Nobody finds time to inspect the way of working, because the team is busy shipping what the agents produced.

The failures also travel through the loop, although the loop can catch them. Poor quality can confound the outcome question, because the team then measures the effect of a flawed implementation; an honest outcome review, however, may show that poor quality is exactly what prevented the benefit. Likewise, a team that chose poorly at the first question can find out when it asks whether the work solved the problem, and stop. The feature factory begins where that learning fails, when a team treats successful delivery as evidence that the choice was good.

In many larger organizations, product people don’t even get to decide what to leave undone, because the organization expects more features faster than ever, now with AI. (Hence “within the given constraints” in my sentence.) Showing such leaders what each feature displaces rarely stops anyone, because they believe agents give them unlimited capacity. Two other resources can become the limit instead: how much work the team can review properly, and how much change customers can absorb. Review capacity can grow through better tests and smaller changes; nevertheless, neither resource grows automatically with the number of agents. An explicit WIP limit on what the team can review and measure per cycle makes that limit visible, no matter how many pull requests the agents open.

The Cost of Learning

Sean Goedecke made the individual side of this argument in Getting good at AI takes time and practice, published on October 28, 2026: “It requires developing long-term skills, which takes time and practice.”

On the organizational side, Erik Brynjolfsson, Daniel Rock, and Chad Syverson described the Productivity J-Curve of general-purpose technologies such as AI, which “enable and require significant complementary investments,” including the “co-invention of new processes, products, business models and human capital.” Because those investments are mostly intangible and poorly measured, measured productivity looks worse early on and better later. The paper models a measurement problem and makes no claim that every team goes through a dip; translated to a product team, however, the time people spend learning to delegate, review, and correct AI work shows up as lost output long before it shows up as beneficial.

The trouble is familiar from the Agile transformation years. In my experience, most leaders don’t give teams enough time to learn properly, and the leader who sponsored the new way of working needs quick wins to convince other leaders the decision was right. So the learning gets measured as lost output, and the verdict arrives early. Progress has a more demanding definition: comparable work taking less total effort, including review, correction, rework, and maintenance, at acceptable quality and with useful results.

An A3 Handoff Canvas per agent, an AI Definition of Done per class of AI-assisted output, and the records of the AI Delegation Audit are one practical way to build the intangible investments the J-curve describes, and other arrangements can do the same job. Either way, the records compound only when a team uses them to improve its next decisions.

I suspect that the window for setting such working principles is closing faster than most organizations assume, because AI habits harden into defaults within months, and retrofitting principles onto an established practice costs more than setting them while the practice is still forming. (That is a prediction, and I may be wrong about the speed; I would rather be early, though.)

Not Paid to Practice Scrum – Conclusion: Who Answers Your Five Product Questions?

None of the principles behind the five product questions is new, nor does any of them belong to Scrum alone: inspecting and adapting, releasing only what meets an agreed quality standard, and regularly looking at how you work. Scrum bundles them compactly, and its brand has taken a beating, some of it deserved; in Agile Is Dead, Long Live Agility, I argued that the label failed while its ideas spread. As I used to say: As long as we deliver business value in an ethical, legal, sustainable, and financially viable manner, no one cares about what we use. And rightfully so.

So take the five questions to your next team meeting and ask three things about each of them:

• Evidence: Who supplies the evidence for the answer today?
• Authority: Who has the authority to act on the answer?
• Stop: What happens when the answer is “stop”?

The last question turns a reflective exercise into a test of your operating model, whatever you call it. If nobody can act on a “stop,” you have found the question to work on first.

If you would rather practice this with AI agents than read about it, AI4Agile v4 Online Course adds a chapter of practical applications, with exercises on the product discovery agent, the refinement preparation agent, a Jira-based status report, and measuring AI impact. It will be available on November 27, 2026, at $149.

---

Key Questions This Article on the 5 Product Questions Answers

Why Are Agile Practitioners Not Paid to Practice Scrum?

Agile practitioners are paid to solve customer problems within the given constraints while contributing to the organization’s sustainability, and Scrum is one means to that end. Its useful principles, such as inspecting and adapting, releasing only work that meets the Definition of Done, and regular Retrospectives, are more useful with AI than before. Whether a team calls its practice Scrum or a product operating model is irrelevant if it lives up to them.

Which Product Questions Become More Expensive to Skip When AI Makes Code Cheap?

Expensive development rationed what an organization could start, but it never answered the product questions themselves. Five questions become more consequential when implementation gets cheap: which customer problem is worth solving, whether the work is the best use of the team’s time, whether it is good enough for the people who will see it, whether it solved the problem, and whether the team’s way of working still fits.

How Does the Jevons Paradox Apply to AI in Product Development?

The Jevons Paradox describes how efficiency gains can increase total consumption rather than reduce it. Anthropic’s 2026 S-1 describes that dynamic for its own business: “Lower costs per task drive greater usage.” For product teams, cheaper implementation can make new problems worth solving. At the same time, customer attention, adoption capacity, and the organization’s review and support capacity do not grow automatically with the number of agents.

What Does the Productivity J-Curve Mean for AI Adoption in Product Teams?

Brynjolfsson, Rock, and Syverson showed that general-purpose technologies such as AI need intangible investments, such as new processes and skills, that measured productivity misses early and rewards later. In a product team, learning to delegate and review AI work first looks like lost output. Real progress means comparable work taking less total effort, including review, rework, and maintenance, at acceptable quality and with useful results.

Which Working Principles Should Product Teams Set for AI Now?

Product teams should decide, for each of the five product questions, who supplies the evidence, who has the authority to act, and what happens when the answer is “stop.” They also need standards by purpose: the product’s Definition of Done for product code, checks appropriate to the purpose and exposure of customer experiments, and an AI Definition of Done for AI-assisted outputs, plus a recurring AI Delegation Audit of delegated workflows.

Five Product Questions — Related Posts

Measuring AI Impact: What Your Velocity Chart Cannot Tell the CFO

AI-Assisted Refinement Preparation

AI-Assisted Product Discovery: When Code Is Cheap, Judgment Is the Job

AI Transformations And Agile Transformations Rhyme

The A3 Handoff Canvas: Six Questions That Turn AI Delegation Into a Repeatable Workflow

The A3 Framework: Assist, Automate, Avoid — A Decision System for AI Delegation

👆 Stefan Wolpers: The Scrum Anti-Patterns Guide (Amazon advertisement.)

📅 Training Classes, Workshops, and Events

Learn more about the five Product Questions with our AI and Scrum training classes, workshops, and events. You can secure your seat directly by following the corresponding link in the table below:

See all upcoming classes here.

You can book your seat for the training directly by following the corresponding links to the ticket shop. If your organization’s procurement process requires a different purchasing approach, please contact Berlin Product People GmbH directly.

✋ Do Not Miss Out and Learn More about the Five Product Questions — Join the 20,000-plus Strong ‘Hands-on Agile’ Slack Community

I invite you to join the “Hands-on Agile” Slack Community and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

If you would like to join, all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.