Designing with Constraints, Not Checklists

I still remember a refinement session that ran exactly to plan. Stories had acceptance criteria. Points were agreed. Definition of done was pasted at the top of the board. Everyone nodded. Walking out, I could not have told you what the product was trying to do that cycle, or what we would change if the first week went badly.

The board looked great. The thinking behind it was thin. I have seen that meeting many times since, in different companies, with different tools. Process theatre is what I call it when the rituals of good practice run with total compliance and almost no judgement. Every box ticked. Nothing decided. The harder question – whether any of it is the right work – goes quietly unattended.

From the outside it looks like rigour. That is why it is easy to miss.

Checklists and the wrong question

Checklists are the right tool for some work. Pre-flight checks. Deployment runbooks. Security close-out steps. When the task is known and the cost of forgetting a step is high, you do not want judgement there. You want the steps, every time, in order.

Product work is not mostly that kind of work. Deciding what to build, reading what a customer actually needs, holding a team through a hard trade-off: you act, you watch, and the lesson often only becomes clear afterwards. A checklist cannot carry that. It can only confirm the ceremony took place.

So the checklist asks: did we do the steps? Refinement, done. Estimates, done. Stand-up, retro, done. Compliance is easy to measure and reassuring on a dashboard (or in a performance review). A team can pass every check and still ship the wrong thing with great discipline.

When Agile spread, a lot of teams copied the visible practices without the learning loop that made them valuable. They kept the ceremonies and artefacts. The reason for them did not travel. Process theatre is that move in slower motion: practice reduced to a recipe. A recipe cannot tell you when the dish is wrong.

A better question

A constraint asks something different. Not did we do the steps, but given this limit, what is the best thing we can do?

A checklist adds items you must include. A good constraint removes options you would otherwise waste time on, and forces the judgement the checklist was trying to avoid. It does not tell you what to build. It shapes the space in which you decide.

Fixed time and variable scope is the example most teams recognise once they hear it in plain language. Fix the time – three weeks, a cycle, whatever is honestly available – and let scope flex. The conversation stops being "when will this be done" and becomes "what is the most valuable version we can ship inside the limit". The limit has to be real. The judgement lives inside it.

A short brief that names what is in, what is explicitly out, and where the known traps are. Not a spec that pre-answers every question. A frame that stops the team wandering into the whole domain.

"We decide by Thursday" is a constraint. It does not tell you what to decide. It tells the team when arguing has to resolve into a choice, which changes how the week is spent.

One sentence on what the product is for, so smaller decisions have something to be measured against. Not seven qualities of good product management. One bet, in words a customer would recognise.

What these have in common: they stay few, they stay real, and they push toward a decision rather than toward completeness. Checklists grow because adding an item feels safe. Constraints have to stay small to do their job. The moment your constraints become a checklist of their own, you are back in the theatre.

What you hear in the room

You can usually tell the difference by listening.

Under process theatre, the conversation is about the artefacts. Are the stories ready? Is the board up to date? Did we groom the backlog? Did everyone fill in their part? The work becomes the management of its own paperwork. Being busy on the paperwork feels like progress because it is visible. Learning does neither, so it loses.

Under design with constraints, the conversation is about the decision. What are we actually trying to do here? What does the time we have force us to leave out? What is the narrowest safe path engineering can see? What did the last customer conversation change? The rituals still happen. They are in service of the decision, not a substitute for it.

I have watched two teams use the same tools – same planning meet, same board – and get opposite results. The ceremony was not the variable. Whether the ceremony produced judgement or just evidence that the ceremony occurred was.

Try one piece of work

Pick something your team is about to start, or has been circling without progress. Do not reform the whole process. Reshape this one thing and watch what changes.

Write the one thing it is for, in a sentence. "A new user can send their first invoice without asking us for help." If it takes a paragraph, it is still too vague to steer by.

Fix the time, not the scope. Say out loud how much attention this is worth right now – two weeks, a cycle, whatever fits its real importance – and treat that as fixed. The interesting conversation is what fits inside it, not how to extend it.

Write what is out, not just what is in. Two or three lines on what you are deliberately not doing, and the traps you already know about. The out list saves more time than the in list. It kills scope creep before it starts.

Name the decision date and who makes the call if the room splits. "We decide by Thursday, and I decide if we are stuck." Ambiguity about when and who is where most drift hides.

At the end, ask what you learned, not only what you finished. Finishing is a checklist question. What this taught us about the customer, the delivery, or the bet is the one that compounds.

If that is too much at once, start with the out list alone. It is the cheapest constraint I know, and often the most revealing.

Where this goes wrong

I have turned constraints into a new checklist. Mandatory fields. A template with its own definition of done. Different scenery. Same theatre.

I have seen fixed time used to cut quality instead of scope. Variable scope means shipping less, done well – not the same ambition, done badly. If the constraint squeezes craft instead of ambition, the team learns to distrust it.

"The CEO wants it by Friday" is pressure, not design. A real constraint is one the team can plan inside honestly because everyone agrees it is genuine. Fake constraints get gamed. Real ones get respected.

And I have kept ceremonies because removing them felt risky, even after they stopped producing decisions. Once a quarter I try to ask of each recurring ritual: what decision does this actually help us make? If the honest answer is none, that is not practice. That is theatre with a calendar invite.

What I do when the work feels well-run but aimless

I do not add a step. I take one away, and put a real limit in its place.

The question I ask afterward is not whether we followed the process. It is whether the team can now say, in one sentence, what this piece of work is for and what we are not doing. On a good week that is the whole win.