The best startups generally begin by trying to address a really important problem worth solving. If they can nail the solution to this important problem, they have a great chance of building a successful startup.
How Solving Problems Can Lead to Failure
Surprisingly, founders’ instincts to solve problems can also cause us to fail. Many startups miss success signals because they are too busy solving problems. Our instincts tell us to be responsive to customer feedback – especially negative feedback. These problems are so actionable that we feel good solving them. But over time a startup that chases problem after problem creates a bloated, fragmented solution that isn’t really needed by anyone.
Find the “Must Have” Use Cases – Ignore Most Problems
Ultimately the goal of any startup should be to create a “must have” product experience. The signal that tells you that you have created a “must have” product is your true north to build a successful business. You should understand everything you can about the “must have” experience so you can cultivate and protect it. Who considers it a must have, how are they using it, why do they love it, why did they need it, where do they come from…?
It feels totally counterintuitive to pursue these positive signals while ignoring most of the feedback about problems. But in my experience, this is the right thing to do. In fact, this is the most important thing that I learned in the years that I focused on helping to take startups to market such as Dropbox, Lookout and Xobni. To reiterate, the positive signal is much more important than the ongoing flow of new problems.
Problems Worth Solving
So which problems are worth solving? Essentially any problem that stands in the way of delivering the “must have” experience once it has been identified.
Problems worth solving include:
- Usability issues that prevent reaching the must have experience
- Confusing value proposition about the must have experience
- Targeting the wrong users (AKA users who don’t need the must have experience)
But start by focusing the majority of your energy trying to create at least one must have use case. If you can’t find any positive signal about someone considering it a must have, then go back and revisit the original problem you were trying to solve. You might need to find one that is even more important to solve.
I recognize that my recommendation to ignore most problems is controversial. Please comment whether you agree or disagree. Hopefully we can get some good debate in the comments.
Update: Just to clarify, I’m referring to the data that deserves your focus. I don’t mean to imply that you should be unresponsive to the customers that make suggestions. It is very important to give great customer support. Just don’t promise to change your product/business based on every reported problem.
Andrew Chen
Brant Cooper
Dave McClure
Eric Ries
Jamie Siminoff
Steve Blank
Thanks, this is a great post and the points on avoiding negative feedback sound spot on (especially as we are in a community that naturally likes to pick holes)
I was not quite sure what you mean’t with this bit:
“Targeting users who don’t need the must have experience”
When you first start, i figured you have to concentrate on a very specific set of users rather than worrying about the ones who don’t need it…
Thanks for the comment Pardeep. For the clarification you requested, I actually meant addressing the problem of targeting the wrong users.
Regarding the last part of your comment, I actually start out with broad targeting of all users who might benefit rather than narrow targeting of the ones I think will benefit most. Then I try to segment the users to see which ones consider the product a must have. Only at that point do I start focusing on targeting the must have users.
Good post. It goes to something I tell our customers (putting up landing pages for their startups) all the time. If they make the page too general they are going to get the wrong audience and the audience will start complaining about things that aren’t really important to their business.
It’s tough because there is rarely internal agreement about which problems are worth addressing or not. Most people agree that you can’t be everything for everyone, but what you should be and for whom is still very debatable. I try to use the signal of the “must have” users to make this decision.
Indeed. This post explains why I’m such a big fan of the “Get out the door” / “eat your own dog food” mentality.
After gathering a decent enough sample of beta clients – and setting up reasonable analytics to see potential show stoppers – it can become quite clear what should be focused on.
In my experience, chasing the dragon sometimes leads to multiple syringes. Ahem. In other words, there isn’t always a clear path to one “Must Have” use case. Like you said in your post, Sean, there are often competing “Must Haves” and sometimes competing audiences.
I’ve seen startups be focused on particular problems for funding purposes (over customer needs). In other cases, I’ve seen startups become profitable after chasing a “must have”, but not be profitable /enough/, and chose to build a different product and business model as a result.
Some “must haves” bring businesses down a path that leads to a small parking lot instead of a large mega-store. Being able to judge which “must haves” are worth pursuing is the art, governed by instinct, experience and luck.
I view that “must have” users are the ones that:
1. Have money to spend.
2. Have a talent/skill/problem gap that YOU are talented at solving for them.
Agree – and finally the ones who would be “very disappointed” if your solution were no longer available to them.
I love this comment Sean. I actually think multiple must have use cases is OK as long as they all map to a unifying benefit.
Skype is a great example of a company with lots of must have use cases. I’ve done research that shows at least 5 must have use cases including:
– Send and receive instant messages
– Make video calls
– Make mobile video calls
– Share my desktop
– Make voice calls over the Internet
Each group of people who identified one of these uses as their primary use case indicated it was a “must have”. In other words, over 40% of the people who used it that way said they’d be very disappointed without it.
Nice to have use cases are generally the ones I’d ignore and instead focus on doubling down on the must have use cases.
Completely agree Sean. It can be really painful ignoring obvious problems and bugs, but you cannot get lost in optimization while you are still on the hunt for product market fit. If something small is blocking you from learning or validating, then fix it, but focus on the boulders in the road, as Andres Glusman says.
And it is doubly true for deciding your use cases. In most situations, it is far better to be really good at a focused thing and for a focused set of customers, and expand from a solid base, than to be mediocre at many things and for many people.
Two questions:
1. It seems that many businesses think they intuitively know their customers “must haves” and are wrong. How do you get them to find out the real must haves?
2. Once understand what features are your “must haves” how do you determine that audience is large enough to support the growth you need?
Completely agree Giff. Must have for a few is way better than pretty good for all. Of course must have for a lot is ever better.
Thanks for the questions Lary.
1) Regarding how to uncover must have use cases… I have a pretty rigorous process for uncovering must have use cases that I used when I was a consultant. Since we need to do it for a lot of products listed on CatchFree, we’ve developed a tool that helps us do it automatically (that’s how I uncovered the must have Skype use cases in one of my other answers). I’ve made it available to a few non-freemium companies already, and plan to eventually offer it more broadly.
2) Regarding sizing the market for a given must have use case, that would probably take a while blog post or even a book. I think the key here is to focus on a must have use case rather than a must have feature. The same feature may support multiple use cases. For example, with Pandora I’d say that listening to music and discovering music are two different use cases – even though they require many of the same features. In my research, Pandora users say discovering music is much more of a “must have” than listening to music. They have many other ways to listen to music, so that is just a “nice to have.”
Great article, Sean.
It seems like a classic case of prioritizing the urgent over the important.
Your phrase “responsive to customer feedback – especially negative feedback.” really resonates with me. I have witnessed this happen at several companies.
A customer with a “hair on fire” complaint can wreck the development schedule for an entire day.
Chasing down a customer complaint:
1 Gives an immediate(often false) sense of accomplishment.
2 Insulates the development manager from executive criticism.
But this can come at the expense of building features that are key to the product’s long term success.
Makes a lot of sense to me. I agree in particular that you need to ignore a lot of feedback in order to find and focus on what really matters. You also need to understand the full context and real reasons behind the feedback, so that even when it’s worth addressing, you implement the best solution you can come up with, and the one that fits your vision, which might not be the same fix as the customer suggested.
What do you do if you are not solving a pain point, but creating a new, addictive experience? Games and social networks often fall in this category. They’re not solving a problem the customer has now, so much as creating something new that the customer won’t want to live without *after* they have it.
PS: You should blog more! :o)
Sean, do you still do any type of consulting work for the Saas startup space? If not, can you refer anyone you know who does?
Thanks
Pingback: Software Marketing Tweetables - 5 March 2012 | Smart Software Marketing
Enjoyed that read.Good to see this viewpoint…we have a core product as well..and now as we test it – have had many customer requests for a variety of things. We do go back to every customer and thank them for their feedback…but would say the on this point the customer is not always right. Don’t get me wrong on this point – we know and value the customers we have more than anything…but the requests we have had – while 70% are excellent and we will do, 30% (we feel) would make the product heavy, bloated and take it in a different direction that we wanted to go…so we will continue to interact with our users…a take a majority rule approach. While we have feedback from 3-5users per hundred…this means 95-97 do not come back to us with anything – but still use the service. Time will tell….great comments here too – look forward to more. All the best,
Great article, and great comments! The message of focusing on the must have use case resonates very well with my experience launching products in the past. In fact, I think the ability to focus on fewer things AND the right things is the most important skill a product creator can have.
One of the main things the article highlights to me is the importance of supporting fewer use cases to begin with (perhaps only one?) but nail the one(s) you support. Keep the app as simple as possible. I think Jack Dorsey once said ‘nail every detail, just limit the number of details’, or something like that.
The trick is knowing/finding the ‘must have use case’. Having a bunch of use cases in your app to try out together suffers from the problems discussed here – the more use cases and features you support, the more ‘problems’ you’ll get that are not relevant. Fortunately I learned here that Sean has a tool for helping find the must have use case, so I’ll have to go and check it out!
One question: If you keep it simple from the outset, and nail the execution of a use case, BUT it’s not the ‘must have’ use case, what do you do next? How do you react? I guess this drifts in the ‘when and how to pivot’ topic?
Thanks so much….