Stop doing what worked in 2026

Do this to win in 2027 (and stop doing what worked in 2026)

In this article, we will discuss:

1. The AI PM Trap of 2027

2. Why Most PMs Will Fail in 2027

3. What a Real Winner Looks Like in 2027

4. The New PM Interviews (AI Interviews 2.0)

5. The 2027 Roadmap to Become an AI PM

It is late at night, and you are scrolling LinkedIn.

One PM has posted a demo of an AI agent she built over the weekend. The next post is about another round of layoffs.

The one after that is a job description that says AI native PM; must have shipped agents in production.

You close the app. You open it again and find Microsoft, Amazon, and Google all planning layoffs.

If you are a Product Manager going into 2027, you are probably feeling this.

Last year you were told to learn AI. You did. You learnt prompting, you built a prototype, you even shipped a small AI feature.

And still it feels like the bar has moved again.

It has. Let me show you where it moved.

The AI PM Trap of 2027

In 2026, the trap was simple. People watched a few YouTube videos on vibe coding and called themselves AI PMs.

In 2027, the trap is more dangerous because it looks like real work.

You built a prototype in Lovable or Claude Code. It worked in the demo. Your manager was impressed. So you think you have made it.

Here is the truth.

A demo that works once is NOT equal to a product that works for a million users (Demo is easy, production is hard)

Prototyping is now table stakes. Every PM can do it. Your intern can do it. So it no longer makes you stand out.

Quick self-check. Give yourself 1 point for every question you can answer with confidence today.

• Can you write evals for your AI feature and tell which ones should be deterministic and which ones need an LLM as judge?
• Can you explain why your agent failed on step 4 of a 7-step task, and not just that the final answer was wrong?
• Can you tell what it costs you every time a user asks your AI one question?
• Can you decide what your agent is allowed to do on its own, and where a human must approve?
• Can you explain what context your model sees, and why giving it more context made it worse?
• Can you price an AI product that does the work, not just helps with the work?

If you scored 5 or 6, you are ahead of most PMs in the market.

If you scored 2 or less, do not panic. But do not ignore it either. This article is for you.

Why Most PMs Will Fail in 2027

The majority of Product Managers will learn AI tools. Very few will learn how AI products actually work.

And in 2027, that difference becomes very expensive.

Three things have changed.

1. First, AI now does the work most PMs were proud of. It writes the PRD, the user stories, the competitor research and even the first prototype. If your value was in writing documents, that value is gone.
2. Second, companies have moved from AI that talks to AI that acts. A chatbot that gives a wrong answer is embarrassing. An agent that books the wrong flight, refunds the wrong customer or deletes the wrong file costs real money. Companies need PMs who can control that risk, not PMs who can make a nice demo.
3. Third, tools change every three months. The PM who only learnt tools has to start again every quarter. The PM who learnt the system underneath (data, models, context, evals, cost) just picks up the new tool and moves on.

2026 exposed the PMs who never learnt AI.

2027 will expose the ones who only learnt the surface of it. I know this is brutal, but this is the truth, and I am definitely sure you don’t want to be the one.

What a Real Winner Looks Like in 2027

The bar has moved one level up. Here is the simplest way to see it.

• 2026 winner built a RAG chatbot. 2027 winner can prove it answers correctly and knows what every answer costs.
• 2026 winner vibe coded a prototype. 2027 winner took that prototype to production with specs and evals.
• 2026 winner knew what an agent is. 2027 winner decided what the agent is allowed to do without asking a human.
• 2026 winner wrote good prompts. 2027 winner designs the full context the model sees.

So a true Product Manager in 2027 should be able to

1. Write evals that catch failures before users do ( Deterministic evals, LLM as Judge, and step-level evals for agents )
2. Design agents with clear permissions: what it can do alone and where a human must click approve ( Autonomy vs Control )
3. Engineer the context, decide which documents, memory and tools the model sees, because more context is not better context
4. Manage the unit economics, cost per task, when a small model is enough and when you need a frontier model
5. Monitor AI in production, because a feature that worked in January can quietly break in March after a model update
6. Price AI products by outcome, per task or per resolution, not only per seat
7. Know when NOT to use AI, and keep simple rule-based flows where the audit trail matters
8. Many More

The New PM Interviews (AI Interviews 2.0)

Interviews have changed again.

In 2026 they asked you questions about AI. In 2027 they ask you to use AI in front of them.

Some interview loops now give you Cursor, Lovable or Bolt and ask you to build a working prototype in about 45 minutes while the interviewer watches. Meta has reportedly added a Product Sense with AI round, where you use AI during the case itself.

The test is not whether you can prompt. The test is whether you can spot when AI gives you a confident wrong answer, and fix it.

Behavioural questions also went one level deeper. Tell me about a trade-off is now: Tell me about a time your AI feature got worse after launch. How did you find out, and what did you do?

They are testing AI Product Sense, Agent Evals, Reliability, Cost, AI Pricing, AI Safety and your judgment on where not to use AI.

Some examples are below

