So you get a great idea, and you decide to turn it into a company. You get together with a few friends, and start hacking. But at some time, you may encounter what I call a critical devalidation. Essentially, this is the point where you realize that it just isn't going to work. Maybe you don't have the right team, or people just don't want the product, or it costs you too much to sell relative the revenue it will bring in. For some reason, you cannot keep holding the current course any longer. You need to abandon your current efforts and go back to the drawing table.
The first thing I can say is that you want to encounter these points as quickly as possible. It is much easier to cope with abandoning something you have worked on for a few weeks than something you have been doing for a few years. If you are talking to your customers and validating your ideas, you should pretty quickly get an indicator that something isn't right. However, regardless of when it happens, this is always a crushing moment. You can literally see the spark in someone's eyes fade as they have that realization.
So how do you deal with this? I'm going to confess that I haven't been terribly good at dealing with it in the past, but I will give you a bunch of options that don't work, and then I will recommend a few options that seem reasonable.
What Doesn't Work
Here are some things I have tried in the past. None have worked well for me, so I will tell you about the possible pitfalls of each.
Giving Up
If you give up, there is no way you will possibly succeed. Sure this is hard, but that's why the potential rewards are high. Sure you could go back to Corporate America and make a nice steady paycheck working for some big corporation, but that isn't what you want to do. You want to make this work. You have this stuff in your blood.
Doing Nothing
The first thing that doesn't work is doing nothing. You can sit around moping, thinking about what could have happened if your idea made it big. Sure, it's fine to take a little while to mourn. In fact, it is better to mourn for a little while than it is to jump immediately into something new. But don't take too long. Realize that the sooner you get back to work, the sooner you will find the idea that makes you successful.
Keep the Same Course
A second option is to ignore the critical devalidation, and to keep on going. This actually could be a reasonable option in some cases. Maybe you made some bad assumptions, which led you to unfairly conclude that your product is the wrong one. Possibly there is a different market for the same product, or you can figure out how to reach the actual people who want your product. Remember that startups are outliers - I would never immediately dismiss an idea because there isn't a $1 billion addressable market (I have seen people do this). Many of the best companies start out small, and hit it big later on.
However, it is important to be realistic. If people don't want your product, they don't want it. Don't keep beating a dead horse. If you can figure out how to make them want it, do that, but it isn't going to magically happen. Sure, Hail Mary shots hit the basket once in a blue moon, but each Hail Mary shot will prevent you from getting back to two-point attempts. Build something people want. You can build the best product, but if no one wants it, then you won't make any money (or make the world a better place).
Quickly Jump to Another Product in the Same Vertical
So you have spent a while understanding a vertical. You don't want to abandon that and start again. So you tell your team, "why don't we build Y instead of X?" The problem with this is that you may not be passionate about product Y. My original startup killed our first idea because of lack of addressable market. We quickly jumped to another product that catered to the same industry. Honestly, we weren't as passionate about the second product as we were about the first. So it never quite felt the same. Plus, we pretty much failed for the same reasons the second time around.
Leap Without Looking
It is easy to jump to the next reasonable sounding idea. After all, it is better to be working on something than to sit around twiddling your thumbs. However, if you jump too quickly, you may end up making the same mistakes all over again. It took a lot of effort to get to the point where you abandoned your last idea, so don't waste that. Look around, and some time really thinking before you start working on something new.
What to Try
Here are some things that I have tried. None of them have worked yet because I haven't hit it big, but they all seem like reasonable approaches. I'm probably going to focus more on them in the future.
Reevaluate Your Team
Do you have the right team? If you failed because of lack of sales talent, find sales people. If you couldn't reach enough users, find marketing people. If you don't have an engineer on your core team, get one. This is not to say that you should spend your time pointing fingers, but definitely think about what it takes to get the job done, and figure out whether you have that. If not, this is a good time to switch.
Find Something That Caters to Your Strengths
Everyone has certain talents. There are products that cater to those talents, and products that don't. Maybe one of you is an experienced Enterprise Salesperson. Well, if you are creating Consumer Internet products, their talents probably aren't going to best use. Maybe you love bikes but are spending your time trying to create a product that sells bowling balls. It's easier to do something you know how to do than something completely new. Starting a company is hard enough without having to do things that you have no particular talent for or interest in.
Build Something Exciting
This is easy. What are you passionate about? Build that. Build a product that solves one of your major problems. In business school, I learned a lot about Kaizen. Hold a Kaizen for your life. Keep a pen and paper with you at all times. Every time something annoys you, write it down. Every time you feel like it would be nice to have "X", write it down. After a while, look at your list, and there are probably a whole slew of new product ideas.
Start Testing Early
So you probably waited too long to test your last idea. After all, it was your baby, and it wasn't ready to face the big bad world. But it still got trampled by elephants as soon as you let it out there. So accept that some ideas will fail, and write that off as the casualty rate. Think up several ideas, and test all of them as quickly as possible. Think up the tests before you build the product, so that you can build a minimum implementation with the fewest possible features. Then you can build, test, pick the best idea, and focus on making that one successful. Or maybe none of them pass your tests. Then you have saved yourself a lot of time and trouble.
Keep Going
Regardless of what you do, keep going. You will miss 100% of the shots you don't take. A lot of people give up too early; it is easy to give up. After all, you put your neck out there, worked your butt off for a while building something, and got rejected hard. But the most successful entrepreneurs keep going until they succeed. If your product fails, build another one. If your team falls apart, build another one. If you are out of money, figure out how you can get by for a little longer (maybe some consulting work or a part-time gig). If you are dejected, tap into your support network. Make sure that they are people who will provide encouragement to the end - some well-meaning people will prematurely tell you to quit.
This isn't easy, but you can succeed if you keep trying (and learning from your mistakes).
Thursday, February 11, 2010
Wednesday, February 10, 2010
Quickly and Cheaply Validating Your Ideas
So you have a great product idea, but how do you prove that the world wants it? Well, one way to do this is to spend 3-6 months building that product (for your sake, we assume that's all it will take). You hack away, building the features that you want. When it is finished, you attempt to get some people to come to your site and try it out. If all goes well, you get a bunch of people to try it, and they give you feedback on whether they like it. Hopefully they do, and if not, well, it's back to the drawing table. Maybe they even tell you what they want to build next time. However, you have just burnt 3-6 months of runway (which could be coming out of your pocket). It's also pretty dejecting to build a product that no one wants.
There has to be an easier way to do this. Well, there is. Until recently, it was pretty expensive and difficult to validate your ideas (pay someone to run a focus group), but recently this has become easy, thanks to two inventions: Google Adwords and rapid development frameworks (Ruby on Rails and Django are two that come to mind).
So there are two things that every web startup needs to do: user behavior studies and experiments. These can save you a lot of time and money, and can help put your product on the right track in minimal time. If you haven't already started. you should be doing them now. So what are these things, and why are they important?
User Behavior Studies
I'll start with these first, because they are simple. This could more simply be called "talking to users," but they are actually better than talking to users, because you get to see how a user truly feels about your application (and this is pretty obvious when you do a user behavior study). To your face, a lot of users will tell you that your product idea sounds great, but that doesn't mean that they truly mean it (or that they will use it).
If you were a big company like Google, you would have a fancy usability lab. You would have people who were hired just to do usability testing. They would run users through a set of actions, and the product managers and engineers would watch behind one-way glass (the product managers would furiously scribble notes about every move that the user made). There would even be fancy computerized systems tracking where the user is looking at all time. In the end, you would be able to see real users use the product. It would be a big production. No one would get any work done for days, and then you would have a big meeting to discuss the "learnings."
How do startups hack this process to their advantage? Well, you can put together a quick demo of your product, and load it on your laptop. Build the simplest possible demo that exposes the functionality you want to test. Then head out to the nearest busy coffee shop. Talk to some random people, and ask them if they will take part in a quick test (most people are pretty nice about this). I know it's scary to talk to random people, but much less scary than spending 6 months on a product that flops. Start by asking general questions about how they already accomplish what your product wants to help them do. If, for example, your product helps them to shop, show them a blank browser, and ask them to shop for a product that they want to buy. Observe what they do. Encourage them to speak their thought process aloud. Observe what pains they encounter.
Next, whip out your demo. Ask users to attempt to "use" it. Give them as little instruction as possible. Mostly, just watch. Encourage them to narrate. If they get stuck, observe that before you tell them what to do.
Watching a few users can give you invaluable feedback. My current team had some conflicting hypotheses about how users would use our product, so we resolved this by showing the product to five random people at a coffee shop. In two and a half hours, and pretty much for free (I got a parking ticket for being over time in a two hour zone), we learned key facts about how people shop for products on the Internet. And we probably saved ourselves one to two months of wasted effort.
If you haven't done this yet, do it tomorrow.
Experiments
So while user behavior studies are descriptive, these give you hard data. To do this, you hack together several possibilities, and you put it out to the users to vote. But you don't tell them what you are doing - you can randomize the behavior of your site. First of all, build the minimum possible experience required to expose a feature. Then build a few alternatives, and make your application randomly serve one of the possibilities (be sure to keep track of which possibility you are testing). Then, use analytics software such as Mixpanel to record what the user does in each situation.
Finally, drive some Google or Facebook Ads to your page. Don't pay a lot of money - you often don't need all that many impressions to figure out what is going on (I think it cost us $6 to run one test that gave us valuable information). You may need to do some work figuring out which creatives lead to the highest click-through rates. Click-through rates don't matter terribly much, although Google will stop serving your ads if your CTR is too low. Plus, you will probably need to learn how to do this for when your product launches.
In the end, you can analyze the results, and draw conclusions based on what happens. It can be surprisingly quick - each time we have run an experiment, we have had fairly convincing results within a few hours. Of course, it is important to control the variables. If you change too many things between conditions, it may be hard to figure out what the true differences are.
In our case, we looked to see what would lead users to give us their email address (a big portion of our functionality involves emailing updates to users). We tried three conditions:
1) We immediately prompt the user for their email address.
2) We wait until the user does something on our site, and then we prompt them for their email address.
3) We display some site functionality related to the query term that the user clicked through on, and then we ask for the email.
Interestingly, the third condition had a massively higher conversion rate (actually pretty respectable), followed by the second condition, and no users gave us their email in the firstcondition (big shocker).
Ego Check
If you love your product idea more than your first-born child, you probably don't want to do this. There is nothing more crushing than having your product idea completely devalidated by an experiment or user behavior study. But it is even more crushing to spend six months to a year working on something that you end up killing because no one wants it. I've done both, and I would drastically prefer the former to the latter.
So get out there and start already.
There has to be an easier way to do this. Well, there is. Until recently, it was pretty expensive and difficult to validate your ideas (pay someone to run a focus group), but recently this has become easy, thanks to two inventions: Google Adwords and rapid development frameworks (Ruby on Rails and Django are two that come to mind).
So there are two things that every web startup needs to do: user behavior studies and experiments. These can save you a lot of time and money, and can help put your product on the right track in minimal time. If you haven't already started. you should be doing them now. So what are these things, and why are they important?
User Behavior Studies
I'll start with these first, because they are simple. This could more simply be called "talking to users," but they are actually better than talking to users, because you get to see how a user truly feels about your application (and this is pretty obvious when you do a user behavior study). To your face, a lot of users will tell you that your product idea sounds great, but that doesn't mean that they truly mean it (or that they will use it).
If you were a big company like Google, you would have a fancy usability lab. You would have people who were hired just to do usability testing. They would run users through a set of actions, and the product managers and engineers would watch behind one-way glass (the product managers would furiously scribble notes about every move that the user made). There would even be fancy computerized systems tracking where the user is looking at all time. In the end, you would be able to see real users use the product. It would be a big production. No one would get any work done for days, and then you would have a big meeting to discuss the "learnings."
How do startups hack this process to their advantage? Well, you can put together a quick demo of your product, and load it on your laptop. Build the simplest possible demo that exposes the functionality you want to test. Then head out to the nearest busy coffee shop. Talk to some random people, and ask them if they will take part in a quick test (most people are pretty nice about this). I know it's scary to talk to random people, but much less scary than spending 6 months on a product that flops. Start by asking general questions about how they already accomplish what your product wants to help them do. If, for example, your product helps them to shop, show them a blank browser, and ask them to shop for a product that they want to buy. Observe what they do. Encourage them to speak their thought process aloud. Observe what pains they encounter.
Next, whip out your demo. Ask users to attempt to "use" it. Give them as little instruction as possible. Mostly, just watch. Encourage them to narrate. If they get stuck, observe that before you tell them what to do.
Watching a few users can give you invaluable feedback. My current team had some conflicting hypotheses about how users would use our product, so we resolved this by showing the product to five random people at a coffee shop. In two and a half hours, and pretty much for free (I got a parking ticket for being over time in a two hour zone), we learned key facts about how people shop for products on the Internet. And we probably saved ourselves one to two months of wasted effort.
If you haven't done this yet, do it tomorrow.
Experiments
So while user behavior studies are descriptive, these give you hard data. To do this, you hack together several possibilities, and you put it out to the users to vote. But you don't tell them what you are doing - you can randomize the behavior of your site. First of all, build the minimum possible experience required to expose a feature. Then build a few alternatives, and make your application randomly serve one of the possibilities (be sure to keep track of which possibility you are testing). Then, use analytics software such as Mixpanel to record what the user does in each situation.
Finally, drive some Google or Facebook Ads to your page. Don't pay a lot of money - you often don't need all that many impressions to figure out what is going on (I think it cost us $6 to run one test that gave us valuable information). You may need to do some work figuring out which creatives lead to the highest click-through rates. Click-through rates don't matter terribly much, although Google will stop serving your ads if your CTR is too low. Plus, you will probably need to learn how to do this for when your product launches.
In the end, you can analyze the results, and draw conclusions based on what happens. It can be surprisingly quick - each time we have run an experiment, we have had fairly convincing results within a few hours. Of course, it is important to control the variables. If you change too many things between conditions, it may be hard to figure out what the true differences are.
In our case, we looked to see what would lead users to give us their email address (a big portion of our functionality involves emailing updates to users). We tried three conditions:
1) We immediately prompt the user for their email address.
2) We wait until the user does something on our site, and then we prompt them for their email address.
3) We display some site functionality related to the query term that the user clicked through on, and then we ask for the email.
Interestingly, the third condition had a massively higher conversion rate (actually pretty respectable), followed by the second condition, and no users gave us their email in the firstcondition (big shocker).
Ego Check
If you love your product idea more than your first-born child, you probably don't want to do this. There is nothing more crushing than having your product idea completely devalidated by an experiment or user behavior study. But it is even more crushing to spend six months to a year working on something that you end up killing because no one wants it. I've done both, and I would drastically prefer the former to the latter.
So get out there and start already.
Tuesday, February 9, 2010
Three Things (AKA Your Core Value Proposition)
I just came across this post by Paul Buchheit. In it, he talks about how you should focus on doing three things extremely well. If you can succeed at that, people will use your product, and you can build the rest later.
I've been working on a new startup with a new team (more on that later), and we're trying to nail down the product. When I came in, we started talking about getting out the minimum viable product. One of my cofounders has been working on the product for quite some time, and he already had a demo up, but for various reasons, we essentially started from scratch. So we mapped out the "minimum viable product," and started building.
Sounds good so far, but there were some issues. The first was a lack of customer development (I need to talk about that more later), but more importantly, the minimum viable product was defined in functional terms. So, for example, if the product were a task list (it isn't), the MVP would be:
1) add task
2) check off task
3) edit task
The problem with this is that we didn't define the MVP in terms of any sort of core value proposition. When I thought about it (after about a month of hacking), I realized that what we were building differed significantly from the original stated vision. We were building something that didn't really accomplish any of our key goals (as I understood them). Sure, it was usable, but it seemed like a compromise. To be completely honest, I was unconvinced that people would want to use what we were building (this became more obvious once we started talking to real customers).
So we started talking about our core value proposition, and how we were going to deliver on it. I came across Paul's blog post later, but it actually simplifies a lot of what we have been talking about. You have to focus on defining and delivering a few key features. These features should differentiate you from everything else that is out there. If you trying to be all things to all people, you don't make anyone happy. I have heard nerds gush about all of the features that Archos puts into their media players. The problem is that I don't know anyone who actually owns an Archos (whereas most people seem to own an iPod or iPhone). I don't want an Archos. It fails to create a compelling core value proposition.
So three actually seems like a good number of core features. It is enough to give your product some definition, but not so much that you try to do everything. It is actually an interesting exercise to limit yourself to three features, especially if you are an engineer "but it would only take ten minutes to add one more thing".
So what would be a compelling core value feature set for our hypothetical task list product? (I'm actually building this as a side project).
1) Makes it super easy to enter your tasks from anywhere
2) Uncluttered and simple interface that is accessible from any device
3) Bugs you relentlessly to complete the things that you put on your list
Now that I think about it, I accomplished goals 1) and 2) relatively quickly, but didn't focus on 3). The interface became cluttered with features, but not the one that mattered. Recently, I have slid into not using my own product. I'm going to refocus on my core value proposition, and hopefully I will get back to creating something that is useful for me.
I would actually argue that, of your three features, one has to be a draw, one has to become immediately obvious once people start using it, and one functions to keep users coming back. With the iPod, people bought it either because it was easy to use (simple interface, easy syncing with the mac) or because it had a large capacity. Once they started using it, the other features became obvious ("wow. I can store all my music on this" or "wow. this is easy to use"). I would argue that the stickiness was that it was small. You could effortlessly carry it with you (especially the iPod mini and Nano). Unlike a portable CD player (and the hard drive-based mp3 players of the time looked like a CD player), it fit in your pocket.
What are your product's three features?
I've been working on a new startup with a new team (more on that later), and we're trying to nail down the product. When I came in, we started talking about getting out the minimum viable product. One of my cofounders has been working on the product for quite some time, and he already had a demo up, but for various reasons, we essentially started from scratch. So we mapped out the "minimum viable product," and started building.
Sounds good so far, but there were some issues. The first was a lack of customer development (I need to talk about that more later), but more importantly, the minimum viable product was defined in functional terms. So, for example, if the product were a task list (it isn't), the MVP would be:
1) add task
2) check off task
3) edit task
The problem with this is that we didn't define the MVP in terms of any sort of core value proposition. When I thought about it (after about a month of hacking), I realized that what we were building differed significantly from the original stated vision. We were building something that didn't really accomplish any of our key goals (as I understood them). Sure, it was usable, but it seemed like a compromise. To be completely honest, I was unconvinced that people would want to use what we were building (this became more obvious once we started talking to real customers).
So we started talking about our core value proposition, and how we were going to deliver on it. I came across Paul's blog post later, but it actually simplifies a lot of what we have been talking about. You have to focus on defining and delivering a few key features. These features should differentiate you from everything else that is out there. If you trying to be all things to all people, you don't make anyone happy. I have heard nerds gush about all of the features that Archos puts into their media players. The problem is that I don't know anyone who actually owns an Archos (whereas most people seem to own an iPod or iPhone). I don't want an Archos. It fails to create a compelling core value proposition.
So three actually seems like a good number of core features. It is enough to give your product some definition, but not so much that you try to do everything. It is actually an interesting exercise to limit yourself to three features, especially if you are an engineer "but it would only take ten minutes to add one more thing".
So what would be a compelling core value feature set for our hypothetical task list product? (I'm actually building this as a side project).
1) Makes it super easy to enter your tasks from anywhere
2) Uncluttered and simple interface that is accessible from any device
3) Bugs you relentlessly to complete the things that you put on your list
Now that I think about it, I accomplished goals 1) and 2) relatively quickly, but didn't focus on 3). The interface became cluttered with features, but not the one that mattered. Recently, I have slid into not using my own product. I'm going to refocus on my core value proposition, and hopefully I will get back to creating something that is useful for me.
I would actually argue that, of your three features, one has to be a draw, one has to become immediately obvious once people start using it, and one functions to keep users coming back. With the iPod, people bought it either because it was easy to use (simple interface, easy syncing with the mac) or because it had a large capacity. Once they started using it, the other features became obvious ("wow. I can store all my music on this" or "wow. this is easy to use"). I would argue that the stickiness was that it was small. You could effortlessly carry it with you (especially the iPod mini and Nano). Unlike a portable CD player (and the hard drive-based mp3 players of the time looked like a CD player), it fit in your pocket.
What are your product's three features?
Subscribe to:
Posts (Atom)