Monday, January 30, 2012

Stop Validating Your Product

I talk to a lot of very small companies that are trying to do Customer Development, and the conversations are often the same. The entrepreneur explains that the company is working on a fabulous product, and they want to figure out a) if anybody wants to buy the product and b) if they need to change anything about the product so that more people will buy it.

The entrepreneurs always ask questions like, “How will I know if I have talked to enough people?” and “How do I know if the people who like it are just early adopters?” and “How do I know if I should change the product in response to feedback or if I should just keep trying to find the right market?” The ones who have already been out in the field trying to conduct these interviews all have a sort of glazed, terrified look.

These are all really important questions. I’m going to give you a way to avoid having to ask most of them.

Stop trying to validate your product.

Now, I fully expect a bunch of people to stop reading here and totally miss the point of this post, but for those of you who stick it out, I promise this will make sense in a minute.

The trick is, it is far, far easier to conduct customer development before you have settled on a product or even an idea for a problem.

Why is that? Well, think about products as solutions to problems. Sometimes that “problem” is “I’m sort of bored while I’m waiting for the train” and the unexpected solution is flinging virtual birds at virtual pigs. But often, the problem is something more concrete, and it’s frequently shared by a large group of similar people.

So, instead of focusing on validating a solution, try one of the following techniques.

Validate a Problem

Let go of your preconceptions about how you are going to solve a problem for people and concentrate on first figuring out whether lots of people have a particular problem and what they’re currently doing to solve it.

For example, let’s say that you’ve posited that people have a really hard time finding and making appointments with trustworthy auto mechanics. The mistake you will probably make is to jump right into solving that problem and then going out into the world with some half-baked idea for Yelp meets OpenTable meets AAA and trying to find out whether it solves this problem that you’re not technically sure exists yet.

Instead of doing that, first validate the problem. Get on the phone with lots of different types of people and ask them how they found their mechanics. Talk to them about all of their mechanic-based issues. Find out what causes them the most pain.

Also, this is a good time to narrow down your market. Start with the market “people who have cars and will talk to you,” but quickly start noticing patterns. Do all the busy people have similar problems? What about people who live in cities vs. suburbs? How about people who are new to an area? Try people with special kinds of cars. I’ll bet that they all have very different problems, any of which you might want to solve.

Once you’ve spent time talking to people in various markets with various problems, you’ll come up with all sorts of ideas of how to solve those problems. The great thing is that then you can validate your product idea with people who you already know have a solvable problem.

This is a great way to do things if you have a particular problem yourself, and you want to find out if there are other people like you who have that same problem. By talking to lots of people with the same problem, you’re going to come up with a much better solution than you would if you just solved things for yourself.

Solve a Problem for a Particular Market

A slightly different approach is to pick your market first. Let’s say you have a special affinity for auto mechanics or busy moms or accountants at mid-sized companies.

The trick here is that you’re not going to change your market. You’re going to figure out some massive problem that is being experienced by a large portion of the market, and you’re going to solve it for them.

Your first step is going to be some ethnographic research. You need to really get into the heads of your target market and see what makes them similar and what’s driving them nuts. You’re not going into the research with an idea of the problem you want to solve for them. You’re going to let their needs drive your product decisions.

This is a great method if you happen to have some specific connection with a group or industry. Let’s say you collect porcelain owl figurines. You might desperately want to solve a problem for other porcelain owl aficionados, but you should be open to what problem you want to solve for them. For example, it might be how to get large numbers of high quality porcelain owls. Or it might be ways to contact therapists that deal with severe hoarding issues. Let the user research guide you!

The Easiest Kind of Customer Development

Hopefully you’re noticing a pattern here. The easiest kind of customer development is the kind that you do before you have a very solid product idea.

If you figure out your problems and your market before you come up with an Idea or a Solution or a Product, then when you do build something, you’ve already done a huge amount of the work in figuring out if anybody’s going to use it.

This is really about controlling which variables you’re testing. It’s hard to simultaneously find a problem, a market, and the problems with a real product all at once.

However, once you’ve validated your market and your problem, you can create something that solves that specific problem for that particular market. The beauty of this is that if you build a product for a problem you know exists in a market you know needs it and still nobody uses it, you can be pretty certain that the problem is your product.

Like the post? Follow me on Twitter.

8 comments:

  1. Excellent article.

    Having read Lean Startup and Customer Development it all sounds very neat and tidy. You have a hypothesis go test it. But in the real-world interviewing customers is messy, people are complex.

    Your approach seems both logical and practical

    ReplyDelete
  2. Thanks, Giles! It's true. Real life Customer Development is anything but neat and tidy. It's really hard to get right. I'm totally on board with having a hypothesis and testing it, but it's so much easier to start with a smaller hypothesis than a fully fledged product.

    ReplyDelete
  3. Excellent article, very logical yet I'd fallen into the same trap and would invariably start discussing features (in my instance we created a service beforehand and are now retrospectively applying Lean Startup).

    ReplyDelete
  4. I need some simple answers. Being a software developer, research about market or validation/invalidation of it makes me confused.

    1 - You say to reach out to market and observe and find their problem. This is not different than Steve Blank Mantra of "Getting out of the building" but the issue is that not every one is in Valley or in US in particular. Being someone living in Pakistan, how can you suggest some step by step methods to find out real problem of people using technology?

    Is there any tool available for it?
    Thanks

    ReplyDelete
    Replies
    1. Hi desipreneur, I'm sure Laura can elaborate on this but you can follow the same process if not the same approach. We complimented the above with emails to a portion of our customer base, posts on forums for target customers seeking feedback. It's significantly more beneficial to meet people though, you get a lot more information from them. Why not use family members and friends, who in turn can point you in the direction or others, or visit colleges or other academic institutions who, generally speaking, are more forthcoming in the desire to assist with all things knowledgeable!

      Delete
  5. Great post, but I disagree that it is easier to do Customer Development before you had an idea for a product. It may be easier for newbies to actually listen to what their customers are saying, but I think it's important to have a guiding vision. At LSM we see both sides of the spectrum-- teams without an idea that pivot endlessly only to end up back where they started and teams with an idea and the inability to admit that their baby is ugly. The sweet spot is in the middle, probably closer to the vision end.

    ReplyDelete
    Replies
    1. Oh, Trevor. Trevor, Trevor, Trevor. HOW DARE YOU DISAGREE?? I kid. It's a good point.

      I would argue that having a "guiding vision" is not necessarily incompatible with doing cust dev before you have an idea for a product. You can have a vision for a problem you want to solve without deciding how you're going to solve it. That's that first "validate a problem" thing. You can hypothesize that people have a particular problem and then go out and learn more about the problem before deciding how you're going to solve that problem.

      You might even have some vague idea when you start about how you think you might solve that problem, but the trick is not to get married to it before you've validated that the problem a) exists, b) is exactly what you think it is (hint: It isn't), and c) is a problem that people are likely to be happy to have solved.

      So fine, have a vision. Just be totally ready to change it when you find out it doesn't actually solve a problem. OR, don't create the vision until after you're sure you've got a problem to solve in a market that needs it. Then feel free to have as many visions as you want.

      Delete
  6. This comment has been removed by the author.

    ReplyDelete