1. Your AI support agent resolves most tickets on its own, but customer satisfaction has dropped. What do you do? ( Evals and Metrics )
2. Write the evals for a travel booking agent that can book and cancel tickets on its own. ( Agent Evals )
3. How would you price an AI agent that does the work of a sales rep? Per seat, per task or per outcome? ( AI Pricing )
4. Model costs drop 10x next year. What changes in your product strategy? ( AI Strategy )
5. You are the PM of a paid AI model. Your biggest enterprise customer wants to move to an open-source model that is good enough and much cheaper. How do you respond? ( AI Strategy )
6. In this product, where would you NOT use AI, and why? ( AI Judgment )

Notice one thing. None of these can be answered with a framework you memorised. You need to have built or broken an AI system to answer them well.

For More Real AI PM Interview Questions (Click Here)

The 2027 Roadmap to Become an AI PM

You need a plan to move from a traditional PM to an AI PM. Here is the step-by-step guide. I have added a checkpoint to every step, so you know when you are actually done and can move on.

This is the same roadmap 800+ PMs have followed in our AI PM Course, including PMs who now ship AI at Google, Microsoft and Coinbase.

#1 Understand Basic AI and ML

→ Machine Learning, Artificial Intelligence, Deep Learning, Generative AI, Linear and Logistic Regression, Decision Trees, Training vs Inference

#2 Learn from Real AI Case Studies

→ How Google, Microsoft, Amazon, OpenAI, Netflix, Nvidia and Uber use AI in their products and pricing

#3 Understand ML Systems and Data Architecture

→ AI Product Lifecycle, AI Data Pipelines, the AI Flywheel, ML System Design

#4 Master Advanced Prompting and Context

→ How to write the Perfect Prompt, System Prompts, Temperature Control, Advanced Prompting ( CoT, ToT, etc. ), getting consistent outputs, deciding what context the model sees

#5 Vibe Coding and Prototyping

→ Beginner to Advanced Vibe coding, Model Parameters, the PM Reliability Framework for prototyping

#6 Understand RAG, Agents and Evals

→ RAG System Architecture, Chunking and Retrieval, RAG Metrics, Designing Agents, Agentic Workflows, Evals, Deterministic and Probabilistic Evals, LLM as Judge

#7 AI Interview Preparation

→ AI Product Sense, AI Success Metrics, AI Pricing, AI Evals, AI Product Strategy ( Real questions like success metrics of GPT 5.0 and evals for a travel booking agent )

#8 Ship One Thing and Show It

→ Build one small AI product end to end, write its evals, and post what broke and how you fixed it

Steps 1 to 8are what the course is built around.

Are You Ready for 2027?

The world is changing fast.

You can keep learning tools that change every three months and feel the stress every time a new one drops. Or you can learn the system underneath them, and become the PM who decides how AI gets built.

Go back to the self-check at the top. Whatever your score is today, you can take it to 6 by the time 2027 starts.

Most Detailed AI Product Management Course ( 50+ Videos, 25+ Case Studies, 20+ Real AI PM Interview Questions )

1000+ PMs have enrolled, including PMs who now ship AI at Google, Microsoft and Coinbase. Highest Rated Course: 4.9 / 5. Testimonials Here

For the New Year, we are giving an EXTRA 40% OFF on our AI PM Flagship Course for a very limited time: Coupon Code: NYE27

Want to build all of this live, with a capstone project and interview prep? Check the AI PM Builder Cohort here

Shailesh Sharma! I help PMs and business leaders excel in Product, Strategy, and AI using First Principles Thinking.

AI Product Management 2027 — Winner’s Playbook was originally published in Agile Insider on Medium, where people are continuing the conversation by highlighting and responding to this story.

A company preparing to sell digital-security software through monthly and annual subscriptions needed a way to organize its development work as the business took shape. Its technical and business teams had to translate priorities into software work, follow progress and raise the decisions that could change the plan. That required a delivery process people could actually use, not simply a configured project-management tool.

This article was drafted with AI writing assistance using my earlier consulting experience, with factual review and editorial revisions.

I worked on that Agile kickoff as an independent consultant and project manager. My involvement covered workflow analysis, implementation and operational planning, Jira project configuration and support for the people adopting the process. I also used the AI tools available at the time to assist with early research, planning and workflow material. The work was about making an operating structure usable across functions; it was not a later Tech Manager’s Playbook consulting engagement.

The team did not need another explanation of Scrum

Several people were already familiar with Agile. I was not arriving to teach an unfamiliar team what a sprint was, nor was Jira the company’s first encounter with the idea of tracking work. The practical challenge was getting technical delivery, business priorities and management review to refer to compatible information.

A business priority and a development task occupy different levels of detail. The priority explains why an investment in work matters; the task specifies what someone is expected to do next. Between them sit clarification, scope decisions, stories, estimates and agreements about when work is ready. A project board can hold those records, but its existence does not establish that the team understands them the same way.

That distinction affected how I approached the setup. I prepared the planning structure, worked through the process with the relevant functions and configured the Jira projects around the intended way of working. The end product of the engagement was a workable operating setup and direct support for adoption. I do not have authenticated client figures that would let me claim a particular adoption percentage, faster delivery cycle or return on the initial AI-assisted planning work.

A delivery update has to explain what changed

The retained communication templates from this work provide a useful view of the reporting problem. One sprint-demo information radiator connects planned and completed user stories with point estimates, narratives, risks and lessons. Another, the Big Visual Information Radiator (BVIR), is structured to bring delivery information into management review.

