Sure, it’s quite a punchy headline but it’s the painful reality for many companies. If your company is led by ‘project’ or ‘program’ teams, whose currency is ‘requirements’ and whose success is defined by ‘delivery’ metrics, then the simple truth is your company isn’t realising it’s profit potential….
Who should be reading this article? Companies of all sizes, anyone looking to launch or grow products, anyone undergoing digital transformation and those passionate about effective product management.
Firstly, it’s worth clarifying, what I mean by requirements? For the purposes of this article I 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 adher to new regulatory needs, then well defined, strict requirements are important. However the same principles still apply.
So…
Why are requirements so bad for companies? 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 binary success metrics of on-time and on-budget delivery. Your organisation will not be agile or dynamic and most certinaly won’t be solving problems your customers want you to solve. More importantly, your learning and feedback loop will be glacial — you’ll 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 KPIs are going down, the feedback loop becomes a blame game and the requirements are then labelled as being ‘wrong’.
In this scenario there is far too much pressure on stakeholders, the voice of the customer is lost and the rate of learning is painfully slow…
So how do you fix this? You shift your company 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 for example, you are assuming that a 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 company 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 this week and switch the conversation to ‘what problems do we need to solve and what assumptions can we make about how to solve this problem’, then see for yourself how quickly it changes the dynamics of a conversation with stakeholders, engineers, designers etc…
One of my clients, a CTO of plc pushing a huge digital transformation program, said this about this switch of approach: “You gave me the confidence to go ahead and really push this change when you showed us that we’ve already failed if we’re spending our time gathering requirements from stakeholders”
By Lee Cross, MD & Founder at Skull Mountain
