← Portfolio · ← Collaboration 2.0
2.3 · What gets discussed on the platform — the PRD
Sub-sections: 2.3.1 Why a document, and why this one · 2.3.2 The decision — an artifact, not the culture
2.3.1 · Why a document, and why this one
So far I have explained the framework within which individuals do part of their communicating. But I have not said what to discuss there. It is the product. Not the technical details — a picture of it. What should it be? What should it be able to do?
Immediately after you answer those, the harder question arrives: why? so what? Those two tough questions make everybody who wants to answer them sweat. Because the answer has to convince the audience that the product will sell, or more broadly that it leads to profit or to a strategic goal in the short or the long term. Someone might try to escape by pointing at long-term views or strategic aspects of the product — and I would still catch you. Where is that strategy? Where is it written down?
Imagine a front-end developer, or someone whose speciality is electronics, who has been sitting in many meetings deciding how an IoT system or a software dashboard for managing an agricultural system should work. Now, who takes responsibility for answering those two tough questions on a recorded, transparent, shared platform?
I know my tone in those lines is as tough as the questions are. My intention has never been to push anyone, to embarrass anyone, or to prove that somebody lacks expertise. But if those questions are not carefully thought through, I believe the whole organization sooner or later faces a more painful outcome. Bringing the whole argument about the product online helps everyone arrive naturally at the consensus that there should be a clear target market, and a declared plan and strategy.
So the framework needed a way in: one thing the organization already did, chosen so that following the new rules and doing the job are the same act. The choice was the Product Requirement Document.
For the content of the PRD itself I followed this course, which fitted my style well. What I liked is the instructor’s consistent emphasis on how collaboratively a PRD must be developed, and on a PRD never being the final truth — it is, at any moment, the current source of truth. I am not going to explain what a PRD is or should be. There is plenty of material on that. What matters here is the reframing:
PRD = a document + the process that produces it.
Almost all the value is in the second half. The document is the pretext.
Why this one. Four things made the PRD the right carrier.
- It was already needed, and already missing. Nobody had to be talked into the idea that a product should be defined before it is built. The reform arrived as a favour, not as a demand.
- It sits on the routes rather than inside a cluster. To write a PRD you need the market view, the domain knowledge, the system design and the build constraints in one place at one time. That turns the structure ↔ market pair of crossings into a scheduled activity. Those are the two along which disconnected market work lands on engineers as work with no visible point, and decisions taken above the available information come back as goals nobody can act on. It also touches structure → culture, because what turns a technical objection into a political one is having nowhere to put it — and the authoring process is somewhere to put it.
- It makes people take part without anyone insisting. A PRD that no domain expert reviewed is visibly unfinished. You can check whether a section is empty. You cannot check whether someone is enthusiastic.
- It is anchored to a recognised standard. Putting it inside the ISO/IEC/IEEE 15288 system life cycle — concept definition, systems engineering, deployment and use — made it look like compliance rather than like a management fashion. In a conservative engineering organization, a standard is a shield.
- It bends. There is no global standard for a PRD, and the course material is consistent that it should not be treated as a rigid form. My template says as much to the author in plain words: adapt the structure to your own product or service. That flexibility is part of the mechanism, not a weakness in it. A rigid template handed down from above would have produced exactly the resistance the reform was built to avoid.
And one route it does not touch. The fourth crossing is culture → structure, where restrictive norms hold down the participation that would relieve the bottleneck. No PRD-shaped activity sits on it. Nothing in the authoring process obliges anyone to loosen a norm.
So the wedge was chosen for three routes out of four, knowingly. The fourth is where the reform is most exposed. 2.3.2 below says the same thing from the other side.
Templates were created — a general one, and a domain-specialised one. I am not going to reproduce the section list here. Two things about them matter here. First, each section was chosen so that it drags a different group to the table: a market objective stated as a number somebody has to defend, a prioritised feature list that makes a roadmap something you derive rather than assert, functional requirements only domain experts can fill in. Second, to avoid running two parallel documentation efforts, we folded components normally found in a BRD — a business requirements document — into what we still called the PRD.
That fold does more than save a document. The questions it brings in cannot be answered without a strategy standing behind them. What does this cost? What is the sales plan? Why this product before the other options on the table? Is the return we expect short term, long term, or reputational rather than financial? Nobody can answer that last one honestly without saying what the company is trying to do.
So the PRD does not solve the strategy problem. It necessitates a strategy, by making its absence visible the moment somebody sits down to fill in the template.
The template lives at _assets/PRD-template.md.
A domain-specialised variant. For the condition-monitoring product line there was a specialised template, and how it is split matters more than the template itself:
- Problem domain — filled in by whoever proposed the project.
- Solution domain, algorithmic — filled in by the team building the computational modules.
- Solution domain, production — filled in by the software team.
- Claims and disclaimers — agreed by every expert and lead involved.
The disclaimer section needs every participating expert to agree. It is the one place where an engineer can write down what the product does not do, and have the organization sign next to it. The obstacle tables behind the strategy-and-market cluster record a habit of assuming an idea will work because it is ours. A disclaimer that is mandatory, and signed by consensus, is aimed straight at that habit.
2.3.2 · The decision — attach the reform to an artifact, not to the culture
The decision. Deliver transparency, distributed decision-making and traceable accountability as properties of how one document gets written. Not as a change programme with those three things as its stated goals.
The alternative not taken. The usual intervention: a culture and communication programme. Workshops, a values statement, revised reporting lines, a commitment from management to be more open. Aim at the behaviour directly.
Why the alternative was rejected. Three reasons, weakest first.
Nothing forces it to happen. Going to a workshop does not change what the work requires. The next day, the same decision reaches the same desk by the same route.
It reads as politics. Where authority and responsibility have come apart at the top (1.2), disagreeing with a plan and being disloyal to a person start to look the same. Now run a programme whose stated subject is how people deal with authority. People will read it as a move in that fight, not as a repair to it. What the programme actually contains makes no difference to that reading.
It gives an order to something that does not take orders. This is the systems argument from 2.1.3, and it is the one that settled it. Trust, openness and accountability come out of how people deal with each other. Set the right local rules and you can produce them. Issue them as an instruction and you cannot. Tell people to be transparent and you get the performance of transparency, which is worse than the state you started in, because now it is harder to see.
There is a fourth way to say the same thing, and the diagnosis supplies it. A culture programme aims at a cluster — the culture-and-norms cluster, in the terms of 1.1.5. But no cluster holds itself up. Each one is held in place by the routes running into it from the other two. So an intervention aimed at a cluster gets absorbed.
That is not a prediction. It is the recorded history of every reorganisation and every values statement the division had already tried.
What the decision cost. It is slower, and it works at one remove. The culture change is a downstream effect, so a sceptical stakeholder is being asked to accept a chain of reasoning instead of a deliverable.
It also limits the reform to whatever the document touches, and that boundary can now be drawn precisely rather than waved at:
- By decision type: budget, promotion, hiring and strategic direction almost never pass through a PRD. Those are the decisions that did the most damage.
- By route: the wedge sits on three of the four crossings, not on the fourth (2.3.1). Nothing in a PRD workflow obliges anyone to loosen a restrictive norm, so the culture → structure route keeps running.
Both limits are real, and together they are the honest boundary of the whole intervention. They are also why 4.2 exists. The strategy had to carry what the document could not reach.
⟵ Up: Collaboration 2.0 · Previous: 2.2 · The approach — Collaboration 2.0 · Next: 2.4 · The collaborative authoring process →