The example stories in those materials include software-site security checks, customer-review moderation and sales reporting. Their story points and sprint charts are instructional figures, not verified records of what the client shipped. I find the format useful because it demonstrates how easily a team can separate the numeric view from the explanation that gives the numbers meaning.

A burn-down or burn-up chart answers a legitimate question about progress under a defined measurement method. It does not, by itself, tell a manager whether a security dependency is still open, whether new scope has changed the expected outcome or whether a business decision is needed before the team can continue. The person receiving a progress report should not have to reconstruct those issues from scattered comments on individual tickets.

I would therefore use a reporting model that connects three things: the accepted work, the current impediments and the next decision. The metrics should be calculated from reviewed delivery records. Risks and dependencies should have their own path into management review, rather than being converted into a favorable or unfavorable chart color without context. This is a management-design recommendation drawn from the engagement and supporting templates, not a claim that every detail of that model was implemented at the client.

Where agreement needs to exist before a sprint moves

The part of the setup I would examine most closely in another company is the agreement between the person requesting work and the people expected to deliver it. When a new priority arrives, someone must decide what it means, how it relates to the existing work and which questions need answers before an estimate is dependable.

Consider an incomplete request to change a subscription-software workflow. It might be possible to create a Jira story immediately, but that would not clarify the intended behavior, business priority or acceptance expectations. The example is illustrative; I am not attributing a specific unresolved subscription change to the historical client. The broader point is that teams need an agreed route for clarification before unfinished assumptions become commitments.

In practice, I would ask the group to agree what makes an item sufficiently prepared to discuss, who can clarify disputed scope, how technical estimates are reached and who can authorize a consequential change. These agreements do not require a complicated governance committee. They require the people participating in delivery to know which decisions are theirs and what evidence another person needs from them.

The same principle applies after a sprint starts. A status update should distinguish accepted completion from work that merely appears finished on the board. When management changes a priority, the resulting scope and capacity trade-off should be made visible rather than hidden by moving cards between columns. Jira can make the current state easier to inspect; it cannot decide whether the business is accepting a different commitment.

What I would change if I ran this kickoff today

If I were helping a similar SaaS business now, I would test one bounded handoff before automating the whole delivery operation: business request to development-ready backlog item. I would trace actual requests, count how often they came back for missing information and examine how much human correction effort the preparation required.

I would then divide the work by the type of control needed. Jira rules could check required fields and route incomplete items for review. AI could draft a story from permitted source documents or identify differences between two versions of a requirement. People would still decide scope and priority, estimate the technical work and accept the item as ready. That division is a proposal for a modern setup, not a description of an AI agent or an automated rule system deployed in the earlier consultancy.

I would bring the same separation into reporting. Progress indicators could be calculated from reviewed project records; AI might help prepare a source-linked narrative about what changed. A management decision would remain a decision made by an accountable person. Success would be measured in fewer returned items, less clarification effort and clearer decisions, not simply in the number of stories an assistant could draft.

The lesson I kept from the kickoff

The engagement produced practical planning and operational materials, configured Jira projects and support for teams learning to use the setup together. It did not produce a verified productivity percentage I can responsibly repeat here. What it reinforced for me was that a team’s familiarity with Agile does not remove the need to agree how business direction reaches delivery and how delivery evidence reaches management.

That is the work I would protect in any future kickoff. A board that shows activity is useful, but leaders also need to know whether the activity serves an agreed priority, what could change the plan and whose decision is required next. If those connections are weak, a more elaborate dashboard will not settle them. The operating agreement has to come first.

By M. Mohammad · The Tech Manager’s Playbook. Based on a previous independent consulting engagement. Example planning figures are illustrative; present-day AI and Jira automation suggestions are proposed improvements.

From Jira Setup to Management Decisions: The Operating Agreement Behind Agile Delivery was originally published in Agile Insider on Medium, where people are continuing the conversation by highlighting and responding to this story.

In modern software development, work is almost always broken down into smaller pieces. Because software projects are inherently complex — no single person can hold all moving parts and interdependencies in their head at once — a large project gets sliced into features, and those features get chopped into tasks and tickets. The idea behind this structure is sensible: breaking a complex problem into smaller units makes the work easier to estimate, track, and complete.

However, this breakdown creates an unintended side effect in how people view their responsibility. When work is reduced to small, boxed-in units, accountability shifts from the outcome of the project to the execution of individual tasks. A visual analogy could be the gap between the pixel and the picture.

The View from the Pixel

When a specific task is assigned to you, your objective is straightforward: You read the requirements, write the code or design the layout, test it, and move the item to “Done.” If every requirement in that task description was met, you did your job correctly. From the perspective of the tracking system, you succeeded.

The problem arises when everyone on a team completes their individual tasks correctly, but the overall project still fails to solve the user’s problem or deliver business value. A strange paradox occurs: The product fails, but no one made an obvious mistake. Everyone can point to their completed tasks as proof of good work.

When responsibility is attached to only a small unit of work, it becomes rational for individuals to stop looking at the larger context. If your performance is measured by how many items you move across a board, spending time questioning whether the feature actually makes sense feels like an unnecessary risk.

How the System Encourages Passivity

When teams operate this way long enough, a subtle cultural shift happens: People stop “thinking along” with the broader business goals. Instead of asking, “Will this approach actually help our customers?” team members learn to ask, “Is this explicitly written in the task description?”

