Building the right problem statement is key to solving a problem. Alongside this, how confident you are about what the problem is has a direct impact on the quality and agility of your solution. It’s crucial to develop a problem solving mindset that utilizes past learnings to make the most accurate decision about the future.
When faced with a new problem, do your best to approach it objectively. Try to remain calm and apply your best problem framing and solving techniques. However, the most important part is what occurs after. You should conduct a post-mortem of your process and outcomes so that you can continuously improve and learn from your mistakes.
Think of yourself analogous to a product that’s going through constant A/B testing and extrapolate learnings from both successes and failures. You’ll learn either way. From these you can decide whether you want to iterate, exploit, or abandon the path you have taken.
The three most important questions
There are three questions you should always ask regardless of whether you fail or succeed in solving the problem: What went well, what did not, and what could’ve been improved?
Answer these questions objectively and in simple straight-forward language. Simplicity helps in understanding across cross-functional teams, both upwards and downwards. Additionally, it drives quicker alignment and collective thinking towards future action. Doing this as a collective rather than individually is a much better idea than being reserved about this.
If you succeed, the answers may improve the fungibility or time. You may also hear what people think worked to get a better sense of your team’s strength.
On the other hand, solutions can fail for multiple reasons. It could be just because the problem statement was not articulated properly. It might also mean that you were actually trying to solve a business problem in the garb of a user problem. For example, if the business needs to sell more items through their app it doesn’t mean users want to experience the app more.
The most important thing to remember here is that solutions fail and they tend to fail for three key factors that one should be aware of:
- Strategy — Your initiatives may fail right at the beginning if your strategy is weak. The WHY part of your task isn’t clear and you have jumped into design and execution
- Execution — You have a great articulation of the WHY but the execution is sloppy. Maybe design didn’t have enough time to user test or QA didn’t have enough time to test all use cases
- Communication — I can’t stress enough how important this section is. Are you communicating your problem statement enough, are you working together, and are you keeping your stakeholders updated on the status and bringing them together?
Next time you can tackle these beforehand by plugging the fool-proof mechanism within your solution
You succeeded, now what?
It’s important to conduct a post-mortem of the solution even if you succeeded. As I shared earlier in the article, identifying patterns, your skill sets and strengths, and building collective credibility helps you repeat this success in future. Communicate learnings so others can utilize your findings to collectively build better products in the first place.
In both cases building mental models and work-flows is a fool-proof idea to codify your experience and make it more meaningful and valuable for you, your team, and your company.
Build mental models to learn from your experience
Reflections drive growth because they help you identify patterns, make your observation skills more potent, and help in building mental models for reference over time. Once you have these mental models you can use them to help guide your team. The three key steps in building mental models are as follows:
- The tell-tales signs — There are always some early indicators of a problem. Retrospectively, if you can find the patterns, you can create a repository of such indicators. This will bolster your thinking on identifying the signs of an emerging problem
- Know the box — Categorize the problem into a type of business function. It helps to apply an existing model or work-flow or a few elements easily if you know the category. Conversely, if it’s a new problem, you can give yourself more time to work on it since you’ve identified a knowledge gap
- Measure the intensity — Measure the problem based on a risk and impact matrix, write down each detail objectively, and then based on impact (high-medium-low) choose which one to prioritize
Once your mental model or work-flow is ready, test it out when you land in a similar situation. Use your codified experience to tackle the issue at hand. See what customizations or major changes you have to make.
This will definitely improve the work-flow/model and it’ll test the resilience of the solution!
Final thoughts
Remember to be kind to yourself. Failing to solve a problem is okay and you should take it in stride as learning for the next time. Don’t beat yourself up. It’s much more meaningful to focus on learning opportunities instead.
You’ll also see your team members, add valuable contributions to these models/frames. And if you come across a problem you’ve never seen before, it’s just a reminder that no one ever knows everything. Do your best and then see what you can adapt for the future.
Featured image source: IconScout
The post The best ways to learn from experience appeared first on LogRocket Blog.