Teams often describe Agile delivery through ceremonies: planning, stand-ups, reviews, and retrospectives. Those routines matter only when they help a team learn whether the product works as intended. In a custom loyalty-management build I managed in late 2024, the critical question was never whether each team had completed its individual task. It was whether a customer action produced the right outcome across the connected system.

The solution supported an event-ticket business and included a customer-facing website, a loyalty-management backend, and an admin portal. The loyalty logic involved accumulated purchase value, purchase frequency, customer tiers, activity windows, dormancy monitoring, and promotional rules. A customer could buy a ticket on the website, receive confirmation and a future-purchase offer, affect their loyalty segment, and create information that administrators needed to see. Testing any one component in isolation would have provided only partial evidence.

Start with an agreed rule, then organise the work around it

The project began with a loyalty-model challenge. Product and marketing needed to define segmentation and customer activity in a market where competitors did not publicly disclose their management rules. They reviewed competitor systems and developed a research-based white paper. I worked with those teams to finalise requirements and turn the approved logic into stories and tasks for the development team.

The resulting programme used Bronze, Silver, and Gold tiers based on accumulated purchase value. It also monitored purchasing activity through 30-day intervals and used a 90-day inactivity window for retention monitoring.

The specific thresholds and detailed eligibility logic are confidential, but the agreed requirements gave the teams an operational reference for delivery.

That reference mattered more than a backlog alone. It allowed the team to ask whether each feature behaved as the business intended, rather than merely whether it had been built.

Integration was part of delivery, not a final phase

Documentation came first. The customer-facing website and loyalty engine followed, while the admin portal developed in parallel with frontend/backend work and the integration of all components. The work had to progress together because meaningful testing depended on the system being connected.

This approach did not mean every team waited for every other team before starting. It meant that the delivery plan treated integration as a continuous concern. The team coordinated product, marketing, design, frontend, and backend work through biweekly sprints, story preparation, task assignments, daily coordination, dependency management, reviews, and testing iterations.

Requirements remained stable once development began. That helped the team focus on building and validating the agreed model rather than repeatedly reworking the logic. Stability did not remove the need for feedback; it made the feedback more useful because the team had a clear reference against which to judge the result.

The feedback cycle had several layers

The client was involved through a daily meeting, a Friday review and demonstration each week, and a retrospective at the end of each biweekly sprint. The cadence created regular checkpoints for looking at progress, discussing work in context, and preparing for the next iteration.

At the feature level, development QA came first. Product and marketing then carried out what the team called an AB-testing stage, reviewing completed functions against the expected behavior described in their white paper. The term refers here to the internal review process, not to a public claim about a statistical A/B experiment.

The full system received final testing when all components were complete and ready for release preparation. There was no MVP launch because the intended release approach was for the complete connected system. Documentation and completed milestones were reviewed and handed over in stages, and the client accepted the system within approximately three months.

The Agile lesson is about usable feedback

A stand-up does not prove that a loyalty rule works. A completed story does not prove that the website, backend, and admin portal agree about the customer’s status. The evidence comes when the connected workflow can be tested against an agreed business rule and reviewed by the people who own that rule.

For delivery leaders, the practical question is simple: where does the system require connected evidence before a feature can be called ready? Identify those paths early, plan integration alongside feature work, and make the expected behavior visible to the people who will review it. That is how Agile routines become a learning system rather than a reporting schedule.

M. Mohammad writes The Tech Manager’s Playbook, on practical AI workflows for project managers and business analysts. 10+ years running software delivery: custom client builds, SaaS, and regulated MedTech.

How an Agile Feedback Loop Kept a Connected System Testable was originally published in Agile Insider on Medium, where people are continuing the conversation by highlighting and responding to this story.

The argument is sincere, the frustration is real, and the conclusion is wrong. There is no backward movement. The work item did not return to Development, because the board does not show what the argument assumes it shows.

This essay is about what a Kanban board actually models, what it does not model, and why getting that distinction right dissolves the backflow argument before it can be had. The argument matters here because it is unusually persistent, unusually corrosive to team dynamics, and unusually traceable to a single conceptual confusion. Other arguments about flow, about feedback, about the linearity of boards, will keep for other essays. This one stands on its own.

What the board actually represents

A Kanban board is a representation of the state space of the work items flowing through a system. Each region of the board corresponds to a state. Each work item resides in exactly one state at a time. Movement of a work item between states is a state transition, and state transitions are governed by policies: the conditions under which a work item is permitted to leave one state and enter the next.

This is a precise claim, and it has formal grounding. The mathematics of state spaces and transitions is among the most worked-over territory in computer science and operations research. Finite-state machines, statecharts, Petri nets, workflow nets: these are different formalisms, but they share a foundational distinction that the board inherits whether we acknowledge it or not. They distinguish between the state of an object (what it is, where it is in its lifecycle) and the actions that operate on that object (what is done to move it from one state to another).