This is not being lazy or indifferent. It is a direct response to how work is organized — and when systems reward the completion of isolated tickets, they also discourage people to take ownership over the overall outcome.

Consider how this plays out in daily decision-making:

• A developer notices that a requested feature contradicts a decision made two months ago. If they raise the issue, the current task gets delayed. If they build it as requested, their task is marked “Done” on time.
• A designer sees that a workflow will confuse users, but the specification was already approved by product management. Fixing it requires re-opening a debate. Following the specification keeps the task on schedule.

In both cases, the system incentivizes taking the narrow view. Completing the ticket protects the individual worker, even if it harms the overall project.

The Accountability Hole

When every team member focuses strictly on their assigned piece, an accountability hole opens up in the middle of the project. The individual tasks are owned, but the connection between those tasks and the ultimate goal is not. Responsibility falls into the space between the tickets.

If a project fails under this model, no single person feels responsible because no single person had visibility or authority over the whole picture. The system allows everyone to defend their work while the collective effort produces a poor result.

Reclaiming the Big Picture

Fixing this problem means changing how those tasks are evaluated. A task should not be considered complete simply because its criteria were checked off. Completion requires a two-step check:

• Did we build what the task specified? (Verification)
• Does this piece still make sense in the context of the overall goal? (Validation)

When teams are given the space and encouragement to ask that second question, work stops being a mechanical exercise in closing tickets. People begin to share responsibility for the final outcome, rather than just the pieces they were assigned to build.

Pixel vs. Picture: How Systemic Ticket-Fixing Weakens Product Ownership was originally published in Agile Insider on Medium, where people are continuing the conversation by highlighting and responding to this story.

An internal IT organisation receives its budget once a year, and with it an expectation that is rarely written down but always present: next year, more for the same money, or the same for less. The budget is a number. The demand placed on the organisation is not. The backlog grows faster than it is worked off, every request arrives marked as important, and the prioritisation meeting has become the place where disappointment is allocated rather than work. However much the organisation delivers, it is perceived as slow, because what it delivers is measured against what it has been asked for, and what it has been asked for has no upper bound.

This is the ordinary condition of a cost centre. Mary Poppendieck described it plainly: a cost centre is measured on its costs and little else, its budget rarely rises when times are good, and it is the first to be cut when they are not.¹ Inside that frame, the demand side looks like a nuisance to be managed. It is more than that. It is the reason the efficiency the budget holders expect cannot show up where they are looking for it.

Where the gains go

In 1865 William Stanley Jevons argued that it is “wholly a confusion of ideas to suppose that the economical use of fuel is equivalent to a diminished consumption.”² Cheaper use of coal widened the uses to which coal was put, and consumption rose. Transport economists later found the same pattern on roads: adding lanes to congested highways brings more traffic, roughly in proportion to the added capacity, and the new traffic is mostly created rather than diverted from elsewhere.³

The road case is the closer analogy, because of the currency in which the price is paid. A driver on a free road pays in time. Yoram Barzel showed that when a good carries no money price, waiting becomes its whole price, and demand responds to it exactly as it would to a price in money: fall, and more is demanded.⁴ A requester in internal IT is in the same position. Asking costs nothing in money; the only price is the wait. When IT becomes more efficient and delivers more, the wait shortens somewhat, requests that were not worth waiting for become worth making, and the capacity gained is taken up by demand that did not exist before. The wait need not return to where it was. What returns is the full backlog.

The consequence is easy to state and hard to see from above. An efficiency gain can be taken in one of two forms: as lower cost for the same output, or as more output for the same cost. With demand unconstrained, the organisation does not get to choose. The choice is made silently and always in favour of output. And because the backlog does not shrink, the added output is invisible too. Management sees neither the saving it expected nor the extra delivery it received.

The usual response is to defend the budget by arguing for the value of what IT delivers, in business cases, benefit estimates and value scores. That route does not hold, for reasons argued at length elsewhere: the worth of a specific piece of work is a counterfactual no instrument can read, so it cannot serve as the signal that justifies a cost or steers a portfolio.⁵ There is a different lever, and it sits on the other side of the ledger. Instead of justifying the cost, limit the demand. The claim is not that the absorbed demand is worth little. Nobody can know that. The claim is that without a limit the organisation has lost a decision it should own: whether a given efficiency gain is to be taken as cost or as output.⁶

Why nothing limits it

In a market, placing an order is not free. Whoever orders commits to pay on delivery, and that commitment limits demand. It also carries information: a buyer who pays reveals, at least, that the purchase was worth the price to them.

Internal IT is the special case. The requester does not pay, or pays in a way that never reaches them in a feedback loop they perceive. The budget is held elsewhere, the charge, if there is one, lands on a cost centre, and the person who asked for the change experiences none of it. Health economists have a name for the result. When insurance reduces the price of care at the point of service to zero, demand rises wherever it responds to price at all. Mark Pauly called this moral hazard and was careful to add that it has little to do with morals: it is rational behaviour, because each user bears only a sliver of the cost of their own use.⁷ The same holds for the business colleague who files one more request. Nothing about the request is illegitimate. It is simply free.

