Startup founders only have so many shots to nail their product-market fit, so it’s crucial they prioritise research, work systematically and embrace both validation and invalidation, according to Great Question Co-Founder Ned Dwyer.

Speaking with our MVP Founders Fellowship cohort last year, Ned warned that “when you start working on a project, the worst thing that can happen is you publicly announce your plans, you build a team, you start spending money... and you later realise you're working on the wrong problem”.

“I've seen too many people do this,” Ned admitted, adding that he too has experienced this pain first-hand. It was a “key assumption” that ended up “murdering” early-stage corporate card startup Spritz, Ned explained. 

It is both Ned’s startup successes and lessons learnt that made him the ideal person to speak with our Founders Fellows about hypotheses, customer interviews and research. Here’s what they learnt. 

‍

Test your hypotheses quickly by working in bets

When you start a company, you have dozens of decisions to make on a daily basis. To stay focused and validate your work as you go, Ned suggests working through your hypotheses in bets, which are essentially two-week sprints. 

“When you work in bets, you commit to one hypothesis,” Ned explains. “Look at your hypotheses quickly and pick one. It could be the biggest one, the gnarliest one, the coolest of the lot, or the one with mega money-making potential, for example.”

Once you’ve picked one hypothesis, create a testing plan, and decide how you’ll proceed if your research affirms or denies your hypothesis. Then, throw yourself at this plan for two weeks. 

Sharing an example, Ned reflected on his time in Y Combinator’s Accelerator. 

He and Co-Founder PJ Murray had the idea to sell a research-management solution to researchers, product managers, marketers and designers. But this idea came with a lot of questions and hypotheses.

• “Which one of these groups is actually the right market?”
• “What's their capacity to pay?”
• “How do they buy?”
• “How many of them are there?”
• “What are they currently paying for software?”
• “Which market is the right one to start in? Who might be a little more amenable to being an early adopter?”
  

Instead of getting overwhelmed at all that they didn’t know, Ned and PJ systematically worked through these questions in bets.

At one point, they decided to test the hypothesis that researchers were their ideal early adopters, and leveraged LinkedIn to organise customer discovery calls. 

Before conducting a single interview, they also decided how they’d proceed at the end of the bet. 

“If we got five responses out of 100 messages, we would add an extra week to the bet. If we only got two, we’d stop and change one thing out of that stack — either the hypothesis, the customer, the messaging, or the channel,” Ned reflected. 

As it turns out, researchers were not Great Question’s ideal early adopters.

“While they're a great market, they often don't have much money, and they're very risk-averse,” Ned said. “Plus, they don't like being early adopters, they've got really long sales cycles and they need to go through procurement processes.”

Fortunately, Ned and PJ worked through and denied this hypothesis quickly and early, rather than relying on an assumption. 

“Working in bets gives you focus and keeps you accountable,” Ned said. “Bets ensure you’re not changing too many things at the same time, because only one of them might be wrong. But more importantly, when you get to the end of a bet and you’ve invalidated your hypothesis, you don't sit and dwell, because you’ve already got a plan.”

‍

Template your interview process so it’s easy to repeat

According to Ned, the larger the hypothesis you’re testing, the more customer interviews you need to conduct. What this also means is the amount of research you have to draw on will grow in line with your startup.

For example, when Ned and PJ Murray decided to double down on Great Question, they had about 10 interviews under their belts. When they decided to do their first build, they had 50. And when they raised capital, they had 150.

Without a repeatable process, however, speaking with hundreds of potential customers will quickly get messy, which is why founders need to live and die by their interview scripts. 

“A script will prevent you from asking leading questions. A customer interview needs to be objective, and you'll only be able to standardise your answers if you're using a script and stick to it every time,” Ned said. 

The best way to organise an interview script is like an inverted pyramid, Ned explained. 

“You want to start broad and then get narrower and narrower as you get to the last of your questions.Your hypothesis will be relatively low in the pyramid. At the highest level, you're just trying to understand who the customer is and what their problems are,” Ned said. 

What does a script look like in practice? 

“You generally open by setting the context,” Ned said. 

For example, explain that you’re there in a research capacity, and not aiming to sell anything. Ned also suggests remaining vague in your product description, so as not to cloud judgment or prime answers. He likes to add: "I'm looking for your genuine feedback. Please don't pump me up — I want to hear what your actual problems are.”

You’ll then work through a set of questions which gradually get to your research hypothesis. Here are the questions Ned has asked dozens of times, for example. 

1. “Tell me about your job and your company. What do you do?”
2. “Tell me about a day in your life. What’s your biggest problem?”
3. “What about that problem is painful?”
4. “In the next quarter, how likely are you to solve this problem?”
5. “Have you already got a plan to solve that?”
6. “Have you got a budget to solve that problem?”
7. “On a scale of 1 to 10, how well do you think you're doing research as an organisation? How would you become a 10?”
   

To close it out, you should ask to keep in touch, Ned said, and ask if they know anyone else you should speak with.

“Don’t fret if some of your customer’s problems have nothing to do with your hypothesis, Ned said. 

“If this happens, it might change what you do in your current bet, or maybe, you’ll park it, and revisit it only if you keep hearing the same thing again and again.”

“When you're doing these interviews, you should always try and have a note-taker or someone else in the room too, because you're probably going to interpret responses differently,” Ned added.

“You’re also going to have different questions as you follow the little tangents that come out. Immediately after the call, you want to be comparing and contrasting.”

‍

Codify your transcripts so you can readily spot patterns

You can’t spot patterns in a single customer interview, Ned said, so founders need a way to make sense of insights. Ned’s suggestion is to codify responses in a spreadsheet to identify trends. 

To do this, create a spreadsheet with a column for each customer and a row for each question. Instead of putting the entire response in the spreadsheet, simplify it down to a single word. 

When Ned and PJ analysed interviews about the top problems facing researchers, for example, they codified responses as “recruitment”, “scheduling”, “incentives” and “synthesis”.

“This allows you to filter responses and see trends,” Ned explained. “You might see that certain personas, such as the enterprise customers, have X problem, but the founder customers have Y problem. This is an invaluable insight.”

As trends, questions or insights emerge, you can use them as the basis for your next bet too, Ned said. 

As a proponent of continuous research, Ned said customer discovery should be part of every product release, instead of an occasional special event.

What this means in practice is “switching from a build-measure-learn development cycle to a “learn-build-measure approach”, he added. 

“Doing it the other way is very expensive.”