We’ve been doing some thinking over the last few months about how we communicate product requirements to teams. In fact, we’ve been asking ourselves if ‘requirements’ are even the right term to use. Should we be telling engineers, designers and other specialists what we ‘require’, or what the problem is that they should solve? Are those the same thing? And do we communicate in ‘user stories’, product requirements, specifications or some other means?
When we’re asking people to design and build software products, there’s a tricky balance to be struck. On the one hand, as I’ve certainly learned from painful experience, failing to be clear about every detail can end up in a product that doesn’t quite do what I expected. On the other hand, trying to define every aspect of a product before we start building it risks taking autonomy away from the very smart and knowledgeable people doing the actual building, and missing the opportunity to discover better approaches as we go.
The military might seem like an odd place to look for inspiration in solving this challenge. In tech products, we often see ourselves as much closer to, say, the construction industry - with our architecture, engineers, prototypes, and talk of ‘building’ things. But I’m not sure that’s always the best analogy. Construction demands precise plans documented up-front, with specialists delivering exactly what’s been asked for, to exacting tolerances, with little room to adapt on the fly - exactly the approach we’re trying to avoid.
Compare that with a military operation which (despite the phrase ‘planned like a military operation’ tending to imply a high degree of precision and control) intentionally builds in flexibility and adaptability at every stage. Above all, it recognises the benefits of allowing decisions to be made as late as is safe to do so, and at the lowest level possible. What goes hand-in-hand with that is a finely-honed process for imparting the information that people need to be able to make decisions and act with autonomy.
Military orders follow a precise structure, and can be pages and pages long (or take hours to deliver in person), yet within them, there is really only one line that specifically tells each junior commander what they must do. Often only a few words long, they’ll read as something like ‘Defeat the enemy position at XYZ, in order to enable the company advance to ABC’.
Everything else is about providing the junior commander with what they need to best decide how to approach that task.
I won’t go into every intricacy of the orders format, but at a simplified level it consists of:
As I say, that’s over-simplified, but the more I think about the question I’m trying to answer about how to communicate technical requirements, the more I like this model. The above is, really, the same information – I would argue – we need to be communicating with engineering teams. So maybe, instead of worrying about what we call it (requirements, user stories, specifications, etc) we focus on the information we’re trying to impart.
If we civilianise it, here’s what I think we’re aiming to communicate:
I don’t know if this is perfect, but I’m excited to discuss it with my teams as a way to think about communicating requirements. Many teams will probably already be confidently doing all of the above through their existing PRDs or user stories, but if you are struggling a bit to figure out how to communicate requirements then maybe going back to basics and breaking it down to a list a bit like the one above could help.
We’ve been doing some thinking over the last few months about how we communicate product requirements to teams. In fact, we’ve been asking ourselves if ‘requirements’ are even the right term to use. Should we be telling engineers, designers and other specialists what we ‘require’, or what the problem is that they should solve? Are those the same thing? And do we communicate in ‘user stories’, product requirements, specifications or some other means?
When we’re asking people to design and build software products, there’s a tricky balance to be struck. On the one hand, as I’ve certainly learned from painful experience, failing to be clear about every detail can end up in a product that doesn’t quite do what I expected. On the other hand, trying to define every aspect of a product before we start building it risks taking autonomy away from the very smart and knowledgeable people doing the actual building, and missing the opportunity to discover better approaches as we go.
The military might seem like an odd place to look for inspiration in solving this challenge. In tech products, we often see ourselves as much closer to, say, the construction industry - with our architecture, engineers, prototypes, and talk of ‘building’ things. But I’m not sure that’s always the best analogy. Construction demands precise plans documented up-front, with specialists delivering exactly what’s been asked for, to exacting tolerances, with little room to adapt on the fly - exactly the approach we’re trying to avoid.
Compare that with a military operation which (despite the phrase ‘planned like a military operation’ tending to imply a high degree of precision and control) intentionally builds in flexibility and adaptability at every stage. Above all, it recognises the benefits of allowing decisions to be made as late as is safe to do so, and at the lowest level possible. What goes hand-in-hand with that is a finely-honed process for imparting the information that people need to be able to make decisions and act with autonomy.
Military orders follow a precise structure, and can be pages and pages long (or take hours to deliver in person), yet within them, there is really only one line that specifically tells each junior commander what they must do. Often only a few words long, they’ll read as something like ‘Defeat the enemy position at XYZ, in order to enable the company advance to ABC’.
Everything else is about providing the junior commander with what they need to best decide how to approach that task.
I won’t go into every intricacy of the orders format, but at a simplified level it consists of:
As I say, that’s over-simplified, but the more I think about the question I’m trying to answer about how to communicate technical requirements, the more I like this model. The above is, really, the same information – I would argue – we need to be communicating with engineering teams. So maybe, instead of worrying about what we call it (requirements, user stories, specifications, etc) we focus on the information we’re trying to impart.
If we civilianise it, here’s what I think we’re aiming to communicate:
I don’t know if this is perfect, but I’m excited to discuss it with my teams as a way to think about communicating requirements. Many teams will probably already be confidently doing all of the above through their existing PRDs or user stories, but if you are struggling a bit to figure out how to communicate requirements then maybe going back to basics and breaking it down to a list a bit like the one above could help.
