Generating Problem Statements as Part of the Design Process

Problem

"At my previous job, as the company began to grow, so did the backlog of things that we wanted to be building. Whether they came in the form of feature requests or solutions, we found ourselves pretty deep in the weeds discussing the pros and scoring individual solutions, all while trying to stack them. This approach continuously led to a dead end conversation because we lost track of the problems that we were trying to solve in the first place."

Actions taken

• "I have found it useful to reposition the conversation to be about the problem statement. Recognize that there is indeed a list of features and stories that can be built, but push increasingly towards the talk concerning the problems that you should be solving instead."
• "Take time to come up with really succinct and thoughtful problem statements. Then, try to assign impact and confidence scores to the individual problem statements."

Lessons learned

• "There are a few symptoms of the solution-based approach not being as productive. Consider the following two scenarios:"
• "You may find yourself in design reviews talking about a specific feature that a designer has brought to the table for feedback. Usually, if you do not have a lens through which to give the feedback, you end up giving a lot of feedback that is perceived as unhelpful. If you want to be a helpful collaborator who gives valued feedback, try to ask what the problem was when you first set out to try to solve the design. From there, you can then look at the designs and tie your feedback to the problem statement. If you do not have a problem statement to fall back on, you can easily get lost in the conversation, nitpicking the details of the design, all while losing track of what the problem is for the customer."
• "Another symptom that is inevitable when you do planning and create roadmaps is that there is a certain amount of upfront buy-in that you want to get from management. I have a fairly large team and you could argue that every piece of work we do is an investment of company money. Getting executive buy in on where you are going to place bets for the next year or so becomes an easier conversation to have if you can tie it back to the problems that you will be prioritizing to solve. In that way, you can demonstrate that you're investing money into either solving or making progress on the highest priority problems. This is much better than having a bunch of features to show that you plan to ship in the next few months."
• "Overall, I believe organizations that emphasize clear problem statements at the beginning of the design process will have much smoother design reviews with more reasonable discussion."
• "Assigning impact and confidence scores to problem statements is a very useful way to align management and stakeholders. It illustrates the most important problems that we should be thinking about solving rather than what specific projects we should be taking on or solutions we should be building."
• "Identifying the problems that should be solved has the benefit of making a creative space for the individual teams and squads that are responsible for actually solving them. They can deep dive into them and come up with their own unique solutions that are based on the actual problems and not the pre-prescribed solutions."