Why Every Startup Needs A Killer Product Use Case

Startups often assume a use case is just to tell customers how to use their product. It's soooo much more than that. Finding the right killer use case establishes a position of leverage that enables small startups to take on global industry leaders and win.

Untitled (22).png

Building a startup is an all-consuming task. This fixation leads product builders to assume that everyone will realize how obviously valuable their product is in just one glance.

They won't.

Users can't figure this out for themselves. As the product builder, it's your job to (a) tell them why they should care about your product and (b) when they should use it. For almost all products — including yours — your users don't initially care how it works. All they want to know is 'why' and 'when,' not 'how.'

The 'when' I refer to is the product use case — the occasion or context where your product is the perfect solution to the problem your target users are faced with.

 

What is a killer use case for a product?

Product use case can quickly become product use cases. This blog post will explain why adding that 's' is a shortcut to insignificance when building a new product. Instead of throwing together a landing page with half a dozen ways target users could implement your product, the best startups find a single killer use case for their product.

Not all products have a killer use case, but all startups need one. Your product has a killer use case when it's the perfect solution to a burning user problem. This infers that there is a reason why your product is better than any other solution for this problem. This differential could be a:

  1. Feature Advantage

    A technical aspect to your product's design or functionality that makes it faster or better for this specific problem that users care a lot about solving. An example of this is Typeform, the design-led conversational survey tool, which offers a better design and more customization options than industry leader SurveyMonkey.

  2. Cost Advantage

    A well executed pricing strategy can act as a differential advantage. Note that this doesn't always mean cheaper; competing solely on lowest price commoditizes a product category and usually leads to an unsustainable race to the bottom. An example of cost advantage done well was AVG's antivirus product, which pioneered a freemium model in the mid-2000s and put antivirus software on almost every home and office computer. This freemium model leveraged price as part of its distribution strategy and gave users the opportunity to experience their product's value so that there was a natural path to upgrading to their paid version.

  3. Support Advantage

    Don't be fooled by this misnomer; support advantage today extends far beyond customer support. Products that offer community, personal assistance like customer success managers, or increased customization and flexibility are driving forward a new point of differentiation. Flexible online knowledge management platform Notion catalyzed their growth by putting community at the core of their strategy.

  4. Status Advantage

    This has always been a factor in product strategy but more recently has become a leading point of differentiation among software startups. Superhuman is an email tool that combined grey-labeling and a huuuge sign-up waiting list to create an exclusive cult status surrounding their product.

 

Trying to find your killer use case? Our newsletter shares data-driven approaches for finding Product/Market Fit faster. Subscribe to get our latest guides delivered to your inbox:


 

Where does killer use case fit into the overall product strategy?

A killer use case is one of the core components of your proposition. It's the intersection of your differential advantage (which we just explored), a well-defined persona (as explained here), and a high priority problem.

Untitled (23).png
 

Why is a killer use case important?

From a micro perspective, the killer use case tells your users exactly what problem your product solves so they understand the context of your value proposition. Unless you tell your users where your product fits into their life, they aren't going to understand how it adds value to their life.

At a macro level, your killer use case is what enables you to define the territory that you plan to take from industry incumbents. This is commonly called "unbundling" — the tactic of taking one use case from an existing tool that offers multiple solutions and providing a product that not only offers more value to customers but also ends up growing the total market opportunity. This is David vs Goliath Mentality; you can only beat Goliath if you focus all of your effort on one point of leverage.

Untitled (24).png
 

Examples of Killer Product Use Cases

Take one quick look at Intercom's website from February 2017 and you know what they do.

^ Intercom's landing page in February 2017

^ Intercom's landing page in February 2017

By this stage, Intercom had closed a $50 million Series C round and they had over 100,000 monthly active users — 17% of which were paying customers (according to Business Insider). Even with all this traction, their killer use case remained crystal clear; Intercom makes customer interaction personal and simple.

