Role Clarity and Testable Requirements: Written by Whoever Stood Closest
We were embedded in an organisational change programme at one of the biggest business units inside a global research and advisory practice: nine product and technology teams, hundreds of millions of dollars in yearly revenue, and an ambition to double it. The programme needed evidence under it, so we ran an assessment: twenty-five dimensions scored, and a qualitative pass that catches what scoring flattens.
The analysis started with the map.
Start with the map
Correlation, not causation: every edge is a measured statistical association (p<0.05) from this engagement, not an asserted cause. Edges below |r|=0.35 are omitted for legibility; the rest are drawn thicker and more opaque the stronger they are. The map stays focused on Product management roles: hover any dimension to preview its own connections against it, and use the strength slider to keep only its strongest links.
The map opens centred on role clarity in product management: whether people know who owns what. It is one of the most-discussed subjects in the study, twenty-one written mentions, and its strongest connection is the reason this page exists: not a people dimension at all, but testable requirements. Whether a requirement can be tested tracked whether anyone clearly owned it. The rest of this page is that one edge, unpacked.
What the numbers said
Hiding the story is a median of 7 out of 10: of sixty-one respondents, nineteen scored role clarity at 4 or below. This strip is close to two populations in one bar: people for whom the roles work, and a large group for whom they plainly don’t.
What the words said
The two dark blobs not lining up is the chart.
There are ten coded units on this dimension, six negative against two positive. Converted to the score axis, the writing clusters at 3, and the scores cluster at 7. And the words are unusually direct about what’s missing:
“There is no segregation of responsibilities. What is a product owner, their responsibilities, what ceremonies are they responsible for… There is no clear product owner role who is part of the Scrum team. Who runs the ceremonies.”
“People are wearing too many hats.”
“QA is not included in any Product Management processes.”
Those are three different vantage points describing the same condition: nobody could say where one role ended and the next began.
Where it lived
Nine teams, anonymised, best to worst. Thin rows render wider and flatter; less data looks uncertain, not falsely precise.
Medians across the nine teams reach from 8.5 at one end to 3 at the other, which is a wide spread on a single dimension. Role clarity wasn’t an organisational constant. Each team had negotiated its own answer to who-does-what, and some answers were working much better than others.
What role clarity turned out to be entangled with
The measured neighbourhood:
- Testable requirements (r = .75), the strongest pull
- The product roadmap and its prioritization (r = .67)
- Prioritization (r = .66)
Why would requirement testability track role clarity harder than anything else? Because of who was actually writing the requirements. The comments answer it from three independent directions:
“Requirements gathering: are they fleshed out, is it actionable, who creates them? At the moment, business sends giant monolithic documents, not easily digestible by IT.”
“Today, a scrum master writes the tickets in the backlog. He writes the functional acceptance criteria.”
“A lot of things trickle down to the dev team, such as: provide the requirement documents to some feature proposal.”
The business writes a tome, a scrum master writes the acceptance criteria, the dev team drafts its own specs. Requirements were written by whoever was standing closest, and when no role owns a requirement, no one owns its testability: which is a plausible account of why the two scores move together this tightly. The edge is a correlation being read, and no cause is being claimed. The one bright spot in the record points the same direction:
“I have noticed an effort to improve the acceptance criteria of the user stories we deliver.”
Where someone took ownership of acceptance criteria, people noticed within a survey cycle.
What happened next
The role-clarity finding fed directly into the engagement’s training spend on the product and portfolio roles, the ones whose boundaries the survey found blurred. The organisation kept watching as conditions shifted from there, and what the later numbers show is not a claim I’m making, that is theirs to make. The method travels, though: when requirements quality is poor, ask who wrote the last ten before asking how they were written. If the answer is a different role each time, the document format was never the problem.
A note on the data
A real engagement; an unnamed client, and it stays that way. Personal names go too. Team names and identifying details are removed, and quotes are lightly edited for anonymity. This page states no asserted figures. Its numbers and charts are pulled fresh from the underlying assessment data, built on close to 2,000 data points spanning the qualitative and quantitative work alike. One organisation, correlations not causes: worth watching for, but never treated as a rule.
Read Next
- Embedding test-first practices
A requirement is only as testable as the intent behind it is owned; test-first practices force that ownership question early.
- TDD as a design practice
The client’s untestable requirements were an authorship problem before they were a technique problem; TDD makes the gap visible per story.
- Epic Owner vs Product Manager
The role-boundary question this client couldn’t answer (“what is a product owner, what are they responsible for”) has a written answer.