A state is a property of the work item. An action is something a person does. The two are not the same kind of thing, they do not live on the same plane, and confusing them produces exactly the dysfunctions this essay is about.

A board models the state space. It does not model the action space. The action space is what people are doing, which person is doing what, which skills are being applied, which roles are involved. None of that belongs on the board, because none of it is a property of the work item. It is a property of the team’s response to the work item, and the response is not the work item.

This is not a stylistic preference. It is a categorical distinction. Putting actions on the board is a category error, in the technical sense: it conflates two kinds of object that the underlying model treats as separate, and the conflation creates problems that no amount of practice discipline can clear up, because the problems are baked into the model.

A note on vocabulary, while we are being precise. The word column is convenient and visually accurate for most boards as they happen to be drawn, but it carries a table-like connotation that the underlying model does not share. A workflow is not a table. The board is a depiction of states and the transitions between them, which is a structure better described as a graph than a grid. The visual choice to lay states out as vertical regions is just that, a visual choice, and nothing in the model requires it. Where this essay refers to states, the reader can substitute the visual region of the board they happen to inhabit. The substitution is in the right direction; the reverse one is not.

What this means for the famous backflow

Return to the opening scene. The work item is in Verification. A finding has surfaced that calls its readiness into question. Common practice is to move the work item back to Development and call this a backflow.

There is no backflow. The work item does not move.

Consider what is actually happening. The item entered the Verification state because the policy governing the previous state’s exit was satisfied: the development work met the criteria for advancing out of that state, which is necessarily not the same as “the item is verified to be fit for release.” That second condition is precisely what the Verification state exists to establish. The item is now in Verification, and the work of Verification is in progress. That work is a co-production: it sometimes involves the people who specialise in testing, sometimes the people who specialise in implementation, sometimes both, sometimes others. The actions vary. The state does not. The item remains in Verification until the policy governing Verification’s exit is satisfied, which is when Verification has produced the outcome it is responsible for: a defensible claim that the item is fit to move on.

When teams move the work item “back” to Development, they are not modelling reality. They are modelling their own role assignments, projected onto a board that was never the right surface for that projection. The mental move runs roughly: “a developer needs to do something, therefore the item is in Development, therefore the work item belongs in the Development region of the board.” Each step in this chain is wrong. The item is in Verification because the Verification work is not complete. A developer doing something during Verification is not unusual; it is the ordinary case, because verifying non-trivial work routinely requires the people who built it. We do not move the item back to Refinement when QA has a question for the Product Owner. We do not move it back to Discovery when a developer needs to clarify intent. We accept, in those cases, that the item is in its current state and that the work of that state requires participation across the team. We should accept it for Verification too.

The reason we don’t, I think, has to do with how the activities behind these states actually work. “Developing” is a single state on the board because the activities inside it — designing, coding, refactoring, integrating, reviewing, debugging — do not decompose into a meaningful linear sequence of sub-states. They interleave. The same is true of “QA”: planning, executing, investigating, validating, regression-checking, all of these interleave rather than queue. Each activity-cluster stays a single coarse state on the board because no finer decomposition holds up. Other activity-clusters work differently. Forming a hypothesis, validating it, splitting it into deliverable units, specifying acceptance criteria: these are distinguishable activities that can meaningfully sit in sequence, because each produces what the next needs. Where activities decompose, finer states on the board are available; where they don’t, they aren’t. And once an activity-cluster is a single coarse state, it becomes natural for a single role to inhabit it. One role, one state. Developers develop, in Development. QA engineers do QA, in QA. The collapse is not a mistake anyone made; it is what happens when an undecomposable activity meets a board that prefers clean states. And from that arrangement, all the rest follows.

What follows for how to design a board

If a board models the state space of work items, then the design rules are not aesthetic choices. They are consequences.

States are named for the work item, not the activity. A state is a condition the work item is in. “Development” is not a state; it is what some people do for a living. “Build in progress” is a state, awkward as it sounds. “Ready for verification” is a state. “In verification” is a state. “Awaiting deployment” is a state. The grammatical hint is that states attach naturally to the item (“the item is in X”), whereas activities attach naturally to people (“a person is doing X”). When the label only completes the sentence about the person, the label is misnamed.

I am aware this is a battle that gets lost more often than won. Teams resist long labels, and they are not always wrong to. But the principle survives even where the labels compromise: the question to ask of every state on the board is whether its name describes the item or describes the worker. Labels that describe the worker are labels inviting the confusion this essay is about.

Roles do not appear on the board. Not as states, not as swimlanes, not as avatars permanently associated with regions. The team collaborates to produce value. People specialise, of course they specialise, but specialisation is a property of how the team chooses to deploy its capacity, not a property of the work item’s lifecycle. Worse, the boundaries that a role-structured board appears to depict are partly created by the depiction itself. A team handed a board that distinguishes “developer work” from “tester work” does not encounter a pre-existing division and visualise it; it encounters a visualisation and learns the division from it. The board is not neutral evidence of how the work is structured. It is one of the inputs shaping how the work comes to be structured, and the structure it teaches is one the team will then have to undo. The moment the board distinguishes roles structurally, it begins teaching everyone who looks at it that “this is the developer’s part and that is the tester’s part.” The instruction is wrong, and the wrongness compounds: it produces the identity-fusion that makes the backflow argument feel personal, the local optimisation that makes hand-offs adversarial, and the resistance to whole-team quality work that practitioners then have to overcome through culture work that should never have been necessary.

