Quick survey, show of hands … How many reading this post use email? 1, 2, 3, 10, 100 – ok everyone! Question #2 … How many use email for sending documents? 1, 2, 3, 10, 100 – ok everyone! How often have we seen email used as a means of sending a document over the wall – far too often. I’m sure you are thinking the same thing. Your email goes bing; you read it and think where did this come from. Email is supposed to be a communication tool; but it sometimes just doesn’t work.
What happens when product managers send their requirements document over the wall to the development team? In some cases, the designer interprets the document properly and the resulting design document properly reflects those requirements. However, in more cases than we’d like to admit to, the design does not even come close to aligning with the requirements. What happened? The product manager wrote everything correctly, but the designer didn’t interpret it the way the product manager intended. Something was lost in the translation.
The goal of a requirements document is to convey what the feature or capability must do. When things go awry, it’s most likely caused by misinterpretations. In other words, the product manager and the designer (or developer or analyst) need to be on the same page. The product manager must convey his thoughts and knowledge to the designer. In many cases a document attached to an email does not do this.
Here’s what I suggest …
- After you understand what the key requirements are and who the key users are, arrange a meeting with the development group to present your findings. Don’t wait until you have everything and certainly don’t wait until everything is written down.
- Put together a 30 minute presentation (10 slides or so) that contains: your vision of the feature, what problems it solves, and who it solves them for; the typical scenarios in which this feature will be used; and the top 5 functional requirements (expressed as use-case summaries) and top 5 non-functional requirements (expressed as declarative statements).
- During the presentation ask the audience to parrot back what you just presented, but in their language. This is the most critical part. They have to understand what your intentions are right from the get-go – it will set the tone for the design efforts that will begin as soon as everyone heads to their desks.
- After the meeting send your presentation to the development team and set a follow-up meeting to review additional requirements and the initial design. This is where the iteration process starts. Don’t wait for everything to be completed … iterate your way to completion. While you are waiting for the next meeting, write your requirements document based on the contents of the presentation.
- During the days leading up to the next meeting, walk over or phone the development lead to see where they are at. Make sure that they are moving down the right path; listen for hints that they are not following one of the key requirements or have made assumptions about what you presented (remember that people only retain 10% to 25% of what they hear during presentations).
Try it … I think it will help you to ensure that your development team truly understands what you want them to build. And please, don’t throw the document over the wall.