Don’t Build Stuff No One Uses: Lessons from 3 Startups
When you are building a new venture, it can feel like aiming an arrow at a target off in the distance. Product market fit is a key material of your arrow (in addition to things like timing, team, funding, channels, revenue models, etc). You make the best arrow you can, draw your bow and let the arrow fly, hoping to hit the bullseye of a successful product.
As a user research partner for early stage entrepreneurs, I’ve heard lots of people’s adventures with finding product-market fit. Here are three stories of real entrepreneurs hitting or missing that bullseye because they did — or didn’t — do customer discovery/user research and what happened. If you want to better aim your venture’s arrow towards a bullseye, keep reading to avoid Rob’s and Mike’s mistakes, and find out what Jason did right.
Miss: Just Building
Rob (not his real name) had assembled a crack team of engineers and data scientists to build products that help people make better decisions using Artificial Intelligence. They had won a contract to develop a website for a very large client. They spent a year developing it, polishing the algorithm to make sure that they were showing the best possible recommendations, and worked their butts off right up until the deadline to make the big launch date where their client announced the site to millions of their users.
The response from users was underwhelming. Few people were sticking around after their first visit. What went wrong? Although internally the team had raised the question among themselves once or twice about whether they were building the right thing, they didn’t voice them or test early versions with users. They had felt sure of their solution. And they missed the mark of building something that people used.
Miss then a Hit: Just Building, then Research
Mike (not his real name) was a Product Manager for a startup that made small businesses loans. Noticing that income is irregular for small businesses, the team had an idea for a new feature for their software: What if small businesses could repay their loans in increments as a percentage of their revenue each month rather than the same set amount? This would take the pressure off having to make a large payment at the end of each month when revenue was small or variable. It was brilliant!
The team built the feature and launched it. They saw a small trickle of adoption but most people weren’t using it. Mike was dumbfounded — why weren’t they using it? He sat down with the customer list and started making phone calls, asking customers about the feature and their experiences with it. Through these interviews, he learned that many of the customers hated it; it resembled the tactics that shady, predatory lenders used and they didn’t trust it. He also found that the customers who hadn’t experienced predatory lenders loved the new feature and it solved a real problem for them.
Mike took a step back to regroup. He realized he had uncovered another pain point that he could solve for his the majority of his users — dealing with shady lenders. He and his team built a feature to go after these guys and help his customers get out of these bad deals. His initial feature may have missed the mark, but it was a bullseye on the second try.
Hit a Bullseye: Research from the Start
Several years ago, Jason, an engineer, noticed that companies like his were devoting a lot of engineering resources to building internal tools that were essentially simple forms on top of a database. Over and over again.
He realized that these were just spreadsheets on steroids — contorted to do many things in the corporate world like data models, process tracking, etc. And he became obsessed with the idea of a tool that has the familiar UI of a spreadsheet, but backed by the power of a relational database. A database would let the tool do those crazy contortions well, rather than cobbled together.
He started doing interviews with people who use spreadsheets. He asked people to show him their spreadsheets and talked to them about their pain points of where spreadsheets missed the mark. He started to hear themes and he developed a clearer vision of what his new product could be. He made a quick prototype that took less than a week to build and was just 1500 lines of Javascript. He created a short YouTube video introducing the product, showing how to use it, and describing the future direction. This vision based on what Jason saw and heard in interviews struck a chord; he raised $500k in seeding funding to build Version 1.
He brought together a small team and they started building Fieldbook. As they were approaching their private beta, Jason left time in the schedule for two weeks of user testing to fix any small bugs that came up. But those early tests were painful; people didn’t get how to do basic functions. The problems were not small bugs. Jason realized that they would have to push their private beta date out. He knew that the product concept resonated but the actual experience of using the product was too difficult. So he took his beta waiting list, and turned it into a potential participant list for user studies. This was the perfect pool of target users — people who had a real need for the product, really wanted to use it, and hadn’t used it before. And he rewarded them for participating in a study with early access to Fieldbook.
He organized 5 user sessions per week, for week after week; they would test with users on Monday afternoon and Tuesday morning. Then he’d build a new release that was ready to be tested the following Monday morning. During the session, participants had an opportunity to use the product while Jason and his team observed. And he also spent part of the session interviewing them to better understand their context: “What got you interested in product?” and “How do you do it today?”
The Fieldbook team iterated and iterated. Five months later, they were confident they had a product that met the needs of their users. Their user growth and retention numbers reflected that. And investors noticed too. Fieldbook raised $2.2 million in seed funding in April 2016.
Research moves the Target Closer
Rob and his team skipped user research entirely and missed the target entirely. Mike reached out to users only after an “Oh sh*t!” moment where few people were using the brilliant new feature, and he course-corrected to hit the target on a second try. Jason reached out to users throughout his process, moving the target closer, and making it easier to hit that bullseye.
As a founder, it’s critical to start talking to your users early and often to deeply understand them, their problems and needs, in order to build the right thing. Doing this helps move that far off target closer, making it that much easier to hit a bullseye. As you are developing your own product, consider whether you are moving the target closer through user research. If you aren’t sure how to do user research, let’s talk.
Marianne Berkovich has over 12 years experience as a qualitative user researcher at Google and Adobe, helping teams build products that users love. She has worked with and mentored dozens of smaller companies and early stage entrepreneurs to gain the know-how to do their own user research. Marianne teaches classes at the Nasdaq Entrepreneurial Center as well as tailored workshops for intact teams.