Breaking down complex problems

One of the least appreciated, but most critical, skills required in product development these days is the ability to break down complex problems into smaller, more manageable pieces.

As the industry moves from large build-it-all Waterfall releases to smaller, more iterative releases the ability to identify the underlying problem that you are trying to solve will be critical to designing simple and evolving solutions that can be tested and verified with your customers.

But this is really hard!

Please indulge me as we take a brief segue into biology. The eye is a marvel of complexity. It is composed of many different components that lead to the ability for us to see the world around us. And if we remove any of the components of the eye we won't be able to see at all - in other words, the eye will provide no value. For this reason, I think that the eye is a fantastic analogy for the way that we often feel that it is impossible to break down our product ideas into smaller pieces - remove any component and the solution provides no value.

It is true that you can't remove any of the components of the eye because each of the components works in harmony in the current structure. But the current structure of the eye isn't the only way to solve the underlying problem that an eye is trying to solve. To understand this we need to break down what the animal (customer) actually uses the eye to do or, put another way, what problems does an eye solve for a customer?

Eyes perform a few different functions. A simple list includes the following benefits:

1. Finding food
2. Avoid bumping into things
3. Identifying danger (avoiding becoming food)

We don't have to solve all of these problems to provide value. So let's see how we could break up the eye into iterative pieces

1. Plants grow in the sunshine so to find food the most basic requirement is just the ability to sense light.
   This will improve your chances of finding food but if you can move in a 3d space this simple solution will get awkward because sensing light doesn't necessarily tell you where the light is coming from.
2. By being able to sense the direction of light will save you time and reduce the trial and error approach for finding your food.
   But on your way to the food you might bump into a lot of things.
3. Seeing shapes would enable you to avoid bumping into things on your way to your food. It also means you can see things to eat instead of just relying on smell. But rudimentary shapes mean you might try to eat a rock as quickly as a tasty treat.
4. Being able to focus on objects means that you can distinguish between the tasty treat and the rock. It also lets you identify potentially dangerous items that might be interested in making you their food.
   But think of a camera with a fixed focus - you have to get close to objects to see them clearly and by then it might be too late.
5. Being able to shift your focus between near and far objects allows you to spot your food from far away as well as spot the danger before it gets too close as well.

This is exactly how the eye evolved in nature. Each step provided incrementally higher value than the previous steps. You could even go further than the human eye to eyes that include an even greater range of vision (such as an eagle), or eyes that enable more colour / UV detection (such as reindeer).

Back to Software

I like building things. A lot of people in product development do. We hear a problem and we instantly start thinking about solutions. We then spend time digging deeper into the problem and we increase the complexity of our solution to handle each of the newly identified edge cases. In the end, we have a solution as complex as the full-featured eye.  This is how we naturally attack problems.

We need to change.

We can't afford to build a complex solution to figure out at the end that the customer doesn't really want it.

But the counter-argument is if we don't plan out all of the bits upfront we will end up having to do a lot of re-work which will increase the total cost of the final solution.

This counter-argument assumes that we can know what to build upfront which, as history has taught us, is wrong. We always have to change our original design either because of missed requirements, change requests or new features that are requested after the initial build. Since change is a given the best thing we can do is architect our solution to enable change. While this isn't easy there are patterns that companies are adopting to enable easier evolution of solutions.

How do we break down a complex problem?

Start with the customer problem.

Then map the customer's journey through your product that will allow them to solve their problem. Start really high level. If you are an e-commerce platform it could be something simple like:

Identify Need -> Search -> Add to Cart -> Pay -> Receive -> Solve Problem

The next step is to flesh out all of the key features under each heading that you need to offer to solve the problem for the customer (I say need because everything seems mandatory at the start).

Now we get the challenging part - step back and validate your assumptions about why these features will solve the problem that you identified for the customer.

• How will you know that the need is being met?
• What is the simplest (maybe, not even software related) way to validate that your assumption is correct?

You're not trying to solve the customer's problem just yet - your first task is to validate if your assumption is valid. This will take practice, and should be done as a team sport.

Once you have identified the absolute minimum you can do to test your assumption draw a line under your customer journey and just include the identified items within this first row. Side note: Don't think of this as an MVP - this should be much, much smaller than an MVP. This should be an earliest testable product. Light sensing cells seem comically simple when you want an eye but demonstrating them to a customer will provide you with valuable information about your customers' true needs.

I find it useful to go to about three rows down as I always feel really uncomfortable with the first row, there are pieces that you really want to add and its fresh in your head. But you should have the bulk of your ideas in the last section at the bottom.

After you have tested and validated the first release you will make changes to the subsequent releases. That's why you shouldn't spend too much time planning when to release each feature - it will be wasted effort.

This map can then be used to educate the team and external stakeholders on the customer problem, the feature that you are developing to solve the problem and the iterative steps that you will perform to validate if it is going to work.

What I've described above is a simplified version of Jeff Patton's User Story Mapping. Although Jeff calls this a pattern, rather than a framework because he's talked to many people who independently came up with the same approach. I think the reason why it is so universal is because many teams struggle with managing both the big-picture view of the direction that they want to go in while simultaneously focusing on the detail of validating the key assumptions. Give it a try and see what value you can get from it.  

Good luck with your mapping. As always, I'm eager to learn what works and what doesn't for you so please let me know in the comments below or reach out on twitter @roryuxdx