You’re Gathering Product Requirements Wrong [+ Statistics]
If you were to map out your product development process and circle the place all your problems originate, where would you pick…
And why is it when you’re gathering product requirements?
And that’s not just because it can feel like a bottomless task to get everything together, but because more importantly, it creates a ripple of risk, that looks harmless early on, but morphs into a project tsunami later on.
Software engineers agree with the struggle product managers find themselves facing; with Deloitte finding 64% of software defects stem from the requirement or design phases.
Simply put, gathering product requirements is something all teams do, but not all can do effectively.
Read on for more on why requirements gathering isn’t leading to better results for product managers and how teams can overcome these pitfalls.
Let’s talk about requirement gathering…
So, 64% of software defects have origins from the requirement gathering and design phases.
That’s huge. If teams ultimately spend all their time solving problems that could have been righted before they happened, then that makes the pre-development phase very important to product success.
In fact, poor requirement gathering practices can add 60% on time and budget costs, contributing to extended product delivery timelines and the statistic that only 55% of products are launched on time.
The issue typically has roots in how gathering product requirements is currently done:
- Lacking inter-team expertise: Building specifications is often done in isolation from team members who can add value to the project and best address the issue. E.g. If you have a technology team that aren’t involved in identifying the solution, then the issue may not be feasible in-house or with your current tech stack.
- Assumption-first products: Siloing also extends to the customer themselves, preventing any specification built from understanding the full picture of what the customer needs and wants. This can be taking 2nd or 3rd hand opinions as fact without validating assumptions.
- 0 to 60 product delivery: Gathering requirements can feel to a lot of higher ups like inaction. This results in pressure on product teams and business analysts to deliver requirements faster so you can get to engineering asap. The consequence is, this can mean jumping iteration phases, design and leave a lot of unknowns on the table, creating a higher risk of failure.
Long story short: Poor specifications driven by assumption, lack of client understanding and culture of just being about how it will work can have huge cost/time implications, ultimately resulting in outcomes that affect your overall product delivery later down the line.
On assumption-led product development:
“[when Marty first broke into product management] The product manager was supposed to have the answer, and write up the answer, and the engineers were supposed to build it. And, I believed that, early on. And it was completely wrong. What you learn over time is that you don't know those things.”
Marty Cagan (Silicon Valley Product Group) Product People Podcast
Product Requirement Gathering Statistics –
Costs of bad requirements gathering:
- Deloitte found 64% of software defects stem from the requirement or design phases
- Poor requirement gathering practices can add 60% on time and budget costs
- 41.5% of new project development resources will be spent on unnecessary or poorly specified requirements
- 70% of organisations don’t take effective action to improve the quality of their requirements
- Identifying requirements for an Enterprise Resource Planning (ERP) solution can be 6 to 24 months.
Product Managers and Requirement Gathering:
- Defining product requirements only takes up 14% of a product managers role
- 39% of Product Managers say they worry about missing launch dates, which can be influenced by poor requirements gathering
- 21% of products fail to meet customer needs, influenced by product requirements being not fit for the customer early.
Improving Requirements Gathering
So, specs produced by not talking with other team members or customers ultimately ends up with worse end results.
But we believe all the issues mentioned before can be solved by a process that encourages collaboration and customer understanding before going straight into requirements gathering.
Product Discovery!
How Does Product Discovery Work?
Product Discovery is a process that requires teams to develop a strong understanding of customers to later then deploy that knowledge in the products they build.
In building a bigger picture of customer needs, existing processes, in-house skill sets and focusing on design before development, teams can gather product requirements that are more likely to end in better products and not need expensive changes later.
This takes advantage of the fact that product managers have significant overlap and access to other departments (34% of departments report to product management), while ensuring any customer insight and research is used to inform better decision-making (74% of product managers, researchers and designers believe research is partially or fully effective in determining decision-making).
Product Discovery Techniques
Here’s some of the techniques and exercises we use at Pixeltree to improve the product requirement gathering process and product outcomes.
- Objective and results exercises: Whether it’s a new product or feature, alignment and collaboration is crucial to what insights you’re able to gather and what you inevitably set out to build. Having teams join to highlight their top objectives or outcomes of any launch can help bind the team together and make dialogue on requirements easier.
- Using the ‘Sailboat’ exercise: Being able to address as a team what your goals are can be useful, but being able to merge them with what’s driving this need to reach the goal and what could be holding you back can help guide teams to building better products, and for defining the requirements that will get you there.
- Harnessing user personas: Having a picture in everyone’s minds of who they are serving when they’re gathering product requirements means that you’re always moving towards the best possible solution.
- Service Mapping/User Journey Mapping: Committing your user journey and all touchpoints with your service to paper where everyone can see can open minds across your organisation. Using mapping as a tool to provide context can help teams identify and agree on requirements.
- Analysing user research: The user will almost always know best. Whether its data gathered from the customer or shared from internal teams like customer services, you should pool this knowledge together and pick out the key themes that will drive the end product you eventually gather requirements for.
Conclusion:
In short, the way teams currently approach gathering product requirements has significant but manageable drawbacks.
Product discovery can help teams overcome many of these issues by focusing on involving the most valuable stakeholders in the process pre-requirements gathering.
Product discovery isn’t meant as a substitute for product requirements gathering and may take more time to progress. However, the lower potential risk and better informed decisions earlier can mean better requirement gathering phases, and in the long run, more successful products.
For more ideas on how you can conduct your own product discovery, check out the details in our latest partnership post with the largest cotton governance body, the ICA!
Want to build the right product in as little as 4 days?
Fill in the form below and let’s have a chat!
