Requirements Aren’t Required
It is common for companies to draw up a document containing product requirements when building a new solution, especially in Waterfall environments. This sets the tone for what the development team would have to do. However, while requirements may seem to provide clarity on what must be done to have a great product, they can be counterproductive at times. It’s high time we realized that what we term requirements aren’t really required in most cases.
What Are Product Requirements?
By definition, product requirements refer to the features, capabilities, and behaviors that the product must include. They are constraints or properties that are necessary to be able to satisfy the needs of the user.
Therefore, requirements are usually given high importance when building products. They are often recorded in what is called the product requirements document (PRD), which communicates the product to build along with its purpose and value. This document also goes by other names including functional specs and market requirements.
One thing with requirements is that they carry expectations. The term seems to suggest that they are not negotiable but mandatory. Requirements set expectations as to what the “done” product will look like. Yet, they aren’t always feasible or advisable.
Requirements Aren’t What They Seem
Product requirements come from different sources, including team members, stakeholders, and customers. They represent what each group thinks the ideal product would be. But experience has shown us that what we regard as necessary in the product isn’t in many cases.
Team members and stakeholders brainstorm to come up with requirements that the solution should include. They think that these need to be covered at some points, so the engineering team must ensure they deliver. Yet, in practice, most of these requirements aren’t needed. Customers also will have ideas as to what our product should do. They make feature requests that they think would make their lives a lot better. Giving in to such requests is how some companies have become feature factories.
As Marty Cagan rightly points out, requirements by stakeholders are often nothing more than theories or assumptions about the right solutions. Those of customers are usually just hypotheses on the perfect product they need – they don’t really know. Essentially, most things regarded as requirements are merely assumptions, opinions, or misconceptions. Experience has very much shown them to be so.
Requirements relate to solutions. This might suggest attention to the customer’s pain points first, but it’s not necessarily true. When thinking of requirements, our attention is usually on the solutions to provide. These required features, capabilities, and behaviors tend to shift our focus from the problem.
Yet, understanding the customer’s needs and pain points is our primary duty. It is this that enables the cross-functional team to be more effective in how it goes about building a valuable product. And it implies not developing a PRD and handling it to engineering but involving the team in creating real requirements.
Too much emphasis on requirements contributes to the phenomenon of feature bloat. We end up providing the customer with more than they need to solve their problem. This not only results in a waste of scarce resources but can also impact adversely on the user experience.
The foregoing explains why less formality is applied to requirements in Scrum. The team is free to write them as it finds most suitable for its work. Requirements in companies using this methodology typically take the form of user stories, which draw attention to problems and motivations behind features.
What Matters More
As Cagan notes, the real requirements are not immediately obvious when we are starting. We only begin to observe them more as we move along in the process of developing a product. So it doesn’t make much sense to compile them before anything is done. We need to be critical about how we assess the value of requirements. Are they indispensable? Must we deliver them or nothing?
The direction we have in focus when building a product should determine what we need to include. What is considered an essential requirement might not be technically feasible. Do we then give up on the product? No, we can instead take a different approach that might give us an even better result.
If we cannot provide perceived value by delivering a requirement, we can provide as good or even better value another way. It’s a matter of being creative and focusing on the ultimate goal rather than on unproven assumptions. We should be more concerned about creating solutions that customers would love. This won’t just happen by collecting requirements from different sources. We need to do more intentional discovery.
Rather than just taking feature requests from customers, we should look to having more productive interactions. It is necessary for us to get out of the building to talk to the customer. We have to take our time to interact with and observe users to understand what their real problems are. Our interactions with customers provide a basis for knowing what to include in the product. This doesn’t necessarily entail Product writing requirements or specs and handing them over to engineering to build. There should instead be collaboration in the cross-functional team to identify the right solutions.
Also, we should not forget the place of a minimum viable product (MVP) or prototype. This not only helps us to assess usability but also the viability of whatever solution we are thinking of providing.
