Three Products in One Requirement

Filed by: D.B. Trench

Field line: Sign-off is only useful if everyone signed the same animal.

The requirement had three signatures on it.

That gave it confidence.

It should not have.

The sentence looked simple enough:

The dashboard shall provide regional performance visibility for leadership decision-making.

Business had signed it. Finance had signed it. The executive reporting lead had signed it. The requirements tracker showed approved, and the project plan treated approved as if it meant understood.

Then the prototype appeared.

Business expected daily exception management by region. Finance expected monthly trend comparison with reconciliation notes. Executive reporting expected a one-page narrative summary suitable for committee decks, which is less a dashboard than a political document wearing charts.

Three signatures. Three products.

The BA saw it first.

Not because she was psychic. Because she asked each stakeholder what they expected to do with the dashboard after launch.

The answers did not even pretend to be cousins.

In the old rhythm of the project, this would have become a delivery problem. The prototype would be called wrong. The vendor would be asked why it missed the intent. The PM would arrange a meeting called alignment, which usually means everyone brings their original opinion and leaves with a softer calendar invite.

The BA did something better.

She stopped asking whether people were aligned.

Alignment is too easy to agree with. People will say yes to alignment while imagining different screens, different filters, different decisions, and different Monday mornings.

She asked for the working output.

When this is live, what exactly do you need to see, decide, or do because of this dashboard?

That question changed the meeting.

Business needed a daily exception queue by region, with owner and aging. Finance needed month-end comparison and reconciliation notes. Executive reporting needed a one-page summary with trend language and risk commentary.

Those were not three preferences inside one product.

They were three products competing for one sentence.

The sponsor did not love that discovery. Nobody enjoys learning that the thing already approved has only been approved in three imaginary versions.

The requirement was reopened.

Not because process demanded drama. Because delivery had finally found the split before UAT inherited it.

The revised record said:

Original dashboard requirement contained three distinct expected outputs: operational exception management, finance trend reconciliation, and executive narrative reporting. These will be separated into three requirements with owners, acceptance criteria, release priority, and source-data assumptions.

That sentence did not make the project faster that week.

It made the project less fake.

The BA did not get applause for this. She got a longer requirements log, a cranky sponsor, and three difficult follow-up meetings.

That is often what prevention looks like from the inside.

No ribbon.

Less fire.

---

Approval split test: Use this when a signed requirement uses a broad noun like dashboard, report, portal, integration, workflow, or visibility.

Ask approvers: “When this is live, what exactly do you need to see, decide, or do because of it?”

Watch for: Different outputs, different decision cycles, different audiences, or different evidence needs hiding under one label.

Record line: “Sign-off confirmed for [specific output], not the broader label [ambiguous noun].”

Field channel: Get The Dispatch — weekly field reports for PMs managing the work beneath the official update.