Product Managers Don’t Need Luck, Just Good Timing

What I’ve noticed in my years as a product manager, is that many products are actually solutions looking for a problem. And many of those products think they know what’s better for your users than your users themselves.

Let’s think about the risky decision Foursquare made when they split their highly successful app down in to two products, Swarm and Foursquare. What was the problem being solved by this split? Foursquare made the assumption that they knew what their users wanted, but since the split and relaunch, the apps have both declined in popularity. When you design a solution without a problem, you will either find a niche place in the market and succeed or more likely, you will fail.

A good product manager identifies real-world problems first and minimizes such risks by relentlessly asking one question: What problem are we trying to solve?

Be the conductor

Marty Cagan and other leaders in our field often relate the role of product manager to being like an orchestra conductor. Like the conductor, the product manager doesn’t build the actual product, but they get to pick the music, set the tempo and direct the orchestra.

Just like a conductor, the product manager gets facetime with everyone by sitting at the intersection between the customer, the business and technology. It’s all eyes on the PM to set the vision for the product and keep the players in sync.

But the conductor needs to keep that one question in mind: What problem are we trying to solve? Other core questions to ask:

• Is this problem worth solving?
• Is the time right?
• Can it be done at the right price?

If the answer isn’t ‘yes’ to all of the above then it’s not time to build this product. And in product, timing is absolutely critical. Think about the Tesla Energy Powerwall. Three years ago, it wasn’t viable. The market wasn’t there and neither was the technology. However, fast forward a few years and both both demand and infrastructure are ready and willing to accommodate this product.

Timing is important, but it isn’t everything

Problems don’t exist in isolation. They exist in an environment that you need to understand first. There are some fundamental questions that need to be asked so you can understand the context of the problem, and as product manager, you get to lead the organisation to investigate for everybody:

• Where does the problem occur? It might be at the office, at home, during the commute, on a farm, or in the city.
• When does it occur? Morning? Afternoon? Evening after a few drinks?
• Who does it occur for? Parents with four children under the age of 3, commuters, or perhaps it’s subsistence farmers.

The context not only helps us to better understand the problem but also allows you to begin forming the basis of user personas. More importantly, it helps you start to set constraints on what the solutions are going to look like. For instance, it wouldn’t make sense to build an app that requires a credit card when the users facing the problem that you are solving with the app don’t even have bank accounts.

I’ll be talking about the next part of the product management process in my next post. In the meantime I’d love to hear what you think makes good product management practice. Can you think of any other products that are solutions, rather than ones that solve real-world problems? Let me know in the comments.