Are you on the right path?

Think about a problem that you and your team recently solved. Not a problem that only took minutes to solve, or one that even the lowest skilled team member can complete without thinking about it. I'm talking about a tough problem. One that took real thought, real work, real effort. A problem that when you and the team reflect on it there is a consensus that the team grew from solving this problem.

First, let's quickly reflect on this problem and its solution. How did it feel when you and the team knew you all were going to be taking the problem on? How did it feel in the thick of the solution, when things were not going so well? How did it feel when the solution was emerging? Lastly, how did it feel when the last check was in the box and the problem was solved? Lastly, what made the problem hard to solve?

As professional problem-solvers, we go through this cycle of feelings quite often. When the problem statement is understood by the team, the more experienced team members typically have a general sense of what a solution may look like. Or they are confident that the problem can be solved. But, as the team begins working on the problem how do they know if they are on the right path? How do they know they are not walking right into a big mistake? What if I told you there is a way to test which path the team is on. Would you believe it?

What if you and the team were to take the example problem and break it down into smaller, more manageable problems. Each of which could be solved independently of each other. Would this approach have made the solution easier to come to? This seems like the obvious answer, which most good teams do. Those teams know that large complex problems are too complicated to solve in one fell swoop. But, is this plan of attack enough to identify whether or not the team is on the right track? NOPE! So now the team is solving a smaller, albeit easier problem. The solution to this problem may be way off the necessary path to the full solution.

If the team was to slice the problem into 2 dimensions. So we keep the large problem broken down into smaller pieces. For each of the smaller problems solve only what is necessary to test a hypothesis. The sooner the hypothesis can be confirmed, the sooner the team can move on to solving the next smaller problem. No more time should be spent on these smaller problems during this period in the project. The next smaller problem to tackle is the one adjacent just completed. Once this smaller problem's hypothesis has been confirmed it is time to test the sub-system of these solutions together. Eventually, the team will have worked through each of the smaller problems resulting in an MVP of the complete solution.

As a team works through the problem in this manner they are exposed to several learnings. First, the team is validating their hypothesis resulting in a working solution. While the solution may not meet all the business criteria necessary initially. The general structure of the solution exists for the addition of the edge cases that are required to handle. The team is not wasting time trying to solve all the edge cases for a smaller problem that has the potential to be all wasted time and effort if the smaller problem being solved is off the path of the complete solution.