Hi all. So — this is my second time in Russia — but my friend Alexander told me the weather is so good in December that I should really come visit!
But my first time giving a talk with a translator 🙂 so there’s a first time for everything! Please bear with me.
A quick moment to thank Alexander, Elena and the South Ural State University for hosting us today.
So I was thinking about what I could say today, and after speaking a bit more with Alexander and Elena, it’s pretty clear that many of you are somewhat familiar with a lot of the great stuff that’s been written about early stage product development on the web.
So I’ll focus on telling five stories from my experience — one is something I’m working on right now, and a few from past products I’ve been involved in.
Turn your assumptions into testable hypotheses. And test them
Most people who start new businesses or make new products do so because of some deep conviction they have. By most standards, it’s not a rational thing to do — the odds are always against you. So there’s this sense of self-delusion people have, and it’s awfully tempting to just go off and build it.
Sometimes that’s the right approach — some experience you have had has given you have a powerful itch, and you just want to go scratch it.
But when you’re making a new product, it’s like you’re facing an upward slope in front of you, and it can be hard to tell whether you’re climbing a little hill, or a big mountain. And you really want it to be a big mountain — because if you climb and discover it’s just a small hill, then you’ve hit what the mathematicians in the room would call a local maximum. You’ve spent all this time getting to the top, but it turns out not to be a very interesting vantage point.
And it’s really, really easy to spend a lot of time creating something that the world doesn’t really need. It can be years of your life!
So you want to make sure there’s a big, intense, unmet need for what you want to do — ideally before committing tons of time and effort to building an actual product.
And from the customer’s perspective, early-stage products have a ton of downsides! They’re buggy, the documentation is bad, there are features missing.
They require people to change the way they do things.
The core of what you’re doing has to be so unbelievably compelling that your customers are willing to overlook all of the bad stuff in order to get access to the benefits.
So how do you do figure that out?
Right now, I’m actually in research mode for a new business I’m interested in starting. We’re interested in making products and services for rideshare drivers (people driving for services like Uber), who are doing it part time while they do something to upgrade themselves, like take classes toward a university degree.
We’re pretty sure there’s a need, but we want to test it more before committing time, money and effort.
So here are some of the things we’ve done in the past few months:
1. Created a set of hypotheses to validate. These can be things like “Riders are more willing to tip a driver if the tip is going to go toward upgrading that driver’s life.”
2. I signed up to drive for Uber, and actually transported customers for a few weeks. There’s no better way of building empathy than putting yourself completely in someone else’s shoes. Turns out it’s pretty hard work, especially in a big and active city like Seattle or San Francisco.
3. We spent a few days interviewing drivers. We did this by going to hang out at the airport, where they’re waiting, and by actually paying for trips, and interviewing drivers along the way.
4. We’ve recruited drivers using Facebook. Turns out a lot of Uber drivers have created a community around !!
When we talk to people, we try really hard not to bias their answers. We do this by asking open-ended questions, and by following up by asking why — not just once, but four or five times until we feel like we know the real reason.
So far, we’ve learned some fascinating things. For example, men and women seem to react very differently to our idea. Men tend to view it negative as charity, and don’t like it; whereas the women are more open-minded.
So as I mentioned, we’re still in the midst of seeing if this is interesting enough to really pursue. But this kind of research is key to make sure that the time you see is actually the hill you want to climb. A little time and money up front can save you a lot of wasted time.
Focus on what people do, not what they say
Scott Cook, the co-founder of the US software company Intuit, often used to tell a story about a product they launched that failed; and it’s such a good story, I’ll repeat it here.
Intuit’s first business was a product called Quicken, which helped individual manage their financial lives — keep track of their accounts, checking account balances, pay bills, etc.
When they spoke with their customers, a number of them said they really knew they should make a longer-term financial plan, and would like a product from Intuit that helped with that.
So the Intuit team went off and talked with financial planners, and end users, and designed and implemented a beautiful product that really did financial planning right.
And like any good, well-organized software company, they recruited users to try it out in “beta” mode before releasing it.
But something strange happened at that point — they actually had more trouble than they expected finding enough people who wanted to invest the time to try it out.
But they eventually filled the group, got everything tested and ready for release.
When they released it, it bombed. No one bought it.
Turned out they learned a very painful but important lesson — financial planning is one of those things that everyone knows they *should* do, but very few people actually do in practice.
The lesson for product developers: focus on behavior. The most reliable way to create new products people love is to find something people are trying to do now, but for some reason, it’s not as good as it could be.
By watching and understanding, you can see how you’d make it better, cheaper, faster, or more fun than it is now.
But it had better be a lot better, because getting people to change their ways is harder than you think. The world isn’t just waiting for you to launch your product.
You have to be so much better at *something* than what’s out there that people beat their path to your door.
Launch earlier than you’d think
If you’re making software. Hardware is different! So for this one, I want to tell you about the time we added two new features to a product I led, and made it 10 times more expensive to buy — and customers thanked us. But we had to launch the lower priced version to figure that out that was possible.
The product was called QuickBase, which started out as a way to share a spreadsheet online — something like a contact list, or a list of tasks for a team — and turned into a pretty powerful and sophisticated way to create new web applications on the fly, without writing new code. We launched it way back in 2001, when the whole idea of web applications and sharing data online was really new and unproven.
So what’s so interesting is that you can do all the research you want, but there’s still going to there’s a lot you don’t know before you launch. We originally thought QuickBase would be relevant to small businesses! After almost a year in the market, we had about 1000 customers, each paying $15-20 per month. Not bad — but not the kind of growth that we needed to see for it to be an interesting business. Again, a local maximum. But when we looked at who actually was buying it, we found a surprise — a lot of our early customers were actually very large corporations, buying it for their workgroup. It let them do things faster than their internal IT department would.
So we went around and talked to some of these customers, and we heard a lot of good things. We found that they were using our product to solve problems that were incredibly valuable to their businesses. Google used it to manage their regulatory compliance process with US securities laws. Marriott, the hotel chain, used it to manage their response to emerging medical epidemics in Asia. Fleet bank used it to manage their portfolio of software projects they had underway.
In each case, people used it because it was fast, and it let people do things their way.
At the same we heard that we really weren’t perfect for them, either. The core of what we did was good — but they often needed to fight with their company’s IT department to get permission to use us.
So- based on this insight, over the span of a few months, we added few key features — mostly ways for companies to exercise some control over who had access to QuickBase.
And we added a new level in price, which increased the price by over 10 times — to $250/month.
Amazingly, those customers who worked for large businesses were happy about this. They felt that we were getting way more value from it anyway — and the new features we added meant that they didn’t have to fight as hard with their company to be allowed to use us.
Now — in hindsight, should we have launched it first aimed at larger businesses? Maybe.
If you’ve created something of value, it should be valuable enough that people will fight for it.
But until you launch something, you don’t get the chance to learn from how the world reacts to it.
It’s important to say at this point, though, that what to launch and when is always a judgement call.
You can’t launch, for example, a car with a motor that doesn’t work, and then be surprised when people don’t buy it because it won’t actually get them anywhere. There has to be value.
If transportation is your business, start with a bicycle. Or a moped. And then move up to the car. There has to be some core that people find exceptionally valuable.
You might think the first version is embarrassing. The vision in your head is of a beautiful, polished, delightful utopia. But if you wait for that, you’ll never learn from what people think. And there’s no better teacher than real customers.
Say no, often
There’s a saying in startup circles: “Startups are more likely to die from eating too much than from starvation.” And it’s really true — when you’re growing your business, there’s a natural tendency to say yes to things that your customers ask for.
When you’ve launched something new and it starts to take off, it’s usually because you’ve hit on doing something uniquely well that gives your customers a reason to put up with the pain of an early-stage product.
But with attention comes requests — and with requests comes decisions about where to spend your time and effort.
It’s easy to be optimistic about new features and capabilities. You understand why a customer is asking for something, and you can get some sense that it might not take that much time to implement. If you’ve done your job with research and empathy, you’ll feel their pain. And it’s painful!
But your job, more often than not, is to say “no” and focus.
For big companies, saying no is relatively easy. They know, who butters their bread, and their sample size is much larger. So they can make better decisions with data.
Startups often don’t have that luxury. You have limited “runway” — the amount of investment money you’ve raised to build your product in advance of the revenue you’ve received. You don’t have that many customers yet. What you do have is a hypothesis about who your customers are, where the big opportunity lies, and what direction the broader market is heading.
New features, more often than not, are like an iceberg — the complexity lies below the waterline, where you can’t see it. In the time it takes to test and support. The complexity it adds to your code base. The number of permutations you have to support.
The hardest decisions sometimes come when there’s a lot of money attached to a new feature in the short term.
As an example: QuickBase launched very early, as a cloud-based web application, in 2001. Well before this was an established category. As we started to attract customers from larger corporations, they would sometimes go to their IT department to get permission to use it. And at that point, their corporate policies often dictated that all data be stored locally, in a server on their network.
Which would have required us to develop and support a locally-installable version of our product.
And there was huge amounts of money for the taking. Millions of dollars.
Was it feasible? Yes. We had a world-class engineering team with advanced degrees from MIT. Anything was possible.
Our head of sales — a fantastic, creative guy — wanted to do it. Partly because he stood to make a lot of money on commission — but partly also because he believed, as many do, that more revenue and customers would help grow the overall business and contribute to our success.
But we said no. Why?
There were a lot of practical reasons — it would have added big complexity to each release, in terms of how we could test it, ship it and release it. It would have slowed us down a lot. But all of those were things we could overcome.
The biggest reason was our conviction that ultimately, this was a temporary phenomenon that would go away. The market, and the more advanced of our customers, were beginning to to accept cloud software, and we believed that within a few years, locally-installable software would be a vanishingly small part of the market.
And that by spending time there, we’d inevitably have to spend less time on other things that would delight customers, building toward the future.
Some of these things seem obvious in retrospect, but at the time, in the thick of it, it’s not always so obvious. Many of these decisions aren’t as big. What about this new checkbox? Couldn’t we just do this?
But don’t be afraid to say no.
Prioritize Delight
If you’ve done a good job getting out of the building and understanding your customers and their actual behavior, they’ll usually give you a lot of practical things they’re trying to accomplish, and a sense of how your product can help them do that.
Products people love go beyond that. They anticipate, surprise, inspire and delight. They’re the small things people would never ask for, but that, once experienced, help people love what you do.
Another company I co-founded was called Limeade. We started the company based on the idea that we could help people be happier, more energized and healthier at work.
Our buyer was typically the head of human resources at large companies.
Employees used our product to participate in social games to encourage them to exercise more, eat well, and manage their stress.
If we could get people to do those things, we thought, companies would benefit by having a workforce that was healthier and more productive, with less occurrence of chronic diseases.
Getting employees to participate was sometimes hard! Often, people don’t just want to do something because their company tells them to. They’re not getting a bonus or more money because of it.
In creating the product, we did our homework.
We relied on experts in psychology, behavior change and cognitive behavioral therapy.
All of these gave us a strong idea of what kind of features to add to our product.
But we were careful to leave some time in our product plans – even just 5% of our total effort – for things that they would find surprising or delightful.
We prioritized little messages of congratulations. Popups with encouraging messages.
One of the things that worked especially well was a question that asked each user how they were feeling that day.
The possible answers were a set of five faces, from a frown face on one end, to a smiley face on the other.
The idea was to make each employee feel like our product was about them first — not their employer, or anyone else.
No one asked us to do it. But after spending time with users, we thought it would make them smile and change how they felt about our product.
So do your homework. Talk to users. Do the functional stuff. But don’t be afraid to be quirky or to let your personality come through.
Creating new products is hard. Most of them fail. Doing it right is a matter of close observation, focus, open-mindedness. A blending of art and science.
The five ideas I’ve shared today — Test your hypotheses, focus on actual behavior, launch early, say no often, and prioritize delight — aren’t a sure recipe for success.
But hopefully they’ll help give you the fortitude to get out there, launch and learn!
Оригинал:
Dave’s speech «Startup experience», опубликовано К ВВ, лицензия — Creative Commons Attribution-NonCommercial 4.0 International.
1 нравится это
