The Requirement Nobody Could Justify

We shipped role-based team permissions on a product one person uses alone. Every reviewer signed off.

We shipped role-based team permissions on a product one person uses alone.

It was a small web utility. You install it, and it lets a site visitor change how the page looks — display settings, appearance controls, that kind of thing. Useful, unglamorous, and used by exactly one person at a time on their own browser.

The permissions layer made it through requirements, through sign-off, through development, through QA. It surfaced at product-market fit validation, which is the last gate before launch, and it was obvious within about a minute that it had no business being there. We pulled it. That cost a week of development and QA time, plus a repeat of the validation cycle.

What I want to talk about isn't the week. It's how a feature that made no sense to anyone got approved by everyone.

Nobody was careless

This is the part that took me a while to accept.

The requirement came from competitive research. A business analyst went through the competing products, captured what they did, and wrote it up.

That research wasn't the whole PRD, and it wasn't meant to be. It was one input among several. We had our own product research, our own ideation sessions, our own view of who this was for. All of it was aggregated and analysed into a single specification, which is exactly how a PRD is supposed to be built — several sources reconciled into one document the team can develop against.

The permissions layer went in through the competitive strand and sat alongside everything else, indistinguishable from requirements that had arrived by a different route entirely.

That's not sloppy work. Competitive research is a legitimate input, and capturing what competitors do is exactly what the task asks for. The PRD that came out of it was accurate. Every line in it corresponded to a real feature in a real shipping product.

Sign-off went the same way. The reviewers checked the PRD against the research, found that everything traced back to something observed, and approved it. They weren't rubber-stamping. They were doing the thing sign-off actually does.

And that's the problem. Sign-off verifies that a document is complete and internally consistent. It's very good at catching a missing section, a contradiction, an acceptance criterion that doesn't match its user story. It's structurally incapable of catching a requirement that is well-formed, well-sourced, traceable, and pointless.

Provenance isn't justification

Every requirement in that PRD had provenance. We could say where it came from. A competitor does this.

None of them had justification. Nobody had written down why we needed it.

Those feel like the same thing when you're reading a document at speed, and they're not. Provenance tells you the requirement is real — somebody didn't invent it, it exists in the world. Justification tells you it belongs in your product, for your users, given what your product is for.

A requirement with provenance and no justification passes every review you can throw at it. It's traceable. It's sourced. It survives challenge, because the answer to "where did this come from" is immediate and satisfying, and almost nobody asks the second question.

The second question is: why does that competitor have this, and does that reason apply to us?

For the permissions layer, the honest answer was that the competitor sold to teams who administered settings centrally. We didn't. Same feature, entirely different product context. Theirs was configured by one person on behalf of many. Ours quietly adjusted a setting for one person on their own browser.

That answer was available at requirements time. It took thirty seconds to reach once someone actually asked. Nobody asked, because the requirement didn't look like it needed asking about.

Where competitive research stops being enough

Competitive research earns its place. It's how you understand the value proposition you're competing against, where the category has settled, and what buyers already expect to exist. For product analysis, it's one of the more reliable inputs available — you're looking at decisions that survived contact with a real market.

The problem isn't the research. It's the handoff into a PRD.

Requirements arrive from a lot of places. Stakeholder interviews, support tickets, sales calls, analytics, regulation. Most of those come with a why already attached, even a weak one. A stakeholder wants something because of a problem they described. A support ticket exists because a user hit a wall.

Competitive research is different, and not by anyone's fault. You can see what a competitor built. You can't see why. You don't have their user research, their support volume, their strategy meeting, or the constraint that made it necessary. You have the output and nothing else.

So when a competitor feature moves from a research doc into a PRD, the reasoning doesn't travel with it. What crosses over is the conclusion. That's fine at the analysis stage, where you're mapping a landscape. It stops being fine at the specification stage, where every line is about to be built.

And the aggregation is what hides it. Once competitive findings, internal research, and ideation output are reconciled into one document, every line looks the same. A requirement that came from a user interview and a requirement that came from a competitor's feature list sit in the same table, in the same format, with the same weight. The PRD is doing its job — a single source of truth is the point — but the effect is that provenance stops being visible at exactly the moment it starts to matter.

Which is why market-fit validation is where these surface, and why that's the hardest gate for any product team to pass. Validation is the first point in the process that asks whether the thing is right rather than whether it was built correctly. Everything before it — review, sign-off, QA — is checking internal consistency against a PRD that already contains the mistake.

The column that isn't there

Most requirement documents I've inherited have a what and an owner. Sometimes a priority. Occasionally an acceptance criterion, if the team is disciplined.

Almost none have a why.

Not a strategic why — not "aligns with our Q3 objective," which is the kind of thing people write to fill a box. A specific one. What problem does this solve, for whom, and how did we learn it was a problem.

When that column exists, the permissions layer never survives contact with it. There's nothing to write. Somebody has to type the words "because a competitor has one," look at it sitting there in the PRD, and notice.

That's most of the mechanism. Not a process, not a gate, not another meeting. Just a field that has to be filled in with a real sentence, where a weak answer is visible as a weak answer.

Three questions that would have caught it

When competitive research feeds a PRD, these go on every line:

Why does the competitor have this? If you don't know, say you don't know. An unknown why is a flag, not a blocker — plenty of copied features turn out fine. But it should be visible that the reasoning is missing rather than assumed.

Does that reason hold for our product? This is where the permissions layer died, months later than it needed to. Their buyers administered settings for a team. Ours changed a setting for themselves. Once the question is on the page, the answer isn't difficult.

What breaks if we don't build it? For a genuine parity requirement, there's a real answer — we lose deals, users churn to the competitor, the product looks unfinished in a category where that feature is expected. For the permissions layer, nothing broke. Nothing was ever going to break.

None of these need a new document or a new ceremony. They need one more column in the PRD and someone willing to leave it visibly empty when it's empty.

What it actually cost

A week of build and QA, and a repeated validation cycle. In the scheme of things, small. We caught it before launch, which is the outcome the validation gate exists to produce, so the process worked exactly as designed.

But it worked at the last possible moment, on a requirement that could have been killed in thirty seconds during requirements capture. Every review stage between those two points looked at that permissions layer and had nothing to say about it, because none of them were designed to ask the only question that mattered.

The thing I check for now isn't whether requirements are traceable. Traceable is easy, and it's what most reviews already measure. I check whether anyone can explain, in a sentence, why each one is there.

The ones where the answer is "a competitor has it" get a second look. Sometimes that's the right reason. It's just never a sufficient one.

Also published on Medium. If you want pieces like this as they publish, subscribe on Substack.