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.
Software Product Manager by Gopal Shenoy 
I think Marty is really urging us to develop awareness to think beyond “formal” requirements (e.g. business, functional requirements) and instead focus on discovery of solutions that address higher-level goals that the users are trying to accomplish with the assistance of the product.
As an example, a product (e.g. enterprise software) being designed to address a business goal (e.g. reduce material ordering time by 50%) will have formal requirements (business & functional) documents but until that product is really measured against its ability to address the business goal (Marty calls it…”It’s the result that matters”) the product discovery & solution development process should be flexible.
The product development process is made of the following high-level steps…
Why –> What –>How
In this discussion the What typically becomes the requirements that drive the development process. The expression of the requirements is based on a perception of how it addresses the need or problem (Why). The How becomes the implementation.
The requirements then become a lens through which we which we guide the product development process. Marty is asking us to focus our attention on measuring the product against the Why instead of measuring against the What.
Thoughts/feedback?
Gopal, in complete agreement with your perspective. A lot of customers express “What they need” but what is possibly more important is “Why they need of what they need”. So as Marty has expressed that what really matters is a solution that satisfies all stakeholders (addresses the “What” part) to be able to do so requires a deep understanding of the need. Because if the why part is known then the requirement will be able to cater to a wider range of what (from wide array of customers). It would be impossible to do the same without having captured the requirements. Requirements here need to have taken into account the “What” and “Why”, using which the development is going to define the “How”.That possibly is one of the challenging aspect of being a product manager.
You can say, the software must authenticate a user, but to specify an authentication method as a functional requirement is not OK. Specify some criteria that must be met by the authentication method, but do it in the non-functional requirements. This is the case even if that authentication method is your core technology.
When you have a technology, rather than using someone else’s, and you actually sell that technology, you will need to define products layered on top of that technology. But, what customers are paying for is the reduction or total elimination of a constraint, so they are enabled to do something that couldn’t be done before, or do something better than it was done before. The real requirement is that thing they will do, not the means of getting it done.
Requirements were invented as a concept to improve programmer productivity. We write them to that end unfortunately. So even if you were prototyping to a product, building the code efficiently means writing requirements that lead to write that code. That said, requirements originate in the subject domain being automated (the carried)–WHAT. Once written, programmers abstract away from the requirements and focus on the technical carriers–HOW. Only in the model and view do programmers return to the carried. So you end up with WHAT>HOW>WHAT. These distinctions are not all that clear in programing languages and developer tools, but they are there.
If you were going to prototype towards a product, break the product down to minimal marketable functionality (MMF). Write traditional requirements docs for each MMF. Then, use the MMFs as LEGO blocks to build your prototype. Still requirements don’t disappear.