It should be sinking in by now that your killer use case is the rudder that gives your ship direction. Let’s look at some of the common mistakes that people make when it comes to defining their startup use case...

 

Pitfall #1: Picking more than one product use case for your startup idea.

First-time founders often look at big tech companies that promote multiple use cases for multiple customer segments and assume they can do this too. Look at Zoom as an example:

^ zoom.us landing page, June 2021.

^ zoom.us landing page, June 2021.

But you have to remember that we're looking at 'Zoom the Scaleup', it's 'Zoom the Startup'. They can have 8 propositions across 4 personas because their market already knows who they are. Mention the word "Zoom" to someone and they'll think of the online video call platform before they even consider former connotations like a camera's zoom feature or a speedy cartoon character.

Category leadership opens up enough breathing space to allow large companies to expand across multiple segments and use cases. However, it's this same breathing space that lets David startups pick their territory against Goliath incumbents.

But Zoom wasn't always Goliath. Back in June 2014, 'Zoom the Startup' was a new product making video conferencing 10x better for companies doing business online.

^ 'Zoom the Startup' (June 2014 via the Wayback Machine) has a clear focus on business video conferencing

^ 'Zoom the Startup' (June 2014 via the Wayback Machine) has a clear focus on business video conferencing

Let's squash this myth right now — these giant companies all started off with one killer use case. The 7 other propositions came much later.

 

Pitfall #2: Expecting users to be able to figure out the use case on their own.

Another common pitfall is believing that users can figure out the right use case on their own. The extreme version of this is when a product offers no use case direction at all, but there's a more subtle manifestation of this pitfall that is far more prevalent.


Early product traction is usually the result of experiments that lead to the right combination of persona, problem, proposition and product. It's extremely rare that the customers you get from this experimentation are all from one segment though. Product builders are deep in the trenches, so when they see these incoming signs of early Product/Market Fit, they call in the big guns (venture capital investors) and add fuel to their rocket (a giant seed round of funding). The trouble is, because they're serving multiple segments, that rocket doesn't ascend as well as planned...


A great example of this scenario is Hubspot. Brian Halligan (the Co-Founder & CEO of Hubspot) explains that even though they found their 'pull' of organic traction within 1 year of starting, it took them 6 more years until they found a way to scale their customer acquisition strategy without reducing their lifetime customer value (aka their LTV:CAC ratio). That basically means that if Brian's team started spending more money to get new customers, they started earning less money for each of those customers. This prevented Brian from accelerating Hubspot's growth, leaving them in limbo for years.


"When we hit the gas (hired faster), the math would get worse. When we slowed down, the math would get better. We had an interesting business, but without the ability to hit the gas pedal, we’d never be able to truly scale and build the company that we envisioned." — Brian Halligan, Co-Founder CEO of Hubspot.

Hubspot's landing page in June 2011 (via Wayback Machine). The first sign that they doesn't have a clear killer use case is the phrase "all-in-one," which translates to 'we do multiple different things kinda well but for lots of different types of people.' Even within their "Customer Successes" section you can see two types of people: marketing managers and business owners.

Hubspot's landing page in June 2011 (via Wayback Machine). The first sign that they doesn't have a clear killer use case is the phrase "all-in-one," which translates to 'we do multiple different things kinda well but for lots of different types of people.' Even within their "Customer Successes" section you can see two types of people: marketing managers and business owners.

Brian calls the solution they built to get over that 6 year hump the 'Mary-MOFU-Monetization Playbook,' which is a fancy way of saying that they made three important decisions. The "MOFU" bit in the middle is what's relevant to Killer Use Cases.

Up until this point, Hubspot had 5 different product teams building tools for two different use cases — one for 'top of the funnel' marketing (tools that drive visitors to your website) and one for 'middle of the funnel' marketing (tools that turn those visitors into sales leads or users). When Brian set out to decide which of the two use cases to eliminate, he found a surprising answer...

