PF#59: Solving Complex Problems

Often simple solutions are the best approach to complex problems

Thanks for reading this edition of the ProductFix newsletter. If you find it helpful please subscribe and share.

---

My inspiration this week comes from a tweet and reply on how to tackle complex problems.

Bryan Liles @bryanl

We have hard problems. We hire senior engineers. They create complex solutions. We have complex problems. We hire ???

Kostadis Roussos Social Distancing Trainee @kostadis_tech

@bryanl Complex problems require complex solutions. The notion of simple solutions to complex problems is a particular mathematical fascination.

I have frequently witnessed a bias among product teams that upon learning about a complex problem they seek to solve it head on. Kind of like @kostadis_tech reply tweet above.

From a product management statement this is almost always the wrong approach. Why? Because solving for all the complexity of a given problem is not good business. It tends to over-emphasize edge cases and misses the forest for the trees.

If we don’t solve a complex problem with a complex solution, then how do we address it? Here are the four options that like to consider.

Often complex problems have multiple solution options.

1. Ignore the problem.

2. Reframe the problem.

3. Approximate a solution.

4. Incrementally attack the problem.

---

1. Ignore the Problem

I know this is the least comfortable option for most development teams to consider. However, if you have been in the trenches long enough you will find that some complex problems vanish on their own over time.

One scenario I have seen repeatedly over time is landing a big new customer that has some “deal breaker” requirements. Far too big for you to tackle in the next few weeks or months but important enough that the customer wants you to commit to putting it on the long term roadmap or no deal.

This is not necessarily a technically challenging problem but it is complex to the business. Do you go after that whale? What about the other big accounts you just made commitments to? What about the other 80% of your business that don’t care about these extreme enterprise asks? You have lots of variables and no good way to fully assess the costs and risks relative to the opportunity.

You know that this is not part of your current strategy. Yet, in the chase for revenue and new marquee logos, you agree to put it on the plan with every intention of eventually working it in.

18 months later, the executive sponsor at that customer has been promoted and nobody left in the organization remembers the commitment. The customer is happy and giving references.

We can argue if this was ignoring the problem or just “waiting it out” but time and time again I have seen this type of complex problem evaporate over time.

The point here is not to ignore all complex long-term commitments. Instead, it is to ensure you don’t over think them as a default response.

2. Reframe the Problem

This is where you earn your pay as a product manager. While you can leverage the cross functional product team in reframing a problem, often you are the one bringing the problem to the team.

You may not even realize the technical or logical complexity of the problem that you determined to be a priority. Yet, here the team comes to the initial conclusion that it will be extremely challenging to solve the problem. At this point, many product teams start digging in to solve it.

As the PM, it is your job to ensure the problem is looked at from many directions. This is the root of “5 Why’s”. It is also exemplified by the slow Elevator Problem, where the innovative solution could only be discovered when it was realized that the slow elevators were not the problem, but people being bored waiting for them was.

Many complex problems can also be tackled by first reframing.

3. Approximate a Solution

One complex challenge that I have encountered in multiple enterprise applications is around authorizations. As your product gets used by larger and more sophisticated enterprises they continue to pile edge case scenarios to be covered.

What I have learned from analyzing these problems at length and implementing very sophisticated role based authorization mechanisms to address the 99.9% situations is that it is not necessary. In the vast majority of cases, a solution design that would have solved for 75% of *possible* cases would have been sufficient for 99% of my customers. That last 25% of possible needs are usually the hardest to solve for.

Importantly, those sophisticated permissions are harder to maintain, harder to test, harder to integrate with other enterprise auth systems, and are harder to train people to use.

Bottom line, approximating a good enough solution is frequently the superior product decision.

4. Incrementally Attack the Problem

Finally, at times, we have no choice but to tackle a complex problem head on. When we do, we should be using an incremental approach to build, measure, and learn as we go.

By their nature, complex problems have many moving parts and multiple possible “right” answers. By incrementally attacking these problems, you give yourself the opportunity to reassess continually as to what to do next.

Sometimes it will be to continue building out the requisite complex solution with adjustments based on feedback — but other times you may find an opportunity to short circuit the process with one of the short cut alternatives I have previously laid out.

Conclusion

All complex problems do not require a complex solution.