Or 'why your start-up should finish your User Requirements document now...'
“Yes, right now, everyone drop everything, even you, Tim, get working on these requirements. Ok, well not everyone, Tim you focus on recruitment... Wait! It looks like we don’t need recruitment as much as we thought we did, it’s just the office looked a bit empty. TIM! - get on with marketing, one of our directors read that the hottest start-up companies rank it as the 2nd most important metric now…”
Now, I am sure you don’t run your company this way, changing direction without solid reason, I’m sure no one does, not even me (people kept mixing Tim and I up on conference calls, so he had to go), yet trying to develop a product like this, without an agreed, signed off and distributed User Requirements Document is extremely common.
Having worked as an Engineer, Engineering Team Lead, and System Lead, I know that nothing delays product development or frustrates a technical team as much as a moving or unnecessarily vague target.
Let’s go over an example. You’ve spent ages speaking to potential customers and validating a market for your product and know it needs a nice user interface to impress. You want to know when you’ll have a version ready to demo at trade-shows, and get a 5 week estimate from your technical team. They throw together a functional requirements list, work hard and a sleek touchscreen demo is ready for the end of week 4. Great, except you know your users in healthcare wear gloves, and often need to enter a paragraph of notes so a touchscreen is completely inappropriate, yet the software team delivered exactly what was asked of them (and ahead of schedule, did I mention this was fictional?!). Suddenly, the Hardware Team have lost 4 weeks which could have been used finding a suitable keyboard and the Software Team now have just 5 days remaining to hack together a rough user interface and so need to push back deadlines at least another 2 weeks.
This of course leads on to the second point of frustrating and impeding your technical team. Four weeks spent on work which is now essentially useless, compounded with having less time to make a revised version is incredibly frustrating. Not committing the requirements to paper and the lack of a telepathic link to the user research in your head has caused unnecessary delays.
Writing a User Requirements Document is difficult. Great User Requirements detail solid user research, and no more. It does not attempt to provide potential solutions, nor force numbers into a requirement to make validation work easier. That all comes next, in the system architecture and functional requirements documents. The act of writing and committing the User Requirements document to paper also forces the company to identify and confront holes in the project. This allows further, focused user research to fill the blanks.
These documents are far from my favourite bit of designing systems, but I do think they are one of the most important parts, and vital to get right. I’ve been through the process of writing these requirements many times, and for 3 clients with Fewer Moving Parts already this year, if it’s something you don’t have yet, or you'd like support with, please get in touch, I’m sure I can help.