This is the design choice that costs the most to make and the most to defend, because it cuts against intuitions that organisations have been reinforcing for decades. But it is the design choice that most directly serves the system the board is meant to make visible.

Policies govern transitions, not occupancy. What permits an item to leave a state is a question with an answer. What is happening inside a state is, from the board’s point of view, none of the board’s business. The board cares about the boundary, not the interior. A policy that says “items leave Verification when the defined verification criteria are met” is doing the board’s work. A policy that says “items in Verification must be actively worked on by a tester at all times” is doing something else: it is attempting to regulate the action space through a model that does not represent the action space. That regulation may be a useful thing for the team to do, but it does not belong in the board’s policy set, and putting it there muddles the model.

State transitions are forward, or they are aborts. This is the formal consequence of treating the board as a state space, and it is the one that resolves the backflow argument cleanly. An item leaves a state by either advancing to the next legitimate state, or by being removed from the active flow altogether (cancelled, archived, returned to the backlog under a new identity). It does not return to a previous state, because previous states no longer exist for this item: they were satisfied, the item moved on, and what would be gained by re-entering them. If a finding emerges in Verification, the finding is information produced in the Verification state, and the item remains in Verification until that information has been acted on. The action might involve writing more code. The action does not change the state.

This sounds like a small linguistic adjustment, and it is. But the linguistic adjustment is doing real conceptual work. Teams that adopt it find that arguments about “whose fault the backflow was” simply have no place to land, because the premise of the argument has been removed. The work is in Verification. The team is working on it. There is no backflow to assign.¹

Where this argument lives, and where it does not

The argument so far is formal. It rests on a distinction that workflow modelling has been making explicit for decades, in territory rigorous enough that competing formalisms (Petri nets, statecharts, workflow nets) agree on the foundational move. The argument is robust against counter-claims of the “but in practice” variety, because the formalism is what makes the practice coherent in the first place. A team that operates under the state-space framing finds that practice questions resolve more readily, because the model gives them a place to stand.

What the argument is not robust against is identity. A practitioner who has spent fifteen years describing themselves as a developer, in an industry that has spent thirty years calling its boards “development boards,” does not experience “the item is in Verification” as a clean re-description. They experience it as a small loss: of legibility, of authorship, of the region of the board they had come to think of as theirs. That loss is real, and no amount of formal argument will pre-empt it. The argument in this essay is a design argument, addressed to people designing boards. It is not, by itself, a cultural intervention.

I think the design argument and the cultural intervention are usually run together, and that this is a mistake. The design argument is settleable: there is a right way to model a state space, and the boards we see in most organisations get it wrong in describable ways. The cultural intervention is harder and slower and lives in a different register: in how teams talk about their work, in what gets celebrated and what gets quietly tolerated, in whether quality is treated as a shared production or an audit imposed at the end. A well-designed board makes the cultural intervention easier, by giving it a model to align with. It does not perform the intervention. The intervention is its own work.

But the design argument is the foundation, and if the foundation is wrong, the intervention has nothing to stand on. A board that codifies “my step” into its very structure is not neutral with respect to the culture it sits inside. It is teaching the culture, every day, that the work is a relay and the runner with the baton is the one responsible for what happens next. The board is doing the wrong teaching, and the team is then asked to overcome the teaching through culture work. This is harder than redesigning the board.

A closing note

The state-space framing is not a new idea. It has been available, in various forms, for as long as software has been formally modelled at all. What is new, if anything, is the suggestion that it applies to the boards on the wall as much as to the diagrams in the textbook: that the same distinction between state and action that disciplines a formal workflow model should discipline the artefact a team uses to coordinate its actual work.

The board is a model. Like all models, it represents some things and not others. What it represents is the state space of the work. What it does not represent, and should not be made to represent, is the action space of the people. Confusing the two produces backflows that are not backflows, arguments that are not really about the practice, and identities that fuse to a region of the board and then defend that region against the system they were meant to serve.

The fix is not technique. It is precision about what the artefact is for.

¹ The state-space framing also keeps flow metrics conceptually tidy. Once items only ever advance or leave the flow, questions like “what counts as the cycle time when an item appears to re-enter a state” simply don’t arise. Mature tooling handles these cases in practice; teams rarely notice. But the model and the measurement agree, which is one less thing to think about.

The Board Is a State Space was originally published in Agile Insider on Medium, where people are continuing the conversation by highlighting and responding to this story.

When You Become The Team’s Information Hub

