← Portfolio · ← Collaboration 2.0
2.4 · The collaborative authoring process
Sub-sections: 2.4.1 The authoring loop · 2.4.2 Roles and lifecycle mapping
2.4.1 · The authoring loop
One note on reading Figure 6: I was a member of the system design team, and that block refers to a high degree to me, as the person responsible for this change.
The document is alive. The process is a loop, not a pipeline.
Figure 6 — the collaborative authoring loop. The PRD and its appendices sit in one shared space that everybody can see. Cross-functional teams write into it and read from it. The system design team looks after the process without owning what is written. Change requests come back from people using the document, which is what makes this a loop instead of a pipeline.
Design → Use → Update. The PRD is not signed off and frozen. Change requests arrive from two directions. Some are about the content: a clarification, a new feature, a technical problem, a change in the market. Some are about the process itself, from the stakeholders and developers who have to work it.
The second channel is the unusual one. How the PRD gets made is open to revision on the same footing as the product.
Approval is a checklist, not a signature. A PRD counts as complete when five things are true:
- the market goals and the performance numbers are there,
- priorities are stated as expected benefit against expected cost,
- dependencies and limitations are written down,
- the assumptions and the goals do not contradict each other,
- the content has been checked — by fact-checking, by peer review, and against what users say.
So approval stops being about who signed it. It becomes about what is demonstrably in it.
That is the whole reform, in miniature.
The likely failures were named up front. The rollout material lists them:
- poor communication,
- requirements written so vaguely that nobody can check them,
- every feature marked high priority,
- language too technical for the people who have to read it,
- attention on the technology instead of on what the user needs,
- treating the PRD as final rather than living.
They were in the launch material, which gives everyone permission to point at them.
And a stated position on perfectionism: imperfect action beats perfect inaction.
A tension inside the design, which I would rather name than smooth over. I pushed hard for people to contribute to the PRD. At the same time I said publicly that nobody should rush to blame a contributor, because market strategy and forecasting are genuinely difficult and full of factors nobody controls. Those two forces pull against each other. Press people to contribute, but do not punish the contribution for being imperfect.
The standard I settled on is that a plain, simple strategy beats no strategy at all. A stated plan gives you a baseline. Six months later you can ask why a decision was made, and trace how you got there. Against silence you can ask nothing.
The same transparency is also what stops someone steering a feature toward their own interest. The reasoning is public, and there are enough sharp people watching that a self-serving argument gets caught.
The platform was Confluence. It is exactly what I had been describing to myself before I found it. Notion was the alternative considered.
What stewarding the process meant in practice. For each part of the document the responsible and accountable person was named, and they were the ones who answered for the final content. Beyond that, the steward’s job was to watch for the political moves the old pattern rewards, and to keep an argument from being won by position rather than by evidence.
2.4.2 · Roles and lifecycle mapping
Transparency on its own produces a different disease: everyone can see everything, and nobody owns anything. So the framework came with a responsibility model attached.
That part is not mine. A teammate — I will call him Hamed — proposed a role and lifecycle model. I found it well matched to the platform, and complementary to it, so it is introduced here rather than claimed. In outline: ten roles, five lifecycle phases, arranged as a RACI matrix, with one rule held firm — exactly one accountable person per activity. Several people may do the work. One person answers for it. Each phase also names who owns which artifact.
The concepts it rests on are standard, and worth naming rather than explaining here: the system life cycle processes of ISO/IEC/IEEE 15288, its software counterpart 12207, the INCOSE Systems Engineering Handbook, and the RACI responsibility-assignment convention.
How it helps Collaboration 2.0. The platform makes contribution visible; the RACI matrix makes ownership unambiguous. Without the second, wide participation turns into a crowd with no author. With it, every artifact the authoring loop produces has one name attached to it before the work starts.
The claim has to stay narrow. A responsibility matrix does not rebalance a company’s authority, and 1.2.2 says plainly that the enabling conditions cannot be removed by decree. What the matrix does is smaller and real. Inside the work it covers, it puts authority and responsibility back together, and the name against each decision is written down before the decision rather than looked for afterwards.
⟵ Up: Collaboration 2.0 · Previous: 2.3 · What gets discussed — the PRD · Next: 2.5 · The adoption argument →