Pauly also reports an observation of James Buchanan’s about the British National Health Service that fits internal IT uncomfortably well: people demand care as though it were free, yet when they vote on the budget, they provide for less than they demand. An organisation does the same with its IT. The budget is set centrally, with cost in view. The demand is exercised locally, with cost out of view. Both decisions are reasonable where they are made, and they do not add up.

Donald Reinertsen put the requirement into a single principle for product development: “ensure decision makers feel both cost and benefit.”⁸ The internal requester is a decision maker who feels the benefit and not the cost. Demand then does two things. It grows without limit, and it stops carrying the requester’s own estimate of what a request is worth to them, since nothing forces that estimate to be made. Many requests may matter little to those who make them; nobody can tell which.

This is a claim about internal services, and only about them. It does not generalise to markets, where the promise to pay is itself the cost.

Three limiters that miss

Organisations do limit demand, whether they intend to or not. The three common ways each fall short, and the way each falls short points to what a working limiter would need.

The first is the queue. Waiting does limit demand, as Barzel’s analysis requires, but it does so by consuming what it rations. For the marginal person in a queue, the time spent waiting exhausts the entire worth of the good: in his phrase, “If there is a free lunch, it will come to have zero value.”⁹ The queue also selects by the wrong property. Who waits depends on how cheap waiting is for them, not on how much the thing waited for matters. And in IT it rewards a further behaviour: requesting early and speculatively, to hold a place in line for something that may be needed later.

The flow tradition’s answer is admission control. Poppendieck’s advice to firms facing more demand than they can serve is not to accept work faster than the bottleneck completes it, and then to grow capacity to meet the rest.¹⁰ WIP limits at the commitment point do the same inside the system. Both protect flow. Neither limits demand. They move the queue upstream of the point where work starts, and the requester’s price is still the wait. Her second step, growing capacity, is exactly what unconstrained internal demand absorbs. And a firm can turn customers away. An internal IT organisation generally cannot turn away its own business.

The second limiter is a budget or a price. Chargeback bills departments for what they use; showback shows them the cost without billing it. Reinertsen goes further and proposes internal markets to decentralise control, and prices that rise with congestion to push demand out of busy periods.⁸ On roads, where the traffic economists concluded that only congestion pricing is left as a remedy, this works because the driver pays.³ Inside a company it does not, because the money lands on a budget and the budget belongs to someone other than the person asking. A price paid by the cost centre changes the cost centre’s accounts, not the requester’s behaviour. The variant that reaches the requester directly is a quota: Kent Beck suggests giving customers a share of development capacity to use as they please.¹¹ A quota does make each requester ration. But sizing the shares means deciding in advance where capacity will pay off most, which is the same value knowledge that the budget route lacks.

The third limiter is the hurdle: the request form, the business case template, the approval step. Public economics calls these ordeals, deliberately imposed costs that are pure deadweight, accepted because they sort applicants.¹² They filter. But they burn the time they cost, and they sort well only under conditions that, as the next sections show, internal IT tends to violate.

Each of the three either fails to reach the requester or destroys what it charges. A working limiter would need to do neither.

A cost that produces

There is a cost that reaches the requester personally and does not destroy what it charges: the requester’s own active participation in the work. Providing the information the work depends on, clarifying what is meant, taking part in refinement, reviewing early versions and saying what is wrong with them. Time spent this way limits demand, because it is time the requester must find. And it improves the result, because it is spent on the result.

Barzel draws the relevant distinction. A money price is a transfer: what the buyer pays, the producer receives. Time spent in a queue is captured by nobody.⁹ Participation adds a third case. Set side by side, the three mechanisms differ in what happens to the price once it is paid. An ordeal is negative-sum: the time is burned. A price is zero-sum: the money moves from one budget to another. Participation is positive-sum: the price is paid in a currency that raises the worth of what is bought. The comparison has a limited scope and should be read that way. It compares what each mechanism costs the organisation, not how accurately each one separates important requests from unimportant ones. Filtering is a different question, and it is the one on which participation struggles.

Why the time is productive in IT specifically has to do with what IT works on. In product development, the process a product supports usually lies outside the organisation that builds it. In enterprise IT, the work object is a business process running through systems the same organisation owns, and the process belongs to the business.¹³ The two sides then hold different halves of what a change needs. The business knows how it wants to work. IT knows which systems the process touches, how the data flows between them, and which governance and compliance obligations apply, much of which the business never sees. Elinor Ostrom, one of those who developed the concept of coproduction for public services, named the condition under which contributions from two parties produce more than either alone: the inputs must complement each other rather than substitute for one another, so that “each has something the other needs.”¹⁴ In enterprise IT that condition is met by construction. Collaboration is not a courtesy extended to the business. The work cannot be specified without it.

This answers the objection that arrives first: that the business experts are too expensive to spend their time with IT. Their time is a real cost, though a cost to the organisation, not to them. The honest comparison is not with an afternoon saved. It is with building without their knowledge, and with what follows from that. John Seddon calls demand caused by a failure to do something, or to do it right, failure demand, and argues that the greatest lever on a service system is to change the characteristics of its demand.¹⁵ Work built on a guess about intent comes back as rework and follow-up requests. Participation reduces that share. So it limits demand in a second way, not by deterring requests but by removing the ones the organisation creates for itself.

