For most Product Managers, when you come into a company, you are asked to research the Market and identify problems that can be solved within the scope of your company’s products. There is another 800lb. gorilla that is easy to overlook – the existing products you will be asked to take over and manage. These products could be in any state – maybe there was a PM there before you that was actively managing the product, or, maybe it was a big company that had let the product grow stagnant and wasn’t actively managing it anymore. Or maybe you stepped into a startup and are bringing PM processes into the company for the first time, making the transition from “cool technology” to “solves a necessary problem.”
I recently came to a startup, and like all startups we are overloaded. There are a ton of problems we have found, and our job is not in solving them all but deciding which to solve and in what order. We are also in the process of moving from founder/engineer-driven to market(ing)-driven. Some big products we have in the pipeline have been under development for a long time, and the assumption is that they will help us drive into new market areas we don’t cover today. Unfortunately, when we started looking at launching the product, we had to ask ourselves: “Now, what problem does this solve?” Oops.
As I look back, I should have seen this coming. The product does not have a MRD to memorialize its requirements; the most documentation it had was a set of executive level conversations and a 2-page memo outlining the key features. In retrospect, that was a red flag. Being new, it was easy to let the product already “in development” float along, while my team and I researched new problems and wrote new MRDs. If I could go back in time, I would stick my nose into the product earlier and test some of the assumptions. The product will still be a hit, but now our paranoia over the problem it will solve will force us to market it with a sniper rifle approach to certain target applications as opposed to a broad shotgun approach to the entire market. I believe this is better anyway, you’re more likely to take down deals with a specific focus and it will allow us to train our sales team on specifics, it just would have been better to get there intentionally.
What problem does this solve needs to be answered before development begins. Right now we have a cool technology that is a solution in search of a problem. Thankfully, it is a cool technology and it will solve a compelling problem for parts of our target market, maybe not exactly what we expected. There is added risk in this approach. We have time to pivot and get it right, and I am sure we will because my VP and our executive team recognize the issue. If our executives were in the weeds of the technology, we might be on a path to failure, since people in the “transistors and RAM” usually want to focus on how to solve interesting technical challenges, does it do something for the customer is not a concern – “Of course the customers will want this – I need this feature for my [house, application, desktop, etc].”
The lesson I take from this is that it is easy (and seducing!) to focus on new problems and products when you start with a new company. Challenging assumptions made about products in the pipeline is hard and sets up conflict with the people you’re trying to forge working relationships with right off the bat…but it is also critical. Rise to the challenge and your company and products will reap the benefits.