Whoever you are, being a team’s information hub is toxic to their self-organization, and it makes you replaceable at any time. A few years ago, I joined a gaming company as a project manager, and I found some strange situations when it came to collaboration among teams.

In the beginning, I tried to understand how they handled requirements from users, and found there was only a ticket management system filled with lots of disorganized tickets. The team picked up tickets from it and started working on them, … no formal meetings, no communication, no flow, and everything was messy.

As a result, I became the only person who prioritized tickets, organized meetings, communicated changes to requirements, and passed requests among teams, which made me unable to work on more valuable things like product experience, effective working models, sustainable delivery, etc.

Well, I was like a proxy.

Make the Workflow Visible

For a while, I came to understand that the model didn’t work for me. It really sucked that I, as a project manager, couldn’t work on important things but had to handle routine tasks. So I decided to make a change.

I started observing the whole process of how they handled requests: receiving requests, analyzing requests, creating tickets, organizing tasks, collaborating, transmitting tasks, testing, deploying to production environments, and closing tickets. I took some time to investigate how things worked from a few aspects, such as request flow, what they did at different stages, and how they communicated with each other.

From the gathered data, I put everything together into a sequence diagram, as below, to show how different roles worked together, how we passed requests between teams, handled details, and finally delivered results, from a systematic perspective.

The more details I learned, the more opportunities I found to divide the workflow into clear stages, which were presented in columns on the Jira board, as below. As you see, each column represents a specific process stage for handling a request. In this way, we were able to understand how requests flowed through the workflow and were passed between people, together with the additional details shown in the sequence diagram.

In order to confirm my investigation with the team, I held a meeting, showed them my data and the diagrams above, to seek improvements based on their perspectives. After that, I set up the corresponding columns on the Jira board and documented the basic policies to tell them how requests should flow through the system based on the stages of work. These became the initial version of our Kanban board.

Fortunately, the team bought into it; the messy situations began to change.

How Transparency Enables Self-Organization?

There were three primary changes as the workflow was streamlined.

Firstly, the endless relay of information was significantly reduced thanks to the clear workflow, which I had initially clarified and communicated to others myself. I jumped out of the swamp of information forwarding and was able to focus on more important parts of the projects.

Besides that, potential impediments became easier to identify, and thus the team could react to them sooner. For example, we could spot warning signs when there were too many requests piling up in some columns, which prompted us to jump in and adapt the work to our objectives.

Even further, the team became more proactive in identifying problems not only through the Kanban board but also in day-to-day collaboration. For example, we were going to deliver a bonus distribution feature by Friday, but one team member was still stuck on the data aggregation task, which had a higher priority than the task we had been focusing on. He raised the issue in the meeting, and I had enough time to acquire a buffer with the customer. This would have been unbelievable if I had still insisted on the previous working model.

It was almost like magic when I implemented the value of transparency through visualization. It somewhat enabled self-organization, even though I didn’t push them hard. I couldn’t help but wonder whether there was some underlying logic behind the visualization practice, because the same scenario had occurred in another company but produced the opposite effect …

Kanban Board Isn’t Enough

Transparency is just a prerequisite for self-organization, while ownership and accountability are the keys behind it. I concluded this after working with another team in a similar situation. Let me tell you a story.

A few years ago, I joined a cryptocurrency exchange as a Technical Project Manager, and I was responsible for cross-functional collaboration between tech, design, and product teams. At that time, I put effort into coaching them on how to adopt Agile practices and designing a common process to visualize how work flowed. I thought everything would go as planned, but as time went by, I came to understand that something was wrong.

I found that the developers were always waiting for full specifications before working on tickets, which forced me to do lots of paper work and delayed delivery. It was clear that the situation had been this way for a long time. And the manager was used to micromanaging tasks instead of encouraging members to organize their work, which made them more passive.

I spent time thinking about what happened beneath the system. I designed the process, coached them on the practices, and documented everything, but received almost no support from the manager. The team continued working as before, and things got even worse as I tried to push harder. I once blamed myself for failing to empower them to self-organize. However, I seem to have done everything I could do right at the moment.

I came to realize that there was some deeper logic behind Agile practices.

Firstly, building transparency is just a prerequisite for self-organization; it doesn’t guarantee that a team will immediately change if its members are not ready to take responsibility for their work.

Aside from that, these people needed empowerment from their manager; it was a pity that I didn’t see that support, but instead saw endless judgment.

Finally, ownership is necessary for a high-performing team. If your team members get used to being pushed to work, it is definitely a waste of time trying to change the process alone.

Design an Environment That Enables the Team

To summarize my experience, there are a few actions you could take to cultivate a self-organizing environment, especially if you’re a manager.

First of all, hiring people who take accountability is the first step to shaping the culture of self-organization. Most people ignore this subtle but important factor, such that they adopt great practices but get less effect. Great practices work best with people who take ownership.

On top of that, visualizing the workflow by collaborating with your team makes the flow of work, policies, and statuses transparent to everyone, and eliminates the necessity of relying on the project manager to convey information, which further enables the team to organize their work.

