The Keys To Building Successful Products
Ha Nguyen, Product Partner at Omidyar Network, shares a 3 step process for building great teams and great products.
A common stumbling block for startups is when founders build a product they think users will want. Instead, they should be focused on building a product that they know users will love, Omidyar Network Product Partner Ha Nguyen says. The distinction sounds simple, but getting there is another, more challenging matter entirely.
Nguyen has learned this lesson firsthand — and at times, the hard way. She was a product leader at eBay when it was just a startup. She helped develop successes like the “Buy It Now” feature, but also worked on failed products, like eBay Stores. Now she uses insights from her experiences to advise Omidyar Network portfolio companies on product development. Nguyen also previously served as a product executive at Keaton Row, Stella & Dot, Oodle and Betfair.
In this presentation given at the Google Sao Paulo campus, Nguyen shares her deep understanding of what makes products great, and what causes products to fail. She details the necessary steps to create the right environment and structure for the team to discover what products they should be building for their customers. She discusses the importance of conducting customer discovery — getting out of the building to talk to customers to gain a deep understanding of their needs and pain points. Finally, Nguyen discusses her favorite product discovery approach — the design sprint — and shares how, using these methods, Brazilian edtech startup Geekie turned its fortunes around.
Step 1: Build A High-Performing Product Team
To kick things off, you must start with a strong foundation. That means not only hiring great people, but also creating a great team environment and culture that holds teams accountable for outcomes. To create an all-star, high-performing product team, Nguyen recommends the following:
- Cross-functional team empowerment. A common trap that startup teams often make is that they will execute largely against the CEO’s ideas. It’s tempting for CEOs or founders to map out a roadmap and then ask the team to execute against it. But don’t. “Instead, allow the teams to make decisions based on the data. Allow them through the process of customer and product discovery and product validation to tell you what they should be building,” Nguyen says.
- Give each team a North Star KPI and objective. Another mistake that Nguyen observes is that teams are aligned around product areas or domains but leadership will fail to give them a clear North Star metric to rally around. The most successful product teams each have a clear set of KPIs or objectives. “Measure your teams against those KPIs. Did they actually move the metric, whether it’s revenue or conversion or engagement? Each product team should have just one metric — no more than that. Multiple objectives overwhelm teams by making it impossible to prioritize,” Nguyen says.
- Value outcomes over output. Don’t think of launches as success. “Product teams will tell me, ‘We just launched our mobile app last week, done!’ Then they move on to the next feature. Success has nothing to do with shipping. It’s about whether or not you moved the business outcomes,” Nguyen says. “The less successful teams are all about output and throughput. ‘Oh, but we’re really fast, we ship really fast.’ Great, but your metrics aren’t moving. How can you say you’re successful?”
Your product team should be telling you what to build — not the other way around.
Step 2: Talk To Customers
The next step is customer discovery. The top rule for that is simple: Talk to your customers. “We think we know our customers, but we don’t. You won’t discover what you need to discover unless you go out and talk to them,” Nguyen says. “One education startup wanted to build lesson plans for teachers. Instead of writing a single line of code, they went out and talked to 100 teachers first. Those teachers told them that lessons plans were fine, but their real problem was managing disruptive students. Their feedback flipped the idea for the entire startup on its head.”
The startup was ClassDojo, which six years ago built 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 U.S. schools.
“Talk to your users. Go to their homes if you have to. You’ll learn a lot of things that will often surprise you,” Nguyen says. “Airbnb struggled when it first started despite getting a few positive PR mentions. The founders finally went to 100 hosts — staying in 100 Airbnbs — and talked to them. They learned of all sorts of concerns including trust and payment that led them to turn the site into the success story we know today.”
Talk to 100 customers and then decide what product to create. Don’t spend weeks building something no one’s going to use.
Step 3: Create Your Customer’s Dream Product
After your high-performing team talks to lots and lots of customers, it’s time to go back to the building. “At this point, we really understand our users needs and pain points. Now the question is, ‘What is the solution we’re going to build for them?’ It’s time to cycle through a ton of ideas. Not every idea is good. You increase your chances of success by validating many of your ideas through a process like Google X cofounder Tom Chi’s approach to rapid prototyping,” Nguyen says. “Time is your enemy when you’re a startup, so you need a way to learn fast. Instead of building each one of your ideas, it’s critical to run a process to discover and validate the best ideas with your customers.”
Nguyen’s favorite method for doing product discovery is a five-step process called The Design Sprint developed by GV (formerly Google Ventures). Here’s how you can execute it:
- Understand the problem. “It’s important to start with knowledge sharing among sprint team members” Nguyen says. She typically dedicates a morning to the following process:
- Interview the experts. Have people talk to other team members to build shared knowledge of the challenge at hand.
- Collect ‘HMW’ notes. HMW stands for “How Might We…?” 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. A HMW could be “How might we gain trust from users?”
- Organize the HMWs into themes. Team members now work together to move post-its into clusters on a wall or whiteboard; themes will start to emerge. Label each cluster with a theme, such as “Building user trust.”
- 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?
- Define your sprint challenge statement. Articulate the challenge you’re trying to solve during this five-step design sprint.
The last part, the challenge statement, is where a lot of teams steer wrong. Often times, when Nguyen runs design sprints with her startups, the initial challenge statements are all about company problems, not user problems. “‘How can we get people to go from free to paid?’ That’s fine, but unless you’re solving a problem for a user, removing pain or providing them some benefit, they’re never going to do what you want them to do,” Nguyen says. “Get into their mindset. What is their goal, what is their need? Create your challenge statement from the perspective of the user.”
It’s not about what you want customers to do. It’s about what will make their lives better.
2. Diverge. Now you enter the ideation phase to come up with as many potential solutions to your challenge statement as possible. “Brainstorming sessions can be flawed because people feel compelled to discuss and evaluate every idea being thrown out. Rather than debating every idea, I use a process called Crazy Eights,” Nguyen says:
- Each person should fold a piece of paper into eight squares
- Give everyone five minutes to sketch one idea per square
- Post all Crazy 8 sketches on the wall “art gallery-style”
- Team members silently vote on each others’ ideas by placing sticker dots on their favorite ideas
“This process should be completely 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 ideas,” Nguyen says.
3. Decide. Now you’re ready to have a discussion, but “instead of having to talk about every idea, just talk about the best ones,” Nguyen says. “After the discussion, 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 user interface and write down notes.” Now, it’s now time to hang these individual solution sketches up on the wall art gallery-style and have team members vote on their favorite parts of each solution sketch. After discussing each solution sketch and a group vote, the decision maker makes the final decision on which solution sketch she would like the group to storyboard to further develop in more detail.
4. Prototype. After the storyboarding process, it’s time to create a prototype of the chosen solution. “Be very clear — this is not code,” Nguyen says. Instead, the team will put together an interactive prototype (clickable mockups) based on the team’s storyboard.
5. Validate. Now it’s time to go out and talk to users. The main things we want to learn from them are the following:
- Do they relate to this problem? Is this a problem they even have?
- Can they use this prototype? Don’t show them how to go through it. Give it to them and watch them as they use it — don’t explain things when they get stuck. “Ask them, ‘What would have happened if I wasn’t here in the room?’ They’d probably say ‘I’d have just given up.’ It’s helpful to hear that feedback,” Nguyen says.
- Do they find this solution valuable? The most important question is: “Would they actually use this solution over the alternative solutions that exist today? On a scale of 1–10, would they tell a friend about this? If they don’t give a 9 or 10, ask why and what would it take to get a 9 or a 10. You’ll be amazed at what customers will reveal to you.”
Don’t help customers use your prototype. If they’re struggling, that tells you something.
A Design Sprint In Action
One of Omidyar Network’s portfolio companies, Geekie, a Brazilian education tech startup, recently executed this process with Nguyen’s guidance. Geekie has an adaptive learning platform which helps high school students prepare for the national exam to get into university. The company was seeing low engagement with their study plans and lacked alignment around the vision for the product. “The team wasn’t sure what they needed to work on to improve outcomes. That made it the perfect time to sprint,” Nguyen says.
The Geekie team followed the design sprint method, kicking off with knowledge sharing and ideation through diverging and converging. After selecting the best idea, they made a prototype. User feedback told them they were onto something, but weren’t there yet. Rather than starting to code, the team wound up doing four rounds of user testing with 20 users, iterating on the prototype each time. “At no point did they give engineers anything to code. Users said certain parts of their solution weren’t that valuable, so the team removed those features. For the parts that were more valuable but needed improving, the team listened and spent time bettering those parts of the prototype,” Nguyen says. “That’s the right way to design a new product.”
By the time the fourth round of testing had completed, the team began to hear excitement in students’ voices. One student said, “I want this study plan, let me use it now!” and another told the team, “Let me use this. I promise not to tell.” An A/B test showed that the solution improved conversion by 50%. Geekie had done it — they’d built a product their customers love!
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.