Thursday, July 08, 2010

Picking the right problem

Nowadays, software can be updated continuously and iteratively. This lets us build what we often call minimum viable product, or MVP, and improve it from there. However, most of us don't end up building MVP despite best intentions. 

The reasons are varied, from fear of negative feedback, not knowing what MVP really looks like, or thinking that your early customers want more than they actually do. The first problem founders-to-be come across when doing MVP is actually picking the scope for the problem.

When you're first building a product, you spend time thinking about what features should be included and what the benefits would be to the end-user. Then you start thinking of all the things that a user might need before they start using it. The vision for your product is big and could go in any number of directions. The opportunity and potential may be huge!

I think this is the wrong way to go about it. Before you start thinking about all that, you need pick one problem to focus on. This problem is what you're going learn whether people even want this problem solved.

But even when you find a problem that people want solved, the next most common pitfall is picking the wrong size of problem to work on. We often try to solve a version of the problem that's too big. Don't try save the world on first shot. If you can subdivide the problem into smaller problems, if it's a problem to different types of people, or solves related problems in different contexts, your problem is too large.

The advantages of picking the right, focused problem are many. It makes the product easy enough to do, it's tractable, and you can see an end in sight--which is extremely motivating. In addition, it's easy to explain to others. Don't underestimate the power that stems from the ease of conveying your idea and the problem it's trying to solve.

Don't worry about the problem being too shallow. All problems are interesting when you look deep enough. 

Paypal on the surface seems easy enough in the beginning. It's like a web-bank that only does transfers, and you don't even need to connect to financial institutions for paypal to paypal transactions. But what people don't realize in trying to copy paypal is that fraud will increase the more popular your service gets, and that will eventually kill you unless you get it under control. 

Twitter seemed easy enough as well in the beginning. Search the web and you'll read a lot of naysayers back in 2006-2008 where they can't understand why posting a message to the web generates so many fail whales. By nature of the interconnectedness of the data in producing the feeds for a given user with a specific set of followers, it's actually a non-trivial problem.

Groupon has been interesting because it changed how people thought of the intersection between local businesses and online ecommerce. With groupon, you go into group buying agreements with other strangers on the web to get deals. However, it's actually a small part of a larger set of problems that you could solve with a similar set of mechanics, such as group campaigning and petitioning. Instead of trying to solve all these problems, the founder decided to just focus on one: group buying.

And even if you pick the wrong problem type or size, you can always iterate. There will always be more potential users to ask whether they have this particular problem. There will always be a myriad of interesting problems centered around human needs and wants. There's no bank account that you're withdrawing from when you ask people about whether they have a particular problem, as the world likes nothing better than people that are looking to solve their problems.

Posted via email from The Web and all that Jazz

No comments:

Post a Comment