Why is writing requirements so hard?

Did you ever play that game at school where you would all sit in a circle and someone would whisper something in the ear of the person next them? Then that person would whisper it to the person next to them, and so on until it came back to the person who said it first. Inevitably, the thing that was said was nothing like what the first person said, which was hilarious.?

Writing, and communicating, requirements can feel just like that sometimes, but no one is laughing at the end result. It also, to me, seems a bit mad that for something as complex and multifaceted as software that when the end result doesn’t match it is only the requirements that get the blame.

Here are some tips for Product Managers to help get your software close to what you intended it to be - whether you are writing requirements or leading teams of people who do.

Communicate widely and with variety

A common trap I find is when a Product Manager finishes their discovery phase and it comes to writing the requirements for the engineers, they stop talking to all the people who worked with them to that point. They assume that because they spoke with them about it once, it was enough. However, people are busy and when they return from workshops to focus on their day job they can forget commitment's and decisions they had previously made. This doesn't make them bad at their jobs, but it does highlight the need for constant communication and involvement.

This issue is best tackled by working more cross functionally and collaboratively throughout the whole process. For involving engineers, Teresa Torres continuous discovery habits is probably the most ideal way of working, but for many this isn’t feasible within their organisations immediately. As a stepping stone, you may consider dual track discovery and delivery. Another options is to adapt the delivery processes to include discovery tasks as this can help planning the time needed from engineers.

For involving stakeholders, consider who needs to have closer involvement and who does not. A simple power / interest matrix can help analyse your stakeholders. Then consider how you interact with them. For your "context setters" making your governance meetings interactive with demos can make them more memorable and support a deeper buy in. Anyone in the "players" quadrant you should be having regular check-ins so changes needed as development progresses are communicated and supported .

With all these varied people involved you are probably creating a variety of different artefacts to communicate your message and keep everyone aligned. This is great, and can all help communicate what the final requirements are. To make it work well though, keep these as living documents with version control - particularly so engineers know which bits to build from, and stakeholders know which bits are live and which are not. Wikis work very well to support this.

Balance speed and certainty

Product Managers, and software development teams, operate in uncertain and complex environments. We create processes to help manage the chaos, but really when you are building software it is often a novel experience. With uncertainty, any human’s instinct is to create more control, even if it is only the illusion of control. Evermore?analysis can feel like more control, and a likely response to a few releases with “wrong” requirements. However, spend too long and you could miss the opportunity in the market for your product, or undermine the value return on the investment made.?

Know what good enough looks like, ship and learn. But also…

Build ways to fail fast

This doesn’t mean get sloppy with your analysis, or only do half the job. It means things like having tight feedback loops, good monitoring and alerts, a solid roll back process. But, it is better to fail even earlier - use prototypes to test, have a robust discovery methodology, and analyse at each sprint if the investment in the next should go ahead.

It is all in the system

Writing requirements is hard. Being precise is important, but is only small part of what makes for effective requirements. If you are finding requirement writing a challenge for your teams, you might need to look at the processes that support you and your teams getting to the requirements. If those processes look like a game from the school playground you might want to think about a different approach!

I help Product teams perform better by looking at the processes the operate in, and providing training to improve their skills. Get in touch if you'd like help with your Product teams.