I work in technology. My role, along with the entire technology organisation that I am part of, is to provide optimal solutions for the problems we have been asked to address.
Before I go any further, I will define what I mean by the terms ‘problem’ and ‘solution’. A quick disclaimer: these are my own, off-the-cuff, definitions, and are in the context of technology product management.
problem
noun
- an unwanted challenge to the customer that needs to be dealt with and overcome.
- a benefit or desire perceived by a customer segment that provides convenience, comfort, or prestige.
solution
noun
- a specific implementation to address a customer problem or achieve a customer benefit.
- Solutions to a ‘need to have’ problem are often referred to as a painkiller, while a solution to a ‘nice to have’ problem is analogous to a vitamin.
During the development of new or evolving software products, the following are examples of artefact types that are commonly used in software product development to articulate the problem and solution respectively.
| Problem space | Solution space |
| Business Requirements User Stories Use Cases User Needs Customer pain points and desires User Personas | Wireframes Functional specifications Prototypes Software solution architecture Business process model |
Define the Problem First!
The problem space needs to be explored, defined, and properly understood by the team before candidate solutions can be explored. At school, the teachers drilled into us that we needed to carefully read and understand the exam question before arriving attempting to solve it.
Regardless of what methodology is used, a solution cannot be solved without the problem being first known and understood. This statement is so very basic and obvious that you are probably wondering why I am even bothering to write it! All will become clear if you bear with me.
Problems polluted with solutions
When I started my career in software – when dinosaurs roamed the earth, I had received no training and all I wanted to do was to write code and learn how to be a better programmer; my focus was very much on technology, while I paid very little attention to the customers and their needs. I have observed the same tendency afflicting most teams in every organisation I have worked with since then. Technology teams tend to be plagued with a laser-like focus on the solution space. And frustratingly, even some team members, with decades of experience, who have the role of specifying the problem, appear to be mesmerised by the glamour and glory of the solution – to the extent that problem space artefacts, such as business requirements, are communicated as a weird farrago of user needs, technical design and even implementation detail! This confusing and unhelpful mixture of problem and solution statements is referred to as “solution pollution”.
Examples of solution pollution
Solution Pollution Version:
I can click on the ‘Play Song’ button to start the song
What’s wrong with it?
The use of the word ‘click’ implies that a mouse (or some other pointing device) is required – this is a facet of the solution. However, the requirement to play a song is likely to be equally valid for devices that aren’t connected to a mouse
A button is a UI component – this is a design and an implementation detail.
The inclusion of the words ‘Play Song’ implies that it must be written on the user interface – this is a user experience detail.
Other ways to initiate a song playing are implicitly omitted – such as voice command or gestures, although these may be better solutions
Pollution-Free Version:
I can instruct the selected music track to play
Why is this version an improvement?
It implies no design or implementation and therefore forces the team to collaborate and ask questions.
The target consumers of the solution are more likely to be considered and what options might work best for them because the solution has not been implied. The consequence of this is that customer’s experience is more likely to be a satisfying one.
Innovation is more likely as the team considers alternative options and collaboratively brainstorms what an optimal solution might be
Solution Pollution – what’s the big deal?
Not knowing what the actual problem is – the most important piece of information I need to be mindful of when working on a solution is the definition of the problem I am tasked with solving. In the same way that I need to read, and re-read an exam question as I am answering it, I need to continually focus on the problem in the course of addressing it.
If the requirements are muddled together with someone’s assumption about how the requirements must be solved, then those tasked with solving the problem have a choice:
- reject the requirements because they are not fit for purpose
- ask for the requirements to be stated in a way that does not imply a solution
- filter out the solution – either mentally or by restating the requirements themselves
- go along with aspects of the solution that is stated in the requirements
In my experience, 4) is usually the choice taken. Challenging a requirement can lead to friction with colleagues, and especially with project leads, who are keen to meet their milestones and may not be supportive of reopening discussions – this is especially true in waterfall projects – including those that are labelled as agile, but really aren’t.
Important requirements can be hidden or distorted by describing an implementation; describing an obvious implementation will stifle the team from working together to identify a better solution.
Innovation – to improve or maintain market share, organisations need to develop better products that differentiate themselves from the competition. Better products rely on innovation from empowered, collaborative teams. Collaborative teams rely on a clear definition of the problems they are tasked to solve – not product requirements that indicate how the solution must work! If the solution is stated in the requirements, the team is unlikely to feel empowered to come up with an alternative or to challenge the stated solution.
Cost and feasibility – a requirement that implies or explicitly states a solution may not be feasible to deliver within the budget and time constraints of a project. If NASA had a requirement such as “the pen must write in space”, it would have eliminated the pencil, cameras and voice recording as options. Alternatively, if the requirement was stated as “record information in space”, a wide range of viable options would have been identified to address the real need. The story goes that the Space Pen used by NASA cost more than US $1,000,000 to develop, meanwhile the Russians instead used the pencil!
User experience – if the requirements are polluted with aspects of the solution, the user experience may be artificially hampered. For example, if a requirement states “the customer needs to be emailed each time a payment is made from their account” then choices that could lead to a superior customer experience aren’t in the frame. Instead, if the requirement is expressed as “the customer needs to be notified of payments made from their account”, then a number of choices become available and assessments can occur to determine which one is optimal.
The consequences of teams honouring solutions that masquerade as requirements may lead the users of the solution to think that they are not properly considered, understood, or cared about. Would you use a product if it is clear that the team that designed it is not interested in caring about your needs?
Why does solution pollution happen?
The delivery team insist on it
The team responsible for designing and delivering the solution are sometimes fearful of ambiguity and the collective responsibility of shaping a solution that may not be accepted by the business stakeholders. Consequently, many teams insist on having design and implementation details included as part of requirements.
Business stakeholders knowing the answer
Over-eager business stakeholders may be keen on advocating a particular solution – this often happens if they have seen a competing solution in the marketplace that they would like to mimic or when they possess some technical knowledge. While solution ideas from everyone should be welcomed, they should not be mixed into the requirement.
Customers indicating what they want
Customers often provide feedback about new features that they want to materialise in forthcoming versions of products.
As Henry Ford may, or may not, have said: “If I had asked people what they wanted, they would have said faster horses.”
Instead, if we focus on the feedback “whys”, we are likely to reveal underlying goals and motivations that underpin the feedback. These “whys” reveal a fundamental problem (or problems) that needs to be addressed – and considering these instead is likely to lead to a wider range of solution options to choose from.
This may lead you to question: Shouldn’t the stakeholders specify a solution? The technology organisation is ultimately responsible for the solution they implement. Does that mean they must define this on their own, excluding other stakeholders, customers, or users? No! The technology organisation is not responsible for defining the problem, but they are not uniquely positioned to imagine every possible way of addressing the problem. While it is important that the solution and problem aren’t muddled together, stakeholders should feel empowered to provide solution ideas and to feel involved.
Bad habits
Companies are often guilty of unwittingly incubating bad practices – including organisations that are prevalent in the software industry. Junior colleagues are often mentored by more senior, experienced colleagues who have cultivated bad practices because they too followed the methods adopted by the herd.
Lack of exposure to good practices
Good learning courses, good books, good YouTube videos and good colleagues can mitigate the bad practices that can be observed around us. Good practices must be continually reinforced over a long period of time before they eventually stick – especially if they are reversing bad practices.
Design Constraints belong in the solution space
Design constraints that have been decided by an organisation need to be an input to the team who are designing and building the product. And occasionally the regulations of sectors – such as those in banking or pharmaceuticals may impose design constraints as well.
These constraints are still not requirements: they sit in the solution space because they limit, or even indicate, the solution options available.
Summary
Defining the problem facing users, customers and stakeholders is both liberating and empowering. It enables teams to work together to create solutions that are in the best interests of the users and other product stakeholders.
If you care about innovating to solve your customers’ problem; if you want to avoid wasting time building a solution that does answer the exam question, or if you care about simple, elegant, effective solutions that are both cost-effective and minimise effort, then please, please ensure you clearly define the problem first and clearly separate this from facets for the solution.