When I first started out in R&D I was convinced that requirements was the most important part of the product development process.
Requirements should be clear and precise, show the R&D team what to do and what not to do. They create boundaries for the project and I saw this as a good thing.
I did not bother too much about where the requirements come from. I thought that my marketing department, the R&D experts and the product manager together with some production knowledge, was all that was needed to create great requirements for any product from start.
I once participated in a larger R&D challenge, we were about 100 engineers divided into 8 teams developing a new and exciting product. One of the teams focused on requirements for the other teams. We started our work, and worked with a tight schedule. After 4 months of hard work, we sent the final drawing of our part of the product, to a manufacturer for prototyping. It was also the same week we saw the first version of the requirement specification…
Clearly the requirement specification was not the controlling document I thought it to be when I first started in R&D. The engineer responsible for the requirements was clearly disappointed, that the requirement was not the control document he wanted it to be. Yes, we used the requirement specification to create test cases, which we later used to validate the product. That part of it worked. But it made me think that maybe, there is another way of working with requirements?
How do we solve this problem? We want to have a requirement in the end of the project to have a good stable ground to test it against. We need to know that our product works before we ship it to customers. It’s expensive to find out problems in the field and repair/replace parts of the product in the field. If that happens it will also hurt our goodwill/reputation and in the long run our sales.
I adopted a more pragmatic approach to requirements. I started to use fuzzier ”goals”, which essentially picture the impact the product is expected to have on the company, in different aspects. During the first phase, when we try to invent the new product, we look at the impact objectives and try to figure out how well our solutions map these objectives. The answers to these questions are usually our requirements. The result is that we end up with a concept and the requirements at the same time. Still we need to ask how valid these requirements really are. The result is usually a product of internal work. We don’t systematically involve our intended product users. We assume we know what they like and add these kind of features. But how can we be sure?
Last year I read the book ”The lean startup” by Eric Rise. His big point was that small start-ups as well as mature companies that develop new products face the same problem. There is no way that they can know for sure that the requirements, or ”assumptions” they make about a new product, are valid unless it’s tested on customers. And if you need to test the product on customers, it’s a big waste to finalize the product before you test it. Some featuers might not fit the customers expectations and be replaced by something else. If this is the case we like to develop as little as possible and test it as fast as possible to avoid developing stuff that we later through away. Eric calls this a ”minimum viable product”, or for short MVP. A MVP is used to validate assumptions we do early in R&D when we really don’t know too much…
I don’t really see any problem mixing these two strategies. Start with your expected impact on the company. Make assumptions on how to realize these in a product. Validate the assumptions as early as possible by testing, to a limited audience of customers, a MVP. Features that create a product those customers are delighted to use stays and are implemented in the concept and in the product. The features that don’t create the intended buzz are quickly ended or modified until they create a buzz, in another test.
Requirements can be a really big waste of time, if we assume that we know what we need and how a future product should work. On the other hand we do need them later to make sure that the features we do select to implement, have the quality we need them to have.
Keep requirements simple, make them visible and trust your team to do the right thing!
Want to know more?