7 Steps for Breaking Down Complex Problems
Product problems come in all shapes and sizes. No… really they do. I’ve found that problems are bigger in size relative to the obstacles in front of you as a product manager. Throughout your career you’ll run into resource constraints, operational limitations, wide-ranging use cases, and/or your own solutions coming back to bite you.
By now you know all too well that your job is to make decisions with scarce resources. So when a problem is so big it looks like you’re going to have to make significant changes, how do you begin to problem solve?
1. Start With the Who, What & Why
I’ve found time and time again that the best place to start is outlining who you’re solving for, what the problem is and why these users are running into the problem.
This is the first step in building out project documentation that will guide the solution-ing process. By documenting these main points you can easily align your team around focusing on the core issue the main customer is having.
2. Collect Qualitative & Quantitative Data
You’ve identified your problem, now it’s time to research the ins and outs. During the outlining process, you probably asked yourself questions about the problem. This is where you begin to fill in the details.
Jot down the unknowns in your documentation and then categorize them as quantitative or qualitative. You can immediately dive into finding answers to your quantitative unknowns by analyzing historical data. For qualitative unknowns, you’ll want to structure user interviews that will lead to the answers for your qualitative unknowns.
This part of the process is extremely important because it will help you determine how to measure the success of your solution. At this point, you’ll want to come up with some benchmarks to measure against and establish the goals of the project.
3. Brainstorm With the Team
You have your case built out for what the problem is, who it’s impacting and why it’s important. Always start your brainstorming meeting by laying this information out so the team can be focused in solution-ing.
Our team typically allocates 15–20 minutes for thinking through the problem and jotting down ideas. White-boarding is best for this exercise so team members can write or draw out their thoughts. For remote teams, I recommend using Invision Freehand or Figma to ensure everyone is able to see what’s being added to the board.
After everyone has had time to think through the problem give each person 3–5 minutes to go over their solution. Discussing everyones perspectives is a great way to think through edge cases and come up with the best solution.
A last optional step, vote on ideas and discuss what the best solution seems to be. Inevitably, you’ll run into more edge cases and blockers. Now it’s time to start designing.
4. Start Designing
Now that we have team alignment, we can move on to the design phase. Taking the solution developed during the brainstorm, the designer and Product Manager collaborate to come up with the optimal user experience.
Once an initial design is ready, we pull in the tech lead for a design review and make tweaks as needed.
5. Conduct a Usability Test
Time to test our design with users! An easy way to test your solution without having to build is to ask users to review your design. This is a great practice because users will say one thing in an interview and then behave completely different in your product.
Putting the design in front of the user will provoke them to really think about what they want. This is where you’ll get more tidbits that help you determine if you’re building the right thing.
6. Review the Scope
One last step before building! It’s time to get product, design and engineering back together to review what we’re actually going to build and how we’re going to release it.
Go through the final design and discuss the effort behind the project. Be ready to make compromises; resources are scarce! You’ll end up cutting scope inevitably to save dev time. The goal is to deliver value without spending more time than necessary on a singular project.
7. Build, Measure, Learn
Time to put all your work thus far to the test. By now you have broken down the project into milestones, determined the order of cards for implementation, and set expectations for how you’ll release.
Ideally you can release iteratively so you can measure the user behavior to see if your solution is working. If you can conclusively determine the initial features are not being used, it’s best to try to understand why so you don’t continue spending time on a project that isn’t successful.