"Back in 2011 when we were grappling with this stuff, our 'top of the funnel' tools were way better than our 'middle of the funnel' tools. But, when we looked at the data, we noticed that customers who used our crappy 'middle of the funnel' tools had better retention rates than customers who used our really good 'top of the funnel' tools." — Brian Halligan, Co-Founder CEO of Hubspot.

^ Hubspot in June 2013 (via Wayback Machine). Their proposition is soooo much clearer after doubling down on one use case and one persona.

^ Hubspot in June 2013 (via Wayback Machine). Their proposition is soooo much clearer after doubling down on one use case and one persona.

Thinking back to Pitfall #1 again, if you look Hubspot's website today you'd never realize how essential this killer use case decision was for their initial product success. Use case strategy is extremely different for early-stage startups compared to growth-focused scaleups.

^ Hubspot CRM landing page in June 2021 (via Hubspot.com). This is just 1 of 5 Hubspot products and it alone has 6 different target personas. Hubspot has built an entire organisation to succeed with such a granular level of segmentation (however notice their positioning has backpedaleds to "with something for everyone"... 👀 This is how space opens up for a new startup to claim that territory with a better specialized product).

Moral of the story — sitting on the fence with more than one use case doesn't keep multiple opportunities open for you, it creates an 'optionality tax' that can stifle your growth for years.

 

Searching for Product/Market Fit? Join our newsletter to discover what it takes to build products users love:


 

Pitfall #3: Product templates are not product use cases.

Short and sweet pitfall to finish us off; most early-stage products implement templates as a crutch to avoid leaning on one killer use case with all their weight. This is particularly relevant for two types of products: ones that haven't hit their 'pull point' yet and those that aren't based on creativity or customization (like website builders or graphic design products).


We made this mistake ourselves at OpinionX. We were getting requests from users to add templates to our stack ranking tool because they weren't sure how to use our product. These feature requests were trying to point out to us that people didn't know what they should use OpinionX for — not that they wanted a one-click template gallery for more convenience. Feature requests are a route to understanding the barriers in your product, not a pipeline of ideas to fill your roadmap with.

 

Why use case determines your entire customer acquisition strategy.

Ok, so we've started to scratch below the surface on the importance of a product's killer use case; it provides much needed direction for early adopters and defines the territory that you're going to take from your industry incumbent. Now we'll explore why the decision you make for your killer use case informs your entire customer acquisition strategy.

In early 2021, we were faced with a difficult decision at OpinionX. We had started to see signs that we were nearing our 'pull point.' We could see organic traction and a fit on the different ingredients we were putting into our Product/Market Fit recipe (persona, problem, proposition and product). However, as Product/Market Fit tends to be, things were a bit blurry. We weren't sure if our killer use case should be "validate your new product idea" or "find product/market fit faster."

Now, you might think that these two problems are pretty much the same thing, but there's one massive difference — validation happens before you start building the product, finding product/market fit is an ongoing process that takes place while you're building the product.

Our primary user acquisition channel is SEO via content marketing. There are plenty of good keywords to focus on within both of these use cases, but for SEO to work you need to be able to intercept a 'signal' from your target user (like them searching an answer to their question).

Not only does a product builder decide on their validation method before they start building a product and therefore there's a way smaller signal to intercept, it often doesn't even happen at all. Product/Market Fit, on the other hand, is a process that has countless 'signals' along the way as product builders hit pitfalls and look for solutions. Really, working towards Product/Market Fit is an ongoing process that never actually ends as you expand to new segments or use cases later on.

Therefore, if we picked "validate your new product idea" as our killer use case, we would need to find other channels to reach our target users (like partnerships and workshops so that we could get in front of users before they started working on their next big idea). For "find product/market fit faster," people hit problems at every step along the way, so we have a bunch of 'bottom of the funnel' searches that we can use to offer people a solution (which I assume is working if you found this article 😉).

 

How to find your product's killer use case?

The best killer use case is the intersection of three vital ingredients: (1) a burning problem experienced by (2) a well defined niche segment of target customers that (3) your differential advantage makes your product the best solution to solve.

There are a number of common approaches used to identify and define a killer product use case:

  1. Product Metrics

    Reactive research is pretty common for segmentation at larger companies that already have established processes for tracking and analyzing quantitative behavioural data with tools like Mixpanel or Google Analytics. This is the approach that Hubspot used to figure out that their 'middle of the funnel' products had stronger retention rates than their 'top of the funnel' solutions. If you've got loads of behavioral data, check out Mixpanel's guide to quantitative behavioural segmentation.

  2. User Interviews

    Most teams don't have loads of user data to figure this out — but even if you do, quantitative data can't tell you why users behave the way they do. This means that almost all teams end up conducting user interviews to understand each segment's unique needs.

    Your objective during these interviews is to identify the most important problem that your interviewees are trying to solve within the activity/occasion that you're focusing on. Best practice is to ask non-leading questions that encourage interviewees to talk about their lives and hope that they bring up the problem independently, therefore validating that it is one of their priority problems. Do enough of these interviews and you'll see if the problem comes up proactively for most interviewees.

    User interviews might seem easy to conduct but they are incredibly easy to misinterpret, lead astray with your own biases or just screw up by asking the types wrong questions. If you're going to take this approach, PLEASE go read The Mom Test by Rob Fitzpatrick first. It's a super short book that will help you avoid these super common mistakes.

  3. Customer Problem Stack Ranking

    When you're doing those user interviews, you're trying to see if the problem you plan to solve is one of your target customers' most important, burning problems. If you're solving a burning problem, you'll have no problem getting customers to pay you.

    Instead of hoping to spot these patterns in tens of hours of interview transcripts, Customer Problem Stack Ranking is a great lightweight framework from the product team at Stripe to consider instead. It gets target customers to stack rank a list of problems so that you can which ones are the highest priority for the largest group of people.

    Customer Problem Stack Ranking turns weeks of interviews into one easy afternoon of work by using a data-driven approach to help you pick the right problem. OpinionX is a free stack ranking tool that not only helps you to analyze your stack ranking results in just one click, it also lets your participants share new problem statements that you missed when setting up the survey.

^ When you use Customer Problem Stack Ranking, this is how easy it is to identify the right burning pain point to build your Killer Use Case around.

^ When you use Customer Problem Stack Ranking, this is how easy it is to identify the right burning pain point to build your Killer Use Case around.

We spent over 7 months doing 100+ user interviews to validate our startup idea and build our original value proposition. In under 2 hours, we used Customer Problem Stack Ranking to figure out that the problem we said our product solved was one of the least important problems according to our target customers. After rewriting our website to align with the highest ranking problems, our traction multiplied multiple-fold. Read that full case study here.

 

Conclusion

No product builder is immune to the great 'Killer Use Case Decision.' Although we may try to avoid it, the decision is inescapable.

Untitled (32).png

^ David, the co-founder of Mo.na (a platform for creators to sell their skills), thankfully put me back in my place when I tried to avoid the 'Killer Use Case Decision' by sharing the counterintuitive fact that the smaller the initial opportunity seems to be, the better.

I spent a fair share of the first year building OpinionX fighting to avoid picking just one use case — even DMing founder friends to try and get some self-assuring confirmation that it was a decision I didn't have to make yet (as you can see, I was wrong).

Don't be like me; search out your killer use case with clear purpose so that you can accelerate the growth of your startup. My final piece of advice — the first thing you should do is identify your target customers' biggest problems so that you can find that killer product use case faster.


OpinionX is a free tool that helps product builders find Product/Market Fit Faster. It identifies your customers' biggest problems so that you can focus on solving the problems they actually care about solving. Get started today and create a free stack ranking survey in under 60 seconds (no credit card required).


Previous
Previous

How to find users that represent your broader userbase

Next
Next

Should you build a feature for just one customer?