None of this makes coproduction a discovery. Ostrom and her colleagues developed the concept in the late 1970s. The Agile Manifesto’s fourth principle holds that business people and developers must work together daily.¹⁶ Beck lists real customer involvement as a practice, with the stated aim of cutting waste by bringing those who have the needs together with those who can meet them.¹¹ What these accounts share is that they treat participation as a benefit, something a customer might even pay for. What is proposed here is narrower: using the cost of participation as the limit on demand, so that the mechanism which constrains how much is asked for is the same one that improves what is built.

Where it breaks

A mechanism proposed as the answer deserves the same scrutiny as the ones it replaces, and this one has a structural weakness. It works through two effects, and they pull against each other.

The limiting effect needs the time to feel costly to the requester. The contributing effect needs the time to be given willingly and competently. A requester who resents the hours participates grudgingly, and grudging participation contributes little: the review is skimmed, the question is answered by whatever is quickest. A requester who enjoys working with IT, or has slack, contributes well and feels no limit. The mechanism works only in the band where the time is costly enough to make people choose and meaningful enough that they do not disengage.

The sorting also runs the wrong way. Albert Nichols and Richard Zeckhauser argued that ordeals sort well when their cost falls inversely with the benefit, so that those who need something most find the hurdle cheapest.¹² A time requirement in IT does the opposite. It is most expensive for the busiest people, and the busiest are often the domain experts with the most consequential requests. Left to itself, a participation requirement deters first the requesters whose participation would help most. And where IT could in fact do the work alone, where in Ostrom’s terms the inputs substitute for one another, participation adds nothing and becomes an ordeal again.¹⁴

Then there are the two ways the cost escapes. The first is delegation. The requester sends someone junior, who has the time but not the knowledge. The limit disappears, because the requester is no longer paying, and the contribution disappears, because the person paying cannot supply it. The second is displacement, and in IT it is the default. The work of clarifying, specifying and deciding moves to a role on the IT side: the product owner, the business analyst, the requirements engineer. In IT that role often slides towards proxy for the business colleagues, and at its extreme towards order taker. Beck is blunt about proxies: working without a customer, or with a stand-in for one, produces waste: features that go unused, and tests that miss what acceptance really requires.¹¹ Displacement preserves the requester’s zero cost by design. It also meets a second obstacle. The role that absorbs the work would need to shape the business process to do it well, and business colleagues typically reject IT influence on how they work. That is Ostrom’s second condition failing: coproduction requires that both parties have real options, and here one of them does not.¹⁴

Last, incentives. Where requesters are rewarded for their “real” work, and their bonus depends on it, every hour spent with IT is an hour taken from what they are measured on. Participation under those terms will be grudging or delegated, whatever the policy says.

The failure-demand effect survives all of this in part, since fewer self-inflicted requests are fewer requests regardless of how willingly anyone participated. But it does not resolve the tension. It only means the mechanism is not all-or-nothing.

Who can install it

Every failure mode in the previous section has the same shape. The mechanism binds the requesters, and IT cannot bind the business. It cannot require business colleagues to participate, it cannot stop them from delegating, it cannot give its own roles influence over business processes, and it has no say over how business colleagues are rewarded. Whatever form the limit takes, it has to be put in place by someone with authority over both sides.

That is the lowest position in the hierarchy where business and IT share a superior. In a divisional organisation with its own IT, it may be the head of the division. In a company with a shared IT function, it is the chief operating officer or the chief executive. The position that can install a limit on demand is, in the typical case, the one furthest from the work.

What that position has to do is specific, and the form matters. Ostrom’s fieldwork includes cases where coproduction withered under top-down command: central authorities took over schools that villages had regarded as their own, ran them by decree, and village contributions dwindled.¹⁴ A decree that the business shall participate would repeat that failure. The top position’s job is to make the requirement binding, so that participation is a condition for work to start, not a favour IT can only ask for; to give both sides real options, including IT’s standing to shape the processes it builds; and to remove the incentives that punish participation. How participation happens is best left to the people doing it.

The same office holds the expectation of yearly efficiency gains, the authority to limit demand, and the incentives that decide whether participation is real. That is the case to take to it. Without a limit on demand, an efficiency gain in IT can only ever appear as more output, never as lower cost, and no amount of value justification will change the arithmetic. With a limit, the organisation can decide which of the two it wants. The limit that serves this purpose best is not a price and not a hurdle. It is the requirement that those who ask for the work take part in it.

¹ Mary Poppendieck, “The Cost Center Trap”, Lean Essays, 5 November 2017, https://www.leanessays.com/2017/11/the-cost-center-trap.html. Her remedy, steering IT by business outcomes, is a form of value steering; see note 5.

² William Stanley Jevons, The Coal Question, 1st ed. (London and Cambridge: Macmillan, 1865), ch. VI, “Of the Economy of Fuel”, p. 103.

³ Gilles Duranton and Matthew A. Turner, “The Fundamental Law of Road Congestion: Evidence from US Cities”, American Economic Review 101(6) (2011), 2616–2652. The authors conclude that neither more roads nor more public transit relieves congestion, leaving congestion pricing as the main candidate remedy (p. 2646).

⁴ Yoram Barzel, “A Theory of Rationing by Waiting”, Journal of Law and Economics 17(1) (1974), 73–95, at p. 75.

⁵ See also “Steering by Value: The Signal That Isn’t There” for why the worth of a bet cannot serve as a control signal.

