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.
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:
Next time you can tackle these beforehand by plugging the fool-proof mechanism within your solution
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.
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:
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!
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
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
As a product manager, you express customer needs to your development teams so that you can work together to build the best possible solution.
Karen Letendre talks about how she helps her team advance in their careers via mentorship, upskilling programs, and more.
An IPT isn’t just another team; it’s a strategic approach that breaks down unnecessary communication blockades for open communication.
Learn more →
