Reverse-Engineering Requirements From a Prototype
A prototype is the best tool there is for discovering what people need, and the worst possible way to record it. The step almost everyone skips is turning what the prototype revealed back into traceable requirements. Do it, and the prototype's learning survives; skip it, and you ship the mock-up's accidents as if they were the plan.
An earlier piece in this series argued that prototyping has become the primary way to gather requirements, because people reveal what they need when they react to...
Epics as Hypotheses, Not Projects, and the Review That Makes It Real
Framing a big initiative as a hypothesis instead of a project is a genuine advance. But a hypothesis is a contract that requires a counterparty: someone to read the evidence and decide. Write rigorous hypotheses into an organization with no review gate, and you have produced the paperwork of agility with the behaviour of waterfall.
There is a real and valuable shift in how mature organizations frame large investments. Instead of defining a big initiative as a project, "we will build X, by dat...
When Building Is Cheap: Why AI Turns Delivery Teams Into Discovery Teams
Artificial intelligence does not remove the hard part of enterprise work. It removes the easy part, building, and leaves an organization face to face with everything it was using the difficulty of building to avoid.
Every article in this series has circled the same quiet truth from a different direction: in large enterprise change, building the software was rarely the real problem. The real problems were knowing what was worth building, trusting the data underneath it, deciding who owned the ...
The Prototype Is the Requirement: Why Interviews Alone Stopped Being Enough
The old model asked people what they wanted and wrote it down. The new one shows them something and watches what they do. The difference is the difference between stated needs and real ones.
For most of the history of enterprise software, gathering requirements meant the same sequence of moves. An analyst or product owner interviewed stakeholders, ran workshops, and asked people what they needed. The answers were captured in a document, a requirements specification, a set of user stories, a ...