In defense of sometimes starting with solutions

Digital product teams really don’t like it when the final output of the thing they’re working on is dictated to them. They prefer be given a problem to solve, and agency to work out the best way to solve it. This is right: organising your teams around outcomes, not outputs, gives better results.

Starting with an output can lead to teams going around in circles, because they don’t know who they’re meant to be helping or the problem they’re trying to solve. It can also close teams off to new ways of solving problems that they wouldn’t have spotted before starting to play with it.

But to make new work happen in an organisation, and to get a team behind it, I think you need to adopt a more nuanced approach, and recognise that the relationship between ‘problems’ and ‘solutions’ is a lot more intertwined.

Let’s say are trying to make a new piece of work happen, and have identified a problem that you think you can solve. Without a clear idea of how you’re going to solve that problem and how realistic it is for you to do that, nobody’s going to fund it. And rightly so: you need an idea of whether a specific problem can be solved within the parameters you’re working with (funding, technology, or else).

You can’t build a case for work purely on “we will follow a user-centred discovery process to see if there’s anything here”. The sooner you can demonstrate the value you’re going to add to users, and the specific way in which you might do that, the better. From day one, talk about what it might look like to get people behind it. Draw a picture! You have to caveat it, all the time, but you can’t just leave that stuff for later.

Then, let’s say you are trying to talk to the team about the work.

Show them what good looks like, and explain how you want them to approach it. Some problems are high-certainty, and can be solved with commodities; others are completely uncharted. Sometimes it’s useful to spend months exploring the possibilities and learning about your users, sometimes you’re pretty sure what the solution could be. Be clear on what kind of work you are starting.

Alignment on a new piece of work can take a long time: people hold a different idea of what the work and it’s all a bit foggy. Having a picture of potential solutions, early, can fast-track it.

You’re unlikely to achieve much without deeply understanding your users, but I don’t think doing that and playing with solutions has to be a sequential process. I’ve seen provocatypes (sorry) get amazing results in discoveries, both to speed up learning and to demystify the work. Hold multiple ideas of what the final thing might look like, constantly talk about them, but hold to them loosely.

‘Solutionising’ or ‘prototyping in discovery’ or ‘jumping to solutions’ get such a bad rep, but I’ve seen this stuff really slow down progress. As designers, I think we need to be as comfortable talking about solutions as we are about problems. 🌶️