Lastly, if you are a team manager, empower your team by letting them organize their work and providing immediate feedback for improvement. Micromanaging only tells them that you care about your KPI, not theirs.

Any ideas? Comment below.

Stop Being the Team’s Information Hub: Build Transparency to Enable Self-Organization was originally published in Agile Insider on Medium, where people are continuing the conversation by highlighting and responding to this story.

Most teams inspect churn at the exit: the save desk, the dunning email, the win-back offer. The defects were made upstream.

Amazon had a name for its Prime cancellation process: “Iliad,” after the Greek epic about a ten-year siege. According to the FTC, customers had to confirm they wanted to leave on three separate pages. In September 2025, Amazon agreed to pay $2.5 billion to settle the case, including a $1 billion civil penalty. It admitted no wrongdoing.

It’s easy to read that as a story about dark patterns. It’s also a story about where companies believe churn happens. “Iliad” was built on the idea that the cancel page is where you fight for a customer.

By the time someone opens that page, their reasons have usually been piling up for a while. The cancel button is just where they finally say it out loud. Yet most companies still organize retention around that button: a save desk, a discount ladder, a win-back email. It’s a factory that only inspects its products at the loading dock.

Churn has a supply chain. Most teams only watch the end of it.

Three terms carry this piece

• Break: a promise the company made and didn’t keep. A failed setup, a charge nobody explained, a second visit for the same problem, a ticket left unanswered.
• Lifecycle event: a change in the customer’s circumstances, like a move, a tighter budget or an expired card. Nothing broke, but the response still matters.
• Uplift: the difference an intervention makes for a specific customer, compared with doing nothing at all.

Defects travel

Manufacturing learned this the hard way. W. Edwards Deming’s third rule for managers was blunt: “Cease dependence on inspection to achieve quality.” The rest of the rule says to build quality into the product in the first place. On a production line, a defect starts at one station, travels through the next, looks like a different problem to each team that touches it, and reaches final inspection too late to stop the next one.

Churn travels the same way. Take Maya, who signs up for home internet. Her installation takes two tries. Her promotional price ends and the bill jumps without warning. Her connection drops every evening, and a technician comes out twice for the same problem. Her ticket about the bill sits for a week. Support sees a ticket. Billing sees a dispute. Field service sees a repeat visit. Nobody sees one customer having one bad month.

That’s the supply chain: retention teams own the exit, while the causes travel through handoffs nobody owns end to end. When Maya finally calls to cancel, the save desk is meeting her for the first time.

And the cancel button isn’t the only way out.

Two exits and a warning light

Customers leave through two exits, each watched by a different team with a different number. A third signal shows up before either one, and often nobody watches it at all.

The failed payment is the exit most teams forget is part of the product. Stripe says a quarter of lapsed subscriptions are purely due to payment failures: expired cards, insufficient funds, a bank that needs new details. Many of those customers never decided to leave, though some had already drifted away and didn’t bother fixing the card. An expired card is a lifecycle event. It becomes a break when the product answers it with a stern email and a locked account.

The quiet fade isn’t churn yet, so it shows up on nobody’s churn report. But usage can end months before the subscription does. In a well-known study of U.S. gyms, members on monthly contracts who eventually cancelled kept paying for 2.31 months on average after their last visit. That’s revenue, but it isn’t loyalty. Netflix went looking for it: in 2020 it began asking long-inactive members whether they wanted to keep paying, and cancelling if they didn’t answer.

Paying without using is the clearest sign of trapped retention: customers who stay because leaving is hard or because they forgot. A retention curve counts them exactly like customers who stay because the product is worth it, so I’d split it. Active retention counts only customers still getting what the product is for, whether that’s watching, visiting or a connection that stays up.

That’s why the regulation matters. California now requires companies to let customers cancel the way they signed up, with a prominent cancel button or link online, and to tell them they can finish cancelling before showing any save offer. A federal court struck down the FTC’s national click-to-cancel rule in July 2025 on procedural grounds, and the agency started over in March 2026. Enforcement never stopped, as Amazon learned. And when regulators from around the world reviewed 642 subscription sites and apps, nearly 76% used at least one dark pattern.

These laws remove friction, not forgetting, and none of them forces a better product. They do make trapping people expensive: a retention number propped up by a hard exit is now a legal risk on top of a misleading one.

The measurement trap

Retention teams lean on two tools, a save rate and a churn score, and both can look like they’re working while the problem grows. It’s the same pattern I found with AI hiring agents: grading the last signal you can see, not the outcome you care about.

Save rate. The save desk reports what share of cancelling customers it kept. By Goodhart’s law, when a measure becomes a target, it stops being a good measure: add a page, deepen the discount, transfer the call, and the save rate climbs. So I’d put regretted saves next to it: saved customers who cancel again within 90 days, or complain again about the problem that sent them to the exit. A move to a cheaper plan that fits isn’t a regret. That’s the offer working. But a save that ends in a second cancellation isn’t retention. It’s a delay.

