03/07/2024
No single way of collecting product requirements is a silver bullet for a good product.
The key is for teams to become familiar with the advantages or limitations of the framework they’re working with, whether that’s teams leaving feeling heard or, on the VERY flip side, the product failing miserably 🚽
🌊 Waterfall 🌊
Linear and step by step, waterfall puts requirement gathering right at the start of the project, with the results of your findings trickling down into design, development and beyond.
As the standard process for some time, teams find it easy to understand why it’s placed early and means that you get detailed granular requirements really early which serves to clarify for any people later in the delivery chain.
However, missed insights, bad problem definition or choosing the wrong solution can all result in negative effects that run deep into the project without a way of pivoting because of its rigid structure.
👟 Agile 👟
Focusing on speed and better inter-team collaboration, the Agile methodology often uses sprints to build up an understanding of the requirements needed on an on-going and iterative basis.
As it’s far more fluid that Waterfall, Agile teams benefit from the ability to adapt requirements at a far cheaper cost as you’re consistently experimenting in the early phases. It also means you can scrutinise your hypotheses more often and as a result, get a better product at the end of it.
But Agile isn’t perfect for gathering requirements either. The iterative nature of Agile means that you need to firm with when you stop refining, otherwise you'll be left infinitely gathering requirements.
In short, we believe it’s essential that product teams get to know the pros and cons of how they gather requirements, because without it, you’re making the risk of the below way higher:
💰 Expensive repairs or pivots
📦 Delivery times that never arrive
😡 Products users didn’t ask for
Read more on things you should remember when collecting requirements below 👇
https://pixeltreemedia.co.uk/things-to-remember-when-collecting-requirements/