Marisol had been on the platform team for six weeks when she inherited a stalled project: a new incident-response setup that was supposed to be live by the end of the quarter. When she opened the requirements document, the problem was visible within a minute. It had forty-one lines, and every single one was marked “critical.” This story is about the diagnosis, and about why the must-have requirements for any operations project need to be a short list, written first, before anyone argues about the rest.

The symptom: a project that never quite starts

The team’s symptoms were familiar. Two engineers had built private spreadsheets scoring candidate tools, and the scores disagreed because each spreadsheet weighted the same wishes differently. A pilot was proposed twice and cancelled twice, once because the tool could not import a legacy log format and once because the dashboards did not match a colour scheme someone liked.

Nobody was lazy. Everybody was careful. The trouble was that care had no shape: with forty-one critical items, a candidate setup could never pass, because it always failed at least one. The team read this as “we have not found the right product yet.” Marisol read it differently. In her view, the product was not the bottleneck at all. The bottleneck was a list that could not say no.

The diagnosis: preferences wearing a must-have badge

She printed the list and sat with three coloured pens. Next to each line she wrote one question: “If this were missing on launch day, would we have to stop and roll back?” Where the answer was yes, she circled it. Where the answer was “we would grumble but carry on,” she underlined it. Where the answer was “somebody once mentioned it,” she crossed it out lightly in pencil.

The result surprised everyone. Of forty-one lines, seven were circled. Eleven were underlined. The rest were pencil-crossed, which is not the same as deleted: they were wishes, and wishes are fine. They just do not belong in the same column as the things that decide go or no-go.

That sorting produced a useful vocabulary. A must-have is a condition whose absence ends the project. A nice-to-have is anything you would enjoy but could live without, and its only job is to break ties between options that already meet every must-have. Once a team holds those two definitions firmly, most arguments shrink, because the question changes from “which option is best?” to “which options are even eligible?”

Writing the non-negotiables first

The order of writing matters more than the content. If you draft the full wish list and then try to mark the important ones, you will mark far too many, because every item looks reasonable once it is on paper. If you instead write the non-negotiables first, while the list is empty, each addition has to justify the space it takes.

Marisol’s circled seven were plain statements of fact rather than features. The new setup had to page the right person at night. It had to keep working if one data centre link failed. It had to keep a record of who acknowledged what. It had to fit inside the approved budget. It had to be understood by the two engineers who would run it. It had to avoid sending customer data to a region the company was not allowed to use. And it had to be switchable off without a ceremony if it misbehaved.

Notice what is absent: nothing about polished graphs, nothing about the number of integrations, nothing about machine-learning ranking. Those were all in the underlined or pencilled groups. They mattered to someone, and some of them would matter later, but none could stop a launch.

A quick test for any line on your list

• Can you describe the exact failure on day one if it is missing? If you cannot, it is a wish.
• Would a workaround exist that your team could live with for a month? If yes, it is a tie-breaker.
• Does it come from a rule, a contract or a real incident? If so, it is likely a must-have. If it comes from a conference talk, it is probably not.

The fix: a two-column decision and a short meeting

With the seven musts on one side of a page and everything else on the other, the team met for forty minutes. They did not debate the wishes. They only asked of each candidate: does it meet all seven? Four of the five candidates did, which was a relief, because the earlier process had eliminated all five.

Only then did the second column come out. The underlined items acted as a ranking: the candidate that covered most of them moved to the front. The pencilled wishes were read aloud as a courtesy and parked in a “later” note. Nobody felt ignored, because every wish still had a home, and nobody felt that a wish had been smuggled in as a requirement.

The pilot began the following Monday. It took two weeks, and the one thing that surfaced was a wish that had been wrongly pencilled out, which they promoted to the underlined group. That is the other healthy property of the two-column method: the lists are living things, and moving an item between them is a small, visible, discussable act, not a hidden loss.

Where outside material helps and where it does not

Marisol also noticed how often the stuck-list pattern shows up outside work. She had watched a relative try to arrange care abroad with no ranking at all, and the educational website BestCardiacHospitals, which is aimed at international patients and walks through how to compare care options, struck her as the same lesson in another setting. The site states that what it publishes is educational, not medical advice, and not for urgent situations, a useful reminder that tips on organising a choice never replace expert input on the substance.

The same restraint applies to operations work. A framework for ranking requirements helps you decide faster, but it cannot tell you what your systems need. That knowledge has to come from your own incidents, your own contracts and the people who will carry the pager. For a gentle introduction to bringing automation into a team, the walkthrough on adopting AIOps practices inside an IT team without chaos is a reasonable place to start, and a beginner-level piece on handling live technical faults supports the incident-related musts above.

Common ways the method goes wrong

Two failure modes appear often enough to name.

Must-have inflation. After a scare, the list quietly grows. A bad outage leads to three new “critical” lines, and within a year you are back at forty. The cure is a hard cap: if a must-have is added, an old one has to be re-argued. Seven is not magic, but a list you can recite from memory has an honest size.

Vague musts. “Must be reliable” cannot be checked. “Must keep delivering pages when one network path is down” can. Whenever a must-have cannot be tested in a pilot, rewrite it until it can.

What changed for the team

Three months later the team had retired a routine nobody missed and kept a living “later” list. Marisol’s favourite sign of progress was that the weekly platform meeting had lost a recurring twenty-minute argument. People still disagreed, but they disagreed inside a frame. A disagreement about a tie-breaker is cheap, because either answer is acceptable. A disagreement about a must-have is valuable, because it forces the group to look at a real risk.

Try it on your next stalled decision

You do not need a vendor evaluation to use this. Take any decision that has stalled, whether it is a rota change, a logging migration or a new ticket workflow, and run the same ten-minute exercise. Write the non-negotiables on a blank page before looking at any wish list. Keep the count low enough to say aloud. Test each one by imagining launch day without it. Then label everything else as a tie-breaker, rank it lightly, and let it serve only when two options are tied.

The list will feel almost embarrassingly short. That is the point. Keeping the musts few does not shrink what you hope to build, it simply lets the hopes ship in sequence. Marisol’s project went live five weeks after she picked up the pens, and the wishes arrived afterwards, one at a time, each as a small improvement to something that already worked.