Churn score. Many teams now predict who’s about to leave and send them an offer. A score is a prediction, not a diagnosis. It says who is likely to leave, not why, so the default response is a discount. And contact can backfire. Uplift modeling sorts customers by how they respond to an intervention: “persuadables” stay because you reached out, while “sleeping dogs” leave because you did. In one case described in California Management Review, a free switch to another contract produced a churn rate 2% higher among customers who got the offer than in a control group that didn’t.

A churn score answers “who’s at risk?” A break answers “what went wrong?” Neither tells you why. That takes a root-cause review. Use the score to decide where to look, and the break to decide what to repair.

The rival view deserves a hearing. Saving at the exit may simply be cheaper. A discount costs less this quarter than fixing an installation process, and some save offers genuinely work. A customer at the cancel button can’t be a sleeping dog, either. They’re already awake. If exit offers keep customers who stay active, for less than repairs cost, the save desk is money well spent. The test at the end is built to find out.

What I’d build: a churn andon cord

On a Toyota line, “each and every one is permitted to stop the production line” when they spot a quality problem. They pull a cord, a light shows where the problem is, and it gets fixed before it travels. Retention needs the same mechanism: a cord pulled at the break, not at the exit.

1. Keep a break ledger

Log every break against the customer it happened to, and give it an owning team: a failed setup, a second visit for the same problem, a charge nobody explained, a ticket past its promised response time. Maya’s month would have filled four lines before she ever called. Log lifecycle events too, but don’t assign them repairs. A move or a tighter budget needs the right offer or an easy exit. Most of this data already exists. It just lives in five different tools.

At HighRadius, I owned a feature on the collections side of an order-to-cash product. It tagged and prioritized collections teams’ shared inboxes, so disputes and escalations got answered first, and response time fell from about ten days to about three. That’s B2B, not consumer churn, and it doesn’t prove a retention effect. But it changed how I see collections. What looks like a payment problem can start as a service problem nobody answered.

2. Pull the cord when a break happens

Every break starts a repair clock, and the fix reaches the customer before they have to ask. A repair, not a coupon, because effort is what drives people away: in a study of more than 75,000 customers, 81% of those who had a hard time solving a problem planned to speak badly of the company, against 1% of those who didn’t. Break-to-repair time becomes the leading indicator. It should move weeks before churn does.

Repair has limits, though. A meta-analysis of the “service recovery paradox” found that a good recovery raised satisfaction but had no significant effect on repurchase intentions. Repair stops the bleeding; fewer breaks build loyalty. So every repeated break gets a root-cause review: keep asking why until you reach a process, then send the cause to the team that owns it.

3. Fix the two exits you own

Cancelling should take one click and finish immediately. One optional question and one matched offer can sit beside the button, never in front of it: a pause, a cheaper plan, a transfer for a move, a repair for a break. The answer goes into the ledger, so the exit becomes the last data point, not the first. For failed payments, warn before a card expires, retry at smarter times, keep service on through a grace period, and make updating a card a one-screen job.

What I’d ship first

The break ledger for your three most common breaks, a repair clock on each, and the one-click exit. None of it needs new data, just new owners.

Three objections

“If leaving gets easy, retention will drop.” It might, and that’s worth knowing. Better to learn how much of your retention was friction from your own test than from a regulator.

“This needs five teams to cooperate.” It needs one owner and five accountable teams. The retention PM owns the ledger. Each break belongs to the team whose process caused it, and its repair time sits on that team’s dashboard. That’s the point: someone finally owns the customer’s whole month, not just the exit.

“Reaching out to at-risk customers is the whole point.” Not when they’re sleeping dogs. The California Management Review authors found uplift modeling especially promising for auto-renewing contracts like telecom, streaming and gyms, where some customers renew if left alone but cancel when contacted. That’s trapped retention by another name. Leaving them out of campaigns is fine. Hiding the exit from them isn’t.

How I’d test it

Run it for two quarters at one subscription business big enough to split into three groups:

• Score arm: today’s playbook. Churn-score offers plus the save desk.
• Break arm: proactive repairs from the ledger, the one-click exit and the payment fixes.
• Holdout: normal service, including every repair a customer asks for, but no proactive offers or outreach, so you can measure uplift instead of guessing it.

Track regretted saves, active retention at 90 and 180 days, break-to-repair time, cost per retained customer (discounts and repairs included), complaints, chargebacks and win-backs.

Two limits. This tests the whole playbook, not which piece of it works, so if it wins, take it apart one piece at a time. And only customer-level moves can be randomized: proactive repairs, the exit, payment recovery. A root-cause fix to an installation process reaches every group, so judge those fixes before and after instead.

If the score arm keeps as many active customers for less money, the rival view wins. If the break arm keeps more active customers with fewer regretted saves, the cord earns its place. And if any group churns more when contacted than when left alone, you’ve found your sleeping dogs.

The bright line

My rule: fix the break, not the exit. A discount never stands in for a repair, and cancelling always takes one click.