⁶ See also “Steering by Value: The Only Decision You Control” on the commitment as the one decision fully in anyone’s hands, and why it has to be an owned judgement

⁷ Mark V. Pauly, “The Economics of Moral Hazard: Comment”, American Economic Review 58(3), Part 1 (1968), 531–537, at pp. 532, 534–535. The observation attributed to Buchanan is reported in Pauly’s note 1, p. 533, citing James M. Buchanan, The Inconsistencies of the National Health Service (London: Institute of Economic Affairs, 1964).

⁸ Donald G. Reinertsen, The Principles of Product Development Flow (Redondo Beach: Celeritas, 2009): E14, the First Market Principle (p. 42); F4, the Principle of Congestion Pricing (p. 176); D20, the Second Market Principle (p. 262).

⁹ Barzel, “A Theory of Rationing by Waiting”, pp. 74, 80, 83 (note 16), 87–88.

¹⁰ Mary Poppendieck, “When Demand Exceeds Capacity”, Lean Essays, 11 June 2022, https://www.leanessays.com/2022/06/when-demand-exceeds-capacity.html

¹¹ Kent Beck with Cynthia Andres, Extreme Programming Explained: Embrace Change, 2nd ed. (Boston: Addison-Wesley, 2004), ch. 9, “Real Customer Involvement”.

¹² Albert L. Nichols and Richard J. Zeckhauser, “Targeting Transfers through Restrictions on Recipients”, American Economic Review 72(2) (1982), 372–377, at pp. 376–377.

¹³ See also “The Estate Is Not a Tree”, section “Why this lands on IT”, on why the business process runs inside the enterprise IT estate, not beyond it.

¹⁴ Elinor Ostrom, “Crossing the Great Divide: Coproduction, Synergy, and Development”, World Development 24(6) (1996), 1073–1087, at pp. 1073, 1079–1082; the Nigerian cases at pp. 1076–1078.

¹⁵ John Seddon, Freedom from Command and Control: Rethinking Management for Lean Service (New York: Productivity Press, 2005), pp. 37–38.

¹⁶ “Principles behind the Agile Manifesto”, 2001, https://agilemanifesto.org/principles

Limited Budget, Unlimited Demand was originally published in Agile Insider on Medium, where people are continuing the conversation by highlighting and responding to this story.

Explained via a Real Case Study

Imagine you are a product manager at a food delivery company.

You own the customer support experience.

Monday morning, you open the dashboard.

Yesterday, your support team got 4,000 refund requests. One support executive takes about 6 minutes per request.

So that is 400 person-hours every single day. Your manager wants this to be under one minute per request using AI. Finance wants to make sure we don’t refund money we don’t owe.

You have two weeks. In these two weeks, you will come across eight terms.

You will not learn them from some glossary.

You will learn them because each one is either a problem you hit or the fix for it. So read in order. Each term solves the problem the previous one created.

1. Agents

This is what you see: day one, you ship a chatbot.

A customer writes that two items are missing from the order. The model writes a very polite reply. You watch the ticket. The chatbot cannot check the order. It cannot see the delivery photo. It cannot issue the refund. A human is still doing all of that. Handling time goes from 6 minutes to 5. You are nowhere near one minute.

This is what you learn: an agent is a model that can take actions, not just write text. You give it tools. It calls a tool, reads the result and decides what to do next. It keeps going till the job is done.

This is what you do: day two, you give the model four tools.

Read the ticket. Look up the order. Fetch the delivery photo. Issue a refund.

Now, for the same missing items ticket, it looks up the order, sees two items marked undelivered by the rider, refunds Rs 180 for those two items and writes the reply. Nobody from your team touched it.

See, a chatbot answers. An agent finishes the task. That is the whole difference.

Our next AI Product Manager & Builder Cohort is starting. For an early-bird discount, you can fill out the form here: AI PM Builder Cohort

[Alumni Shipping at Google, Microsoft, Uber]

2. Harness

This is what you see: day three, finance pings you.

The agent has refunded a full Rs 2,400 order. You open the ticket. The complaint was one cold dish. The customer asked for a full refund; the model agreed, and nothing stopped it. You go to check the logs. There are no logs.

This is what you learn: the model was not the problem. The problem was everything around the model. That everything is called the harness.

Which tools the agent gets. What the system prompt says. What limits apply. What gets logged. When a human steps in. Most of an agent’s quality lives here and not in the model. This is why you are hearing this word everywhere in 2026.

This is what you do: four changes to the harness. Any refund above Rs 500 needs human approval. Refund is capped at the value of the items the customer actually complained about. Every tool call is logged with the reason. The written refund policy goes into the system prompt.

Same model. Different harness. The Rs 2,400 mistake cannot happen again.

3. MCP (Model Context Protocol)

This is what you see: your agent needs order data, rider data and the payments system. Your engineers write custom code to connect each one. Each connection takes around a week. Day five, the rider team changes their API without telling anyone.

Your agent is down for a full day. Now you have three integrations and each one is something that can break.

MCP is a standard way for a model to connect to tools and data. Anthropic released it in late 2024, and today most major AI platforms support it. A team exposes its system once as an MCP server. After that, any agent in the company can use it, no new code needed.

You ask the payments team to build one MCP server with two tools, lookup_order and issue_refund. Your agent uses it.

Two months later, the marketing team’s agent uses the same server for order lookups. Nobody writes that connection again.

Your question to engineering changes. You stop asking whether we can build an integration. You start asking whether we have an MCP server for this.

4. Skills

The refund agent is working. Day six, your manager asks you to also handle the where is my order tickets. That is 3,000 more a day. Your system prompt is already 1,800 words of refund policy. You add the tracking rules. Now the prompt is 3,200 words. And refund accuracy drops, because the model is reading two policies for every ticket and mixing them up.

A skill is a folder of instructions, examples and scripts that the agent loads only when a task needs it. The main prompt stays short. The detail lives in the skill.

You split the prompt into files.

• skills/refunds/SKILL.md has the refund policy, 12 worked examples and the edge cases
• skills/order-status/SKILL.md has the tracking rules and the rider delay thresholds
• The main prompt is now 200 words. It only says which skill to open for which ticket type

A refund ticket loads only the refund skill. Accuracy goes back up. When policy changes, you edit one file.

5. Loop engineering

The agent is now running 7,000 times a day. You cannot read 7,000 outputs. Day nine, you pull a sample of 200 tickets.

In 6 of them the agent called lookup_order 20 times one after another because the order ID was wrong, then gave up and refunded anyway. You realise nobody ever decided when the agent should stop, when it should retry and when it should ask for help. The agent decided on its own, and badly.

That decision is loop engineering. The term was picked up in June 2026 after an essay by Addy Osmani and posts by Peter Steinberger and Boris Cherny all said the same thing. Stop prompting the agent one turn at a time.

Design the loop that runs it. A loop has four parts. Do the work. Check the work. Retry if the check fails. Stop at a limit and hand over.

This is what you do: you write the loop for one ticket.

1. The agent reads the ticket and drafts a decision with reasons
2. A second, cheaper model checks the draft against the refund policy
3. If the check fails, the agent retries once with the checker’s note
4. If it fails again, or crosses 8 tool calls, the ticket goes to a human

The 20 lookup problem is gone. You stop thinking about the prompt. You start thinking about the loop.

6. Computer use

Around 8% of tickets involve a third-party rider partner. Their delivery photos sit inside a web dashboard which has no API. Your agent cannot fetch them. So those 560 tickets a day still go to a human, and they are the slowest ones because the human has to log in and search manually.

Computer use lets a model operate a screen the way a person does. It takes a screenshot, finds the right button, clicks, types and reads whatever comes up. It works on any website or app, even the ones built with no AI in mind.

You add a computer-use step only for those 8% of tickets. The agent logs into the partner dashboard, searches the order ID, opens the photo and brings it back into the normal loop. It takes around 40 seconds instead of the 2 seconds an API call would take. It fails maybe one time in twenty, and those go to a human.

You use it because the alternative is 560 human tickets a day. Computer use is slow and less reliable than an API. It is the right choice only when there is no API.

7. GEO / AEO

Week 2, you notice a new type of ticket. Customers are asking why the refund takes 7 days. Your policy is 48 hours. You ask three of them where they got 7 days from. All three say they asked ChatGPT or Google AI mode before writing in. You try it yourself. The AI answer says 7 days. It is picking that up from some 2023 blog post, because your own help page has the policy buried in paragraph six.

GEO is Generative Engine Optimisation. AEO is Answer Engine Optimisation. In practice, both mean the same thing. SEO was about ranking in a list of links. GEO is about being the source the AI answer reads and quotes. If the AI cannot find a clear answer on your page, it will pick one up from somewhere else.

You rewrite the help page. The first line states the policy in one sentence. Each heading is a question a customer would actually type. The refund timeline is a small table, not a paragraph.

Three weeks later, the AI answer says 48 hours. The 7-day tickets stop.

8. AGI / Superintelligence

Day 13, a new model gets released. It is cheaper and scores higher on every benchmark than the one inside your agent. Your agent is not even two weeks old and the model inside it is already not the best option. And this will happen again in a few months.

AGI means artificial general intelligence, an AI that can do most cognitive work at the level of a capable human, across any field. Superintelligence means an AI that is better than the best humans at that work. Neither exists today. Every major lab says it is building towards them. Because they are racing, the model inside your agent will keep getting cheaper and better, on a schedule you do not control.

You take one design decision. Everything in sections 2 to 6 is built such that the model is a swappable part. The harness, the MCP servers, the skills and the loop do not depend on which model is running inside. When a better model comes, you change one line of config and rerun your 200 test tickets.

The model is the part that keeps changing. The system around it is what you own.

About Author

Shailesh Sharma! I help PMs and business leaders excel in Product, Strategy, and AI using First Principles Thinking.

AI Learning Resources

1. 12 Weeks LIVE AI PM Cohort (Alumni now ship AI at Google/Microsoft, etc)
2. Self-Paced AI PM Cohort Recordings (65 Hours of Content) | Use AIBUILDER20 for 20% Discount [Alumni Shipping at Google, Microsoft, Uber]
3. Quick AI PM Course (20 Hours of Content) [ Rated 4.9/5 from 1000+ Product Managers from Google, Coinbase, Microsoft, etc]

8 New AI Terms You Should Know to Be Ahead of 99% of People was originally published in Agile Insider on Medium, where people are continuing the conversation by highlighting and responding to this story.