More often than not, I see product managers frame their product vision as a solution – sometimes even as a solution without a clear problem. In some cases, this happens because the product manager hasn’t clearly identified a suitable problem. But other times the product managers have done their homework and are tackling an important problem, but they are so focused on their solution they begin to mix the two. This can be limiting, particularly when things don’t go as planned.
To illustrate this I’ll continue working with my Caltrain mobile application example from an earlier post. To quickly review, Caltrain is a train service that runs from San Jose to San Francisco. Riders generally fall into one of two categories: daily commuters and occasional riders. The system is not particularly user-friendly and occasional riders often run into problems when trying to pay for parking, buy tickets, and figure out which platform to use.
Using this example, suppose I stated my product vision as follows:
Connect occasional riders with train schedules, ticket buying information and parking information via a mobile app.
This vision statement accurately captures my current view of the situation. But it’s not flexible enough to account for something going wrong. For example, what happens if I learn that occasional riders won’t rely on a mobile app for this situation? Or suppose I discover that train schedules don’t actually help occasional riders? This vision statement is centered around my current solution. If my current solution is wrong, I don’t have much room to explore other options.
In fact, by framing my product vision this way, I’m going to be more likely to solve my usage problems within this context. Rather than questioning whether or not a mobile app is the right approach, I’m more likely to tinker with the app itself to try to grow usage. Context matters. My view of how to fix the usage problems is going to be constrained by how I’ve framed my product vision. If I’m set on delivering a mobile app, that’s the world within which I am going to work, whether it’s the right answer or not.
However, look at what happens if I state my product vision as follows:
Help occasional riders have a seamless Caltrain experience
Rather than focusing on a specific solution, this statement captures the problem I am trying to solve. I might still solve this problem with a mobile app, but if I later learn that occasional riders won’t use a mobile app, I haven’t hit a dead end. I can simply look for a different solution. In this case, the context from which I’m working is the problem that I am trying to solve.
By framing my product vision as a specific problem rather than a specific solution, I have the freedom to explore many different types of solutions. This is important. Odds are your first solution isn’t going to work quite right. But if you have the freedom to explore multiple solutions this won’t matter. Your vision statement gives you the freedom to keep trying rather than hitting a dead end.
Don’t let your product vision limit you. Frame it in the context of an actual problem. It will help you stay focused on the problem itself and you’ll be less attached to specific solutions when they don’t work out.