Recently I was reminded about the importance of abstracting one level up when trying to understand a problem space. This is an idea that I was introduced to in Cindy Alvarez's fantastic book Lean Customer Development, and it goes like this:
Say you want to build a menu bar app for Mac that shows the local time for your remote team members. You have the idea, you have an image of what the design might look like, and it's a problem you've experienced. If you post a mockup on Twitter and ask, "Would you use something like this?", you're opening yourself up to a lot of potentially false validation.
Why? Because you zoomed straight past the problem! Your product or service doesn't exist in a vacuum—it exists to solve a specific problem. That is where you are going to find your nuggets of insight.
So instead of asking about your product, try asking about the problem it addresses. "How many times in the last two weeks did you have to look up a remote teammate's local time?" will tell you so much more about the importance of the problem you're solving.
The important mental shift here is recognizing that your solution does not exist on the same plane as your problem space. Abstracting one level up gives you a better idea of the context and where your problem sits in terms of priority for your target audience.
Say you want to build a menu bar app for Mac that shows the local time for your remote team members. You have the idea, you have an image of what the design might look like, and it's a problem you've experienced. If you post a mockup on Twitter and ask, "Would you use something like this?", you're opening yourself up to a lot of potentially false validation.
Why? Because you zoomed straight past the problem! Your product or service doesn't exist in a vacuum—it exists to solve a specific problem. That is where you are going to find your nuggets of insight.
So instead of asking about your product, try asking about the problem it addresses. "How many times in the last two weeks did you have to look up a remote teammate's local time?" will tell you so much more about the importance of the problem you're solving.
The important mental shift here is recognizing that your solution does not exist on the same plane as your problem space. Abstracting one level up gives you a better idea of the context and where your problem sits in terms of priority for your target audience.
I've been thinking lately about the minimum viable research stack and what tools I'd recommend to someone just starting out with research. It's an important question because, if you've spent any time looking around, you'll know that there are thousands of research tools and most of them are clunky or outdated.
In general, I like to keep things simple. So here's what I would go with:
In general, I like to keep things simple. So here's what I would go with:
- SavvyCal — Schedule times to talk with your customers.
- Whereby — Create a personal video chat room with screen sharing.
- UsabilityHub — Run quick surveys, questionnaires, and prototype tests.
- Tremendous — Send gift cards to your customers as incentives.
All of them except for SavvyCal include a free tier (and SavvyCal is worth paying for right away because of how much it simplifies things for you and your customer). So you can start your research stack for just $120 per year.
If you want a white-label research experience for your customer, upgrade to the Pro plan on Whereby and swap out UsabilityHub for Reform. The total annual cost should be around $300 (at current prices) for a really nice research setup.
If you need a completely free research stack, you can swap out SavvyCal for Calendly's free tier. It's not quite as nice but it'll get the job done.
If you want a white-label research experience for your customer, upgrade to the Pro plan on Whereby and swap out UsabilityHub for Reform. The total annual cost should be around $300 (at current prices) for a really nice research setup.
If you need a completely free research stack, you can swap out SavvyCal for Calendly's free tier. It's not quite as nice but it'll get the job done.
Laura Klein wrote a great break down looking at why you aren't your user and the dangers of assuming you can easily step into their shoes. If you want to know how your users feel and really understand their experience, it's usually best to just listen to them.
You aren't your user - even when you make employees dash
Laura Klein | linkedin.com
Plenty has been written about identifying the key indicators that you have product/market fit. I personally like the Sean Ellis method — look to have 40% of your customers say they would be very disappointed if they could no longer use your product.
Besides that, I've found through personal experience — and heard from many founders — that product/market fit is just one of those things. You know it when you see it.
Besides that, I've found through personal experience — and heard from many founders — that product/market fit is just one of those things. You know it when you see it.
The best time to add a dedicated research function is after you've reached product-market fit. Before then, you only have one guess — whether your product is valuable to people. And it should be the only thing anyone is trying to figure out.
After product/market fit, your assumptions will begin to increase exponentially and the sooner you get a handle on them, the better. A good research partner will help build a proper scaffolding around those assumptions. They won't just do research (though they will), they will empower others and accelerate the overall rate of learning that is happening across the company.
After product/market fit, your assumptions will begin to increase exponentially and the sooner you get a handle on them, the better. A good research partner will help build a proper scaffolding around those assumptions. They won't just do research (though they will), they will empower others and accelerate the overall rate of learning that is happening across the company.