When I approach a new product problem, after I’ve interacted with users, dug into the data, researched the market, and built a clear problem statement, I've found it incredibly valuable to set aside time to look for analogies.
Studying your competition can be quite valuable, but that's not what I mean in this case. I'm talking about researching analogous problems in other fields that have already been solved (or have failed to be solved) by companies in those markets.
In my experience, these analogies are hugely beneficial for two primary purposes: storytelling and solution design.
Analogies should always take a back seat to a clear, compelling, empathy-inducing problem statement, but as a product manager pitching or explaining the problem you're solving, analogies can be powerful frames of reference for others. This can be true in a wide variety of situations such as:
Pitching your work to executives, investors, managers.
Getting buy-in from non-product groups who may be necessary to fully solve your problem statement or are impacted by the solution.
Building excitement in the product, engineering, design teams who will be working on this problem.
Analogies have the potential to be either beneficial or detrimental to solution design. It’s important to make it clear to your product team that the analogy is not the solution but a jump-start for the solution design process. Without calling that out up front, analogies can stifle creativity and put the team in a copying mindset. When used correctly, analogies will provide the product team with a launching point for conversation and permission to think outside the box.