Back to Maya. After the second technician visit for the same dropped connection, she calls to cancel. The save desk offers three months at half price. She takes it, the save rate goes up, and the connection keeps dropping.

With the cord, that second visit is the trigger. A senior technician finds the root cause (say, a faulty line at the street) and fixes it for everyone on that street, and Maya gets an apology that names what went wrong. If she still wants to leave, she leaves in one click. The repair was owed either way.

On a save desk report, the half-price Maya is a win. On a break ledger, she’s a defect still in the product.

Unwritten Rule #3: You can’t inspect retention into a product.

Next week: the PM problems that only show up when your product arrives in a box, or with a technician.

Sources

Law and cases

• Amazon’s $2.5 billion FTC settlement, via ABC11 (2025)
• Venable, California amends its auto-renewal law (2024)
• Fenwick, Eighth Circuit vacates the FTC’s click-to-cancel rule (2025)
• Kelley Drye, FTC relaunches negative option rulemaking (2026)
• FTC, ICPEN and GPEN review of dark patterns in subscription services (2024)

Research

• DellaVigna and Malmendier, Paying Not to Go to the Gym, American Economic Review (2006)
• Dixon, Freeman and Toman, Stop Trying to Delight Your Customers, Harvard Business Review (2010)
• de Matos, Henrique and Rossi, Service Recovery Paradox: A Meta-Analysis, Journal of Service Research (2007)
• Schoder and Rößler, To Treat or Not to Treat? Five lessons learned from using uplift modeling, California Management Review (2025)

Industry data

• Stripe, How we built it: Smart Retries (2024)
• Netflix on cancelling inactive accounts, via TechCrunch (2020)

Frameworks

• Deming’s 14 points, via IfM Cambridge
• Toyota UK, Andon in the Toyota Production System
• Goodhart’s law, via FORRT

Churn Has a Supply Chain was originally published in Agile Insider on Medium, where people are continuing the conversation by highlighting and responding to this story.

1999: “We need a website.”
2008: “We need an app.”
2012: “We need to move to the cloud.”
2017: “We need a blockchain strategy.”
2023: “We need a chatbot.”
2026: “We need AI in everything, and we need it yesterday.”

I’ve heard every one of those sentences across a client’s table.

Over two decades of delivering projects to clients around the world, each wave arrived with its own excitement, its own buzzwords, and its own learning curve.

A few weeks ago, I was sitting in a boardroom with a long-time enterprise client. We were reviewing the roadmap for a major digital overhaul that our team at Genetech Solutions had been preparing for months. Halfway through, the client looked across the table, smiled warmly, and asked the question every tech leader is hearing right now:

“Since your team is using AI tools now, shouldn’t this project take half the time and cost 40% less?”

I smiled back, but inside, I thought: And there it is

It was a fair question, and a familiar one. Every client has seen the headlines and the demos, and every client wants a share of the speed AI promises.

So What’s the Matter?

When AI changes the speed of the work, the business around it has to change too. The way we price projects, the tools we trust, the way our teams work together, and the relationship we build with clients all need a fresh look.

Those four areas are where I see the biggest gaps right now.

1. Affordability and the Changing Business Model

AI tools carry a real price tag, especially when you’re equipping an entire team. Licenses, usage-based API costs, and the time spent learning new workflows add up quickly. In fact, more than half of developers in Stack Overflow’s survey said platform costs shape which AI tools they use.

Meanwhile, customers have done the math in their heads. AI is doing the work now, so it should be faster and cheaper. Right?

That squeezes service companies from both sides. We invest more to deliver faster, while the traditional hourly billing model gets harder to defend. Imagine a feature that once took 40 hours now takes 15. Bill by the hour, and your team’s newfound speed shows up as a smaller invoice.

The answer isn’t necessarily to abandon hourly billing. It’s to rethink where it makes sense. Dedicated teams, ongoing support, and evolving projects may still justify time-based models. But when AI helps us deliver measurable outcomes faster, our pricing should reflect the value we’re creating, not simply the hours we’re spending.

The challenge is finding a model where clients benefit from greater efficiency without making innovation financially unsustainable for the companies delivering it.

Questions worth asking:

• Which parts of our work are now measurably faster with AI?
• Are we passing that efficiency to clients, keeping it, or sharing it?
• Can we price by outcome, milestone, or product instead of by the hour?
• Do our contracts account for AI tooling costs, or are we quietly absorbing them?
• How do we show clients the value of human judgment when they assume AI did everything?

2. The Pace of Change Is Exhausting

Our teams are adapting quickly, but honestly, the pace of AI evolution is exhausting!

One day it’s Claude Code. The next, it’s GLM from Z.ai, offering competitive coding capabilities at a fraction of the cost. By the time you’ve evaluated one tool, three more are knocking at your door!

Then came the ZCode controversy. In September 2026, developers found that Z.ai’s ZCode coding assistant had been uploading entire local code repositories to Alibaba Cloud servers before users had given consent, through a feature switched on by default. Z.ai apologized, disabled the feature, and open-sourced the tool, and the whole industry started asking questions about where its code goes.

