Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery. 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.
Good article. In line with the problem-vision is a systems approach. Quite often, a more successful solution is found if looking at all the components that are involved, rather than just one or two.
Teresa, I really like the thought and agree that you are limited by focusing only on the solution, but I’m not convinced that stating only the problem equates to a product “vision.” For your example I would want my vision to include something like “Help occasional riders have a seamless Caltrain experience, by understanding and implementating methods of communication or tools that meet the demographics of the occasional rider.” by expanding slightly your pinpointing that you need to do something to help the problem. if expanded slightly more I would add a benefit statement such as “in order make Caltrain more user friendly and reduce the Carbon Footprint of the bay area”
Tracy, I agree that a vision statement should include more. I like the addition of a benefit. I originally wanted to expand the vision to:
Help occasional riders have a seamless Caltrain experience in order to help grow Caltrain ridership.
It gets at the “why”. But this opens up a whole new question of vision scope, which I’ll tackle in a future post. For now, I really just wanted to focus on avoiding specific solutions in the vision, so that it doesn’t blind you to alternatives.
Hmm, I have a hammer. That problem is starting to look very nail-like.
Hi Teresa, Happy New Year.
Browsing around I came across your post which is a topic close to my heart. I am keen on process to provide an environment to deal with this type of problem and guide product designers irrespective of skill level. We use this across the team and it has also been published in a journal called “The Ergonomist” in the UK. You are quite right, the real goal of the user must be placed at the heart of the design activity, sometimes this can be tough for a user to identify, but that is part of the skill of the product /marketeer to understand the real need, the pains and then move on to the “stories” that will meet that need. Only once all the stories for different stages of future experience are defined, should any thought be made to how technically this may be implemented either using planes, trains and automobiles or more humble software based products which is my background.
I hope you find the article and the template at the end useful
http://bestpracticebank.com/2010/07/user-story-grids/
regards, alan
Thanks, Alan! Great template!