Requirements are ….
November 11, 2010 3 Comments
One of the blogs I read frequently is that of Marty Cagan, the author of “Inspired – How to create products customers love” (one of the books that I strongly recommend to product managers and executives). Often, I agree with Marty on his perspectives, having experienced the many pitfalls he writes about in his posts. A month back, he wrote a post titled “Requirements are not“. In this post, he writes about how different stakeholders such as customers and internal stakeholders mistakenly call some things requirements while they actually are not. No disagreements there. But then he compares defining and creating a product to cooking by saying “I find defining and designing product is more like cooking in this respect in that if an ingredient is unavailable, you can often get creative and substitute something else or a combination of things that aren’t quite the same but may be even better. It’s the result that matters, not our pre-conceptions.” He concludes by saying “Our only real requirement is to discover product solutions that work well for our users, our customers and our business.”. This is where I disagree with Marty or I am confused about what he is saying.
Here are points I completely agree with Marty on:
- Customers and other stakeholders often propose solutions and not articulate problems. I have written about this very thing before – the difference between customer pain points vs. requirements
- Requirements are unclear at the beginning and take shape as the understanding of the problem becomes more clear.
But saying that there are no absolute functional requirements is just plain wrong. Product Managers need to delve deep into the customer’s problem and at some point come up with a solution that will solve the problem in the most usable, technically feasible and cheapest way – this is all done during the product discovery process that Marty has championed in his book. Such a solution will have absolute functional requirements once it gels into a viable solution. These requirements have to be met when the solution is implemented. Trying to change the requirements as the solution is being built (like you could do in cooking) is costly even in an agile environment where there is utmost flexibility. Yes, you do discover new solutions during implementation, but functional requirements do not change. The functional requirements describe what the user expects to do when all is said and done. For example, the functional requirements of an “authentication mechanism” do not change even if engineers figure out a new way to engineer it. Users still expect to login using their username and password, they will forget their usernames and passwords, they will type in their usernames or passwords wrong.
So, while I agree that requirements are hazy at the beginning, they should be become absolute at some point in time during the development cycle, such that the solution can be built, tested and communicated to the customer. Saying that the only real requirement is to discover product solutions that work well for all involved, is a very generic statement, but not one that product managers and engineers can use to build the product solutions. The word “requirements” are probably misused, but throwing out the whole word from the product lexicon is unwise.