Ideas are an interesting beast - we tend to get attached to them as if they are the lifeblood of what we’re doing. It’s especially common in the world of product management - way too often PMs tend to think that the most important part of the job is to come up with great ideas, implement them, and see the product shine. I thought so too when I was first starting out - the onus was on me to come up with the right solution as the driver behind a feature or product segment. This creates a disproportional amount of pressure on the PM thinking that way - stress, time spent riffing on things that can be spent doing research or having more productive conversations, all of this eats away at one’s ability to deliver truly impactful customer solutions.
The reality diverges quite a bit from the original statement - the job of a PM is not to come up with the best ideas, but rather find the best ideas for the product they are working on. Those can be sourced from many channels - peers, customers, existing research, Twitter, you name it. Whatever works best in your field. It doesn’t need to be you who comes up with a solution to everything. As I internalized that in my second year on the job, it felt incredibly liberating - instead of spending hours trying to draw out product plans that may or may not resonate with my target audience and the engineering team, I could instead spend that time talking to some designers and UX researchers about what we can do better to serve the customer.
To an extent, that just ties into the broader concept of a successful PM never doing it solo - you need a crew to scale, and your crew is not there just to help you make the vision a reality, but also to help you flesh that vision out.
To give you an example, the .NET API Browser, the tool we use on docs.microsoft.com to discover .NET-based APIs was the product of ideation between many people, but the core concept was put forth by Mike Sampson, our brilliant service engineer, and Immo Landwerth, a PM on the .NET team who previously built APIs of .NET. We were looking at the best way to structure the table of contents for .NET APIs in a way that allows discovery of other APIs, and it seemed like we couldn’t easily do that within the existing constraints of the DocFX table of contents model. Despite the fact that I was the PM on that project, it was not my idea that was used as the solution - and we ended up building something that customers love!
Here is an even more counterintuitive discovery - the more one talks to other people and aggregates ideas, the better ideas they will start developing themselves. My former manager referred to this phenomenon as “developing a spidey-sense” - your intuition. Realistically, you will rarely be smarter than the collective mind of many people, so the more you learn from them (and by “them”, I refer to both your team and customers) through ideation, iteration and delivery, the more you start building a better understanding of what customers are truly after.
The lesson is this - stop caring about who comes up with the best ideas and start focusing on delivering value through shipping the right things to the customers. Whether it’s your engineer or customer who bring up a concept - it doesn’t matter, as long as that helps the broader audience solve a problem.