How To Build Rockstar Products: Think Like Airbnb, ClassDojo and Geekie

The following is a summary of the opening keynote I recently gave at Female Founders Summit hosted by Google.

I’ve seen the gamut of products in my 16 years as a product leader, from the successful to ones that never took off. Working at startups like eBay, Stella & Dot, Betfair and Oodle, I've learned a lot about what makes a great product. In my current role as a Product Partner at Omidyar Network, I advise startups on the best path to achieving product-market fit and building the next rocket ship. The key really is this: Build a product that people will love.

And when I say love, I do mean love. You want your customers to be fanatical about what you’ve built. It’s not enough for them to just like it. The end goal is a product customers can’t wait to tell their friends about. There’s a way to build products that people will love -- and while it doesn't guarantee success, it will certainly increase your probability. I've distilled it into the following 3 step process:

It’s not about what you want customers to do. It’s about what will make their lives better.

Step 1: Customer Insights

Start by talking to your customers. We may think we know about our customers, but we don’t. Talk to 100 customers in your target market, and then decide what product to create. Don’t spend weeks building something that you're not sure anyone will use.

Consider how Airbnb got its start. They initially rented out air mattresses, but struggled their first several years, despite receiving a smattering of positive press. The founders finally went to 100 hosts — staying in 100 Airbnbs! — and talked to them. They learned about concerns like trust and safety which led them to introduce user profiles and payments, ultimately turning the site into the success story we know today.

Startup ClassDojo began with an idea of building lesson plans for teachers. Instead of writing code, the founders went out and talked to 100 teachers instead. Those teachers told them that lessons plan were fine, but their real problem was managing disruptive students. That feedback flipped the entire startup on its head. They ended up building an app that allows teachers to reward students individually for positive behavior in the classroom. The platform now has over 35 million users and is present in over 90% of schools in the U.S.

Talk to 100 customers and then decide what product to create. Don’t spend weeks building something no one’s going to use.

Step 2: Product discovery

Say you’ve talked to 100 customers. Now the question is, ‘What is the solution we’re going to build for them?’ There may be dozens of good ideas that might solve your customer's key pain point. At a startup, time is your enemy and you don't have the luxury of time or resources to build each of your ideas. Before deciding on what to build, it’s time to cycle through a ton of ideas. Your chances of success increase by trying many things using processes like Google X cofounder Tom Chi’s approach to rapid prototyping. As he says, assume ideas have a 5% chance of success. If you try 20 things, you’ll have a 64% chance of success. If you try 50 things, that goes up to 90%.

My favorite approach is The Design Sprint, a highly generative and creative five-day process developed by GV (formerly Google Ventures). Last summer, I facilitated a design sprint with one of Omidyar Network's portfolio companies, Brazilian education tech startup Geekie, which helps high school students prepare for the national exam to get into university. Geekie was seeing low engagement with their study plans and struggled to increase paid conversions. They were unclear on what they needed to do. It was the perfect time to sprint.

Here’s how you can execute The Design Sprint — and what happened when the Geekie team tried it.

Understand the problem.

• Interview the experts. Pair off team members and have them interview each other about the problem at hand. This creates shared knowledge.
• Write ‘HMW’ notes. When a team member hears something interesting during their interviews, they write it down in the form of a “How Might We” question on a post-it note: “HMW gain trust from users?”
• Cluster HMWs into themes. Work together to cluster the post-its into themes, such as “building user trust” or “content organization.”
• Create a customer journey map.  What is the final outcome that users are trying to achieve? And what’s their journey like throughout the process?
• Write a sprint challenge statement. This is where a lot of teams go wrong. The first batch of statements are usually all about company problems. ‘How can we get people to go from free to paid?’ You need to be solving a problem for users, not for you. Geekie settled on: "How might we help high school students prepare for the national exam to get accepted into university?"

Ideation. Now you come up with as many potential solutions to your challenge statement as possible. I use a process called Crazy Eights:

• Fold a piece of paper into eight squares.
• Sketch one idea per square.
• Post all Crazy Eight sheets on the wall.
• Team members silently vote on each others’ ideas by placing sticker dots on their favorite ideas.

This process should be silent. In less than 15 minutes, a group of 6 or 8 team members can come up with as many as 48-64 ideas and quickly narrow them down to a handful of the best ones. Here's an example of a Crazy 8:

Storyboard.  After discussing the best ideas, each team member takes one of their favorite ideas to create a solution sketch around that idea. Where does the user start in the journey? Where do they go to next, and after that? And after that? Draw out the UI and write down notes. Have team members vote on their favorite parts of each solution sketch. After a group discussion and vote, make the final pick on which solution sketch to storyboard and flesh out in more detail. Have your team draw a storyboard for the user journey and product experience. Here's what Geekie's storyboard looked like:

Step 3: Product Validation

Prototype. After the storyboarding process, it’s time to create a prototype of the chosen solution. This is not code. Instead, put together a clickable mockup based on the team’s storyboard.

User Testing. Go out and talk to users from your target segment again. You'll want to test with 5-6 users individually and find out from them the following:

• Do they relate to this problem?
• Can they use this prototype?
• Is this solution so valuable they would use it over alternatives available?
• On a scale of 1-10, would they tell a friend about this? If not 9 or 10, why? What would it take to get to a 9 or 10? (Hint: If you are not consistently getting 9's and 10's during user testing, you'll want to iterate on your chosen solution and test again).

Geekie’s outcome:

Geekie’s product team followed the design sprint method, honing in on the best product idea. The team wound up doing four rounds of user testing with 20 users in total, iterating on the prototype each time. They removed and improved upon features based on feedback. By the time the fourth round of testing was done, the team began to hear excitement in students’ voices. One user said, “I want this study plan, let me use it now!” and another told the team, “I know this isn't quite ready yet, but please let me use this. I promise not to tell.” An A/B test showed a conversion improvement of 50%. Geekie had done it: they’d built a product their customers love! And the cherry on top: the team was inspired and motivated by the process, with some saying those were “some of the best days I’ve ever had at Geekie.”

Build products customers love — not like. It’s not ‘nice’ or ‘fine.’ People have to love it so much they’ll tell their friends about it. That’s when you know you’ve hit gold.

That's me giving a talk at Female Founders Summit at Google Launchpad.