And now European providers offer GLM through EU-hosted infrastructure with GDPR-focused data protection terms. Same model, very different privacy posture, depending entirely on how you access it.

So suddenly, choosing an AI tool is about trust, security, compliance, and where your data ends up, as much as capability or cost. Developers feel it too: 81% of those using AI agents reported concerns about security and data privacy.

We’re learning to be more deliberate about the AI tools we adopt. Capability and cost matter, but so do data privacy, security, and the implications for our clients’ intellectual property. We’re increasingly evaluating tools through that lens, asking harder questions about how data is handled, and where human oversight is essential. It’s an evolving process, just like the technology itself.

For me, staying ahead in AI isn’t about adopting every new tool. It’s about knowing which ones to trust, when to use them, and where to draw the line.

Questions to ask before your team adopts any AI coding tool:

• What leaves the developer’s machine, and does any of it leave by default?
• Where is that data processed and stored, and under which country’s laws?
• Is a data processing agreement available, and does the vendor train on your data?
• Can features like codebase indexing be switched off, and is that clearly documented?
• Who approves new AI tools in your organization, and how fast can they review one?

3. The Juniors Versus the Seasoned Developers

This one is particularly interesting to watch.

Fresh graduates and junior engineers are picking up AI tools incredibly fast. They experiment, learn, and produce work at a pace that once felt out of reach, which is exactly why junior developers remain essential to every modern team.

Junior Developers Are Not Obsolete; AI Just Shifted Their Job Description

Then you have your seasoned developers. They bring years of domain knowledge, architectural understanding, and experience building products that endure well beyond launch. They can be more set in their ways and slower to change how they’ve traditionally worked, and the data reflects that caution: experienced developers are the most skeptical of AI output, with 20% saying they highly distrust it.

And that’s where the push and pull begins. Speed versus experience. We need the speed and adaptability of our juniors, and equally, we need the judgment and experience of our seniors. Getting that balance right is a real management opportunity.

Our approach at Genetech has been simple: pair them directly. We match AI-native junior engineers with senior architects. Juniors use AI to generate rapid drafts and prototypes, while seniors review the architecture and ensure long-term stability. Speed meets wisdom, and both grow together.

What helps teams strike the balance:

• Pair juniors and seniors on AI-assisted work, so speed and judgment meet in the same review.
• Treat code review as the place where experience shapes AI output.
• Give senior engineers protected time to experiment with AI tools, away from delivery pressure.
• Reward sound architectural decisions alongside output volume.

4. Customers Are Cautious, and Rightly So

Many clients have thoughtful questions about AI being used on their projects. Their concerns about intellectual property, data protection, and confidentiality are important. Then there’s the creative side. Some customers want unique designs, animations, and experiences, and they want to know their product will feel original and distinctly theirs.

So clients want delivery that’s faster and more affordable, while also being secure, original, high-quality, and clearly their own. That’s a fair ask, and it calls for AI adoption that’s thoughtful and vigilant.

We handle this with total transparency. We walk our clients through our exact workflow, showing them where AI handles baseline scaffolding and where human strategists and designers lead the craft. When our clients see that human judgment governs the final output, uncertainty turns into genuine trust.

Conversations to have with every client before the project starts:

• Where AI will be used on the project, and where human work takes the lead.
• How their code, data, and documents are handled, and which tools are approved.
• Who owns the final output, and how originality is reviewed.
• How human craft and creative direction shape the parts of the work that need to feel unique.

What I’ve Learned

Looking closely at these four challenges, the pattern is clear. Technology is the easy part.

The real work lies in strategy, pricing, people, and trust.

The businesses and professionals hesitating right now have plenty of talent. What they need is direction: what to automate, what to buy, what to build, and where AI earns its place.

The good news is that direction is fixable. It starts with an honest look at the problem, before the tools.

Back in that boardroom, my answer came with its own smile. AI gives us remarkable speed, and we pass that gain to our clients through faster delivery. The judgment, security, and care of a team that builds products to last remain the heart of what they receive. That conversation reminded me why pricing discussions can no longer begin and end with hours. AI may change how quickly we deliver, but what clients ultimately pay for is the value, reliability, and quality of the result. So we agreed to measure the project by the outcome it delivers instead of the hours it takes.

A conversation that began with cost ended with value.

Challenges and evolving waves have always been a part of this industry. What businesses need to navigate them well is a critical evaluation of the challenge, a clear understanding of the pros and cons, judgment shaped by lived experience, and proper guidance. Whether you are reworking your pricing model, setting up data governance, or deciding where AI belongs in your roadmap, book a 1:1 AI Strategy and Business Consultation session and leave with a clear direction.

Bring your biggest AI question, and let’s work through it together!

The AI Gold Rush Is Breaking Business Models was originally published in Agile Insider on Medium, where people are continuing the conversation by highlighting and responding to this story.

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.