Quite a punchy headline but it’s the painful reality for many organisations. If your business is led by product /project / program / BA teams, who’s currency is ‘requirements’ and who’s success is defined by ‘delivery’ metrics, then you cannot be realising the true potential growth for your organisation...
Who should be reading this blog? Businesses of all sizes, anyone looking to launch or grow products and services, anyone interested in digital transformation and product management.
Firstly, it’s worth clarifying, what do we mean by requirements? For the purposes of this blog we simply mean the process of asking stakeholders what they want in a product, service or feature, the creation of a ‘list of requirements’ on the back of this and the direct execution of these requirements to the product. And don’t get me started on stakeholder ‘wish-lists’…
Secondly there are always edge cases, for example if you need to directly replace a product or meet regulatory needs, in which case strict requirements are important. However the principals still apply.
So…
Why are requirements so bad for organisations? It’s a surprisingly simple answer. If you have a requirements defined delivery culture then you are relying on stakeholders providing these requirements. Your delivery functions will be executing against these with a success metric of on-time and on-budget delivery. Your organisation will not be agile or dynamic and won’t be solving problems your customers want you to solve. More importantly, your learning and feedback loop will be glacial — you will be learning AFTER you have shipped.
Why are requirements so bad for people? When you deal in requirements you are forcing the people behind them to define things very specifically. Requirements then get set in stone and delivery is judged on how closely requirements were followed within a set time and budget. When things go bad, the product is failing and the numbers are going down, the feedback loop becomes a blame game and the requirements were ‘wrong’.
In this scenario there is far too much pressure on stakeholders, the voice of the customer is tiny and the rate of learning is intensely slow…
So how do you fix this? You shift your organisation from a currency of requirements to a currency of problem solving and assumptions. At Skull Mountain we have helped many clients move from asking stakeholders ‘what do you want’ to asking them ‘what problems do we need to solve’ in order to meet goals and objectives for the business. The key word here however is ASSUMPTIONS.
Once you have clearly defined goals and objectives then it should be easy to see what problems you need to solve. Once you have problem statements then you empower your teams, partners, stakeholders, customers (everyone involved) to provide assumptions on how to solve these problems. Assumptions can be initiatives, features, functionality, marketing campaigns etc. basically any potential problem solving solution. They are assumptions because you are assuming that this new sign up button is going to increase conversions.
The beauty of an assumption is that it is a license to be wrong — quickly.
The beauty of well defined problem statements is they engender strong agreement across organisations.
With a series of assumptions being validated through the product roadmap your organisation will now be rapidly learning and validating how to and how not to meet your business goals and objectives. This leads to ultra efficient use of time and budget as you quickly rule out all of the assumptions that proved to be wrong. (To be clear we are NOT talking about failing fast — learning where not to spend time or money is not a failure.)
So problem statements and assumptions are the answer? Yes — certainly not requirements…
Just try it. Pick one project next week and move the conversation to ‘what problems do we need to solve and what assumptions can we make about how to solve this problem’ SEE just how quickly it changes the dynamics of a conversation with stakeholders, engineers, designers etc…
Here’s what a client of ours said. This was a CTO trying to change a very big organisation: “You gave me the confidence to go ahead and really push this change when you showed us that we’ve already failed if we are spending our time gathering requirements from stakeholders”
We have fundamentally changed several of our clients with our approach to product management and digital product transformation as such I am thinking of doing a round table Q&A with these clients (and some excellent speakers) If you are interested in getting involved, let me know and i’ll organise a Q&A dinner soon.
