Use cases — The foundation of your growth strategy

The very first thing you have to define is what problem or problems your users are solving with your product. Every product’s main purpose is to solve problems for your users — knowing them is key for all further analysis.

Make sure that you let your users define the problem. It’s good for you as a founder or growth marketer to have your own ideas of what value your product or service provides. But ultimately your job is to serve your users in the best possible way — so how they frame their own problems matters most.

Don’t define your problem too broad or too narrow

How you define the problem determines the scope of the use case. It should bring clarity to your decisions. Aim to define the problem broadly enough to allow for some breathing room in strategic decisions but narrow enough to serve as a guard rail to guide you.

Let’s look at a hypothetical example for Uber. If they would have defined the problem as “I want to get from a to b” it would have been way too broad to generate any meaningful insight. Places a and b could be a few hundred meters or a few thousand kilometers apart.

Uber could have evolved into a platform to book flights, train tickets, long-distance busses etc. It would have opened up an almost infinite field of possibilities, thus creating confusion instead of clarity.

An example of how Uber could have defined its users’ problem too narrow is “I need a special car driving me to church on my wedding day.” This would have significantly constrained the world they are operating in, leading to Uber becoming a niche business instead of the multi-billion US-Dollar ride-hailing business it is today.

Getting the scope of your problem statement right

So how do you get the problem statement just right? It should be narrow enough to help your team(s) focus and align, and broad enough so that they don't miss the bigger picture and wider audience.

The following examples can help you get a feeling for what scope to aim for:

• Uber: “I need a ride for a special occasion”. A special occasion massively limits the possible transportation options but is broad enough to apply to situations from students going to prom, to executives going to high-end company or networking events.
• Spotify: “I want to listen to music”. It clearly cuts off audiobooks or podcasts (which could be a separate use case). On the other hand, something like “I want to organize my music into playlists” would have been too narrow. It would have led Spotify to focus on how to best create and maintain playlists. It would have aimed to monetize playlists and define retention and engagement metrics around playlist usage.
• Pinterest: “I have a project (e.g. wedding planning or re-designing my apartment) and quickly need a lot of inspiration.” A project is generic enough to allow for diverse content. The inspiration part excludes e.g. e-commerce functionality and hints at the importance of content recommendation and curation.
• Eventbrite: “I need a simple way to organize free events and track attendees.” The type of event could be anything — a networking event, meetup, poetry slam, or a vernissage at an art gallery. But it also lets us focus on free events (i.e. no payment functionality needed) and features around attendee tracking.
• Zendesk: “I have to ensure a good performance of my team and regularly report on KPIs and metrics.” This would be the view of the person leading the support team at a small-to medium sized company (→ the persona, which we’ll tackle in the next section). It’s distinct from the problems of the support agents but constrains the scope to tracking and reporting of metrics in the widest sense.

You can have more than one problem

While reading through the above examples you might have thought “but they solve more than just this one problem!” — and you’re absolutely right. Unless your product is super niche chances are people use it for more than just one purpose.

Some might be tangential, such as “I want to listen to podcasts” in addition to Spotify’s “I want to listen to music”. There are also a lot of people who don’t just book an Uber Black for a special occasion but use UberX Share (formerly Uber Pool) because their problem is “I need to commute to work”.

Other times, the angles might be completely different. Pinterest — and most social networks for that matter — are not only used by people to consume content. They also offer a suite of solutions for companies who want to advertise their products.

So, another problem could be “I want to increase sales for my product” which would be solved by campaign management features, reporting, and tracking and targeting functionality. That’s vastly different from building a product that people use to quickly get a lot of inspiration for a project they’re working on.

Collect problem statements through qualitative research and surveys

Remember that your users should tell you what the problem is. Your main job is to collect their input and then properly frame the problem statement.

To get the input, surveys and qualitative research are the way to go. Maybe you have some previously conducted surveys and user interviews, to gain insights from. If you don’t have existing data or you want to freshen up some user feedback, keep the following points in mind:

• Interview multiple user types to get different problem sets and perspectives. Examples are:
  • Existing, happy users who are engaged and actively using your product or service. You already provide a solution to their problem, so they will help you understand which use cases you are already serving today.
  • Target users. Those are people who you’d like to get as customers but aren’t reaching today. This will give you input on what problems your product isn’t solving today but could be in the future. It is valuable input e.g. for product roadmap decisions.

In any case make sure to listen to your users describe the problem in their own words.

• When performing user interviews and surveys always ask open ended questions. Prospects and users might not be consciously aware of what problem they are trying to solve. To get valuable info you can ask questions around how users experience your product:
  • "What made you sign up for the product? What did you expect this product to do for you?”
  • "Before using this product, what did you use instead?”
  • "When do you typically use this product? What is going on before or after that motivates you to use it?”

While having a list of questions prepared gives you kind of script to run through and make you feel safer in the user interview, it’s by no means the only or even best way to do it.

I’d highly recommend watching or listening to the episode with Teresa Torres on Lenny’s Podcast; specifically minutes 36:20 to 40:30. She explains (and even shows in a short live role play) how user interviews should feel more like you’re having a beer with a friend than a completely pre-structured interview. Highly recommend watching it!

A word on bias

You are an expert in our own product and probably have a fairly well-defined idea of your users' problems and how your product is solving them. Be careful to not let your own assumptions seep through in customer interviews and surveys. You don’t want to “lead the witness” by nudging them towards clear problem statements.

Being aware of the fact that you’re biased is already half a battle. Before your start the research phase, write down all your assumptions about the problems and use cases your users (or target audience) have. This will make you aware of your own thoughts. It’s also a good reference after talking to users to distinguish between what you expected them to say vs. what new insights they gave.

Also, you shouldn’t completely ignore your own opinions and assumptions — they will often be right. You should treat them as hypotheses that you’re validating or invalidating during customer interviews.

One way you can try to avoid subconsciously pushing your bias onto the users is to apply the five whys technique. After the user answers your question, ask why a few times to really get to the root cause of what they’re thinking rather than staying superficial.

Of course, be mindful and proceed with tact. You don’t want to come off as an inquisitive toddler. The goal is to research the problems from a first principles approach. Read through this great explainer of first principles with examples.

Give your problem some context

One last tip before we’re moving to the persona part of the use case map: Be careful to not define your problem too functional. Give it some context and a “why”. This will not only help you avoid overly broad definitions but will also help you in the last step when we’re defining the frequency.

Consider the problem “I want to invest in the stock market”. It is not a bad problem statement by any means. In terms of scope, it’s comparable to “I want to listen to music” for Spotify.

However, there is a big difference between “I want to trade and make speculative buy/sell decisions” or “I want to invest long-term to build a capital stock for my retirement.”

Their motivation to use the product can differ as well. Are they using it out of curiosity? To get rich? To diversify? For those who want to get rich I’d expect the usage frequency to be high but retention to be relatively low.

In call cases user types, their motivations, and in what frequency they interact with your product will be worlds apart. All three are very different use cases.

Now you know what problems your users have. But who are those people? Who are your current users or your target audience?

It’s an important piece of the puzzle because it provides context around the problem (see the Zendesk example above). It can also influence other parts of the use case: The alternatives, the why, and the frequency.

Personas consists of key differentiating demographic or firmographic attributes of users who experience the problems we defined before. So, the information should come from the same people you have talked to or surveyed before.

Some examples of information and attributes you’re looking for:

• For B2C products you only focus on the consumer:
  • Age
  • Household income
  • Geographic location — e.g. country, urban area or countryside etc.
  • Current stage of life or important life events that happened recently — e.g. started college, got married, moved to a new place etc.

• For B2B products you should get information about the company as well as the user:
  • Number of people in the company and team the user is working in
  • Industry
  • Average annual revenue
  • Growth rate — doesn’t has to be exact but it makes a difference whether it’s an established company growing 3% per year, a scale-up with 20-30% of growth or a high-growth startup with >70% annual growth rate. These values should only give an idea of what brackets you could think about.
  • Function/role of the user
  • Their seniority

Exemplary personas

Usually, when building our use case maps, we define personas pretty concise. In that way they differ from the more elaborate user personas that you might know — often including details like a fictional name, picture, or hobbies.

Here are some examples of use case personas:

• Airbnb: Owner of a second home or has a spare room in their house. 20 to 50 years old with an above average income.
• Slack: Team lead, project owner, or project manager. Often works in a marketing or product-related role. The company size tends to be small to medium (<2000 employees) with a progressive mindset towards technology (e.g. not so much manufacturing or construction firms).
• Eventbrite: Recruiters, community organizers (e.g. in co-working spaces), social coordinators, bar/pub owners (for special events), art gallery owners
• DocuSign: Works in the legal team (any company size), founders, senior sales executives who have to draft and send out contracts.

How to handle multiple personas for the same problem

Sometimes a clear persona crystalizes from your research. A lot of times, however, multiple different personas experience the same problem. Now the question is: Do they belong to the same use case or not? For that we’ll look at their alternatives, motivations, and their natural usage frequency.

Option 1: The personas have different motivations to use your product, consider different alternatives or have a different natural frequency → then split your use cases.

Let’s look at Zendesk again. They provide a full-service solution for support team: From live chat on the website, over support ticketing functions, to CMS solutions to host your knowledge base and help center. One of the high-level problems Zendesk solves is “I want to provide efficient, high-quality customer support.”

But there are multiple, very distinct personas who experience the problem: Support agents in a team, support executives, knowledge base managers, or founders/small business owners. Their alternatives and usage frequencies are diverse:

• Support agent in a team: Has to easily see all their relevant tickets, utilize canned responses for standard questions, and be able to collaborate on tickets with their colleagues. They’re doing this on a daily basis.
• Support executives/team leads: They don’t actively work on support tickets but are interested in their team’s performance. They need dashboards, build reports, and drill down along multiple dimensions. They’re probably doing this weekly. Team lead functions usually only exist in medium- to large-sized companies, not a startup with 20 people.
• Knowledge base managers: They’re not working with tickets and reports at all. Instead, their main focus is on the content management system that powers the company’s help center.
  They need a powerful text editor, some design capabilities, approval features before content can be published and an edit log. You’d typically only have dedicated people for this in companies with >100 employees and they’d use it daily.
• Founders: They combine most of the requirements of the other personas, though usually need a less powerful solution where the core features would be enough. They tend to have smaller budgets than dedicated teams in larger companies The usage frequency would likely also be daily.

So instead of using these distinct personas for the same problem…

… you should split them into their own use cases and have separate problems, personas, and later also alternatives, motivations, and frequencies for each:

Option 2: The personas don’t substantially differ in their behavior and desires → then keep them in just one use case.

As an example, we can look at Spotify: The problem they have identified is “I want to listen to music.” There are lots of different personas for that, from high-school students to stay-home parents, all the way to business folks who travel a lot and listen to music at the airport or in the train.

Still, their alternatives are pretty similar, their motivation to use Spotify is roughly the same, and most of them will listen to music on a daily (or almost daily) basis. Podcasts are distinct enough to create a new use case for them.

Criticism of user personas

The concept of user personas has been around for decades and has drawn quite some criticism over the years. It is often seen as a stereotypic oversimplification of reality, leading to a false sense of confidence in how well you know your users.

Often times, personas also don’t really explain why somebody is using your product. Multiple other frameworks have emerged to provide better alternatives to user personas — most notably user stories, job stories, and jobs to be done (JTBD).

When creating the use case maps, we’re not building super detailed user personas in the classical sense. The main goal is to understand what group(s) of people experience the problem, why are they using your product and in what frequency.

Use anti-personas to accentuate who this use case is for

The personas we have identified give us a decent understanding of the type of person experiencing the problem. To further shape them you can additionally define anti-personas. Those are user groups who explicitly don’t have the problem you’re solving for. Or at least they don’t belong to this use case.

If we go back to the Airbnb example, one use case is centered around casual hosts. Their problem is “I want to earn a side income” and we have defined the persona as someone who “owns a second home or has a spare room in their house. 20-50 years old with an above-average income.”

An anti-persona for that use case would be professional hosts.

Their problem is “I want to efficiently rent out and manage a portfolio of properties.” While some of the basic feature requirements are similar to those of casual hosts, they might also need solutions around managing cleaning personnel, insurances, functionality to help with their finance and accounting duties (e.g. certain data exports) or in-app message automations.

The persona of a professional host might be defined as “owner or manager of a larger portfolio of properties which are rented out as a full-time business. Usually in urban regions.”

Another very helpful way to create anti-personas is to identify people who think they are the target audience but actually are not. They have some variation of the problem but aren’t a real fit. For example, an anti-persona for Airbnb’s “Casual Host” use case could be someone who has a second home but wants to rent it out long-term for multiple years.

Anti-personas can have a similar problem as “good” personas but ultimately one the product was not designed for. They tend to be leads with low conversion rates, a lot of complaints, feature requests that don’t fit your roadmap, and ultimately higher Customer Acquisition Costs and lower Lifetime Value.

Note that an anti-person is not someone who should not use your product at all. They are just a group of users that doesn’t fit the use case you’re defining them for, thus sharpening your real persona.

At this point we know what the problem is and who experiences that problem. Now let’s figure out how your personas solve this problem if your product doesn’t exist.

Knowing the alternatives is valuable for multiple reasons:

• It helps to position and differentiate your product. Your product or service does not exist in a vacuum — people will evaluate it against other possible solutions for their problem. Knowing what those are helps to drive home what makes you unique.
• Potentially your market is way larger than you think. If Slack defined their alternative as “emails” instead of “other messaging apps for work”, their market size suddenly got 1000 times larger.
• Alternatives inform other parts of the use case map. Knowing how often people use these other solutions gives a good estimate for your natural frequency and the motivation for choosing your product.

Alternatives are not competitors

A common misconception is to equal alternatives with competitors. Often the real alternative is not a competitor, i.e. another product that solves the problem in a similar way to yours. Instead of other products, we’re interested in alternative ways people are solving the problem.

These examples help make the difference clear:

• The main alternative to Slack was not — and still isn’t — other messaging apps. It’s mostly emails and meetings.
• DocuSign did not compete against HelloSign and other e-signature products. The primary alternative for their customers was sending a PDF via email, having the recipient print it out, sign it with a pen, scan it, and send the signed version back to you via email. In some cases even signing the document with pen and ink and then physically shipping it back through a courier or a postal service.
• The no-code website builder Webflow did not only compete with other no-code website builders or visual builders in Wordpress. Established alternatives, especially for high-quality sites were freelance or in-house developers who would be tasked with building landing pages and marketing websites.
• For the “reader” persona, Substack is competing with Netflix, YouTube, Twitter, media websites like NYT, The Verge, Politico etc. All those are places where people can stay up to date with news and trends in certain industries, get opinions, political analysis, or learn about topics they’re interested in.
• Even physical books are not only competing against e-books. Alternatives are television, TikTok, Netflix, YouTube, Twitter, Substack, or podcasts. All of them provide fiction and non-fiction content to entertain, educate, or just occupy your free time.
  Frankly I’ve never been particularly passionate about books. But in recent months my entire consumption of written words has shifted to long-form content from a range of blogs and Substack publications.

How to discover alternatives

As for all other parts of the use case map, the best way to identify alternatives is to ask. Interviewing happy existing users but also people from your target audience who are not yet using your product gives you a broad set of insights.

When talking to existing users who are satisfied with your offering, you should learn about their experience before using your product. Questions you could ask include:

• How did you solve the problem back then?
• What behaviors have you stopped since they started using your product?
• Are there any products they stopped using because of yours?

For example, Slack users might say they used to send and receive lots of group emails that naturally evolved into longer email threads with content that’s irrelevant to most of the CCed people.

Users of Miro (a collaborative online whiteboard tool) might have used physical whiteboards before — and maybe zoomed in on it during calls — a shared Google Slides document, or even taken pictures of drawings on a sheet of paper and sent them around.

To understand what alternatives are being used today, talk to people from your target audience. Those are people who you’d like to have as users but who are not signed up for your product (yet).

Ask them about the last time they experienced the problem. Then let them walk you through how they solved it. Talk to them about some more situations where they faced the problem. You can learn additional alternatives from it.

You can supplement these user insights by doing research online. Regardless of use case maps you should know where your users and target users are hanging out online. What are their preferred communities and platforms. Are they using Twitter, subreddits, dedicated Slack groups, Discord servers, or forums?

The problem you’re aiming to solve should be common enough for people to talk about it. Find these discussions. If they discuss the problem, they will inevitably also talk about how to solve it. This gives you a good idea of what alternatives exist, and which ones are the most common.

While this kind of online research can lack some of the context you get during user interviews, it’s a good way to increase your sample size.

Why are people choosing your offering over the alternatives?

Answering this question helps you understand how your product appeals to users and what makes it unique. We’ll look at two parts separately: The core motivations (what do they gain from solving the problem) and the differentiators (why they pick your product, what separates it from the alternatives).

The why is crucial for everyone who works on growth and product. It informs key areas of the growth and product strategy:

• The positioning of and messaging around your product, to emphasize how it is different from the alternatives.
• Your retention and engagement metrics: The why helps us defines what value users get by using your product to solve their problem.
  • Later on, we’ll use the why to determine the core actions. They are the foundation of your retention metric.
  • Your activation metrics will also tie back to the why and differentiators of your use cases. A user is considered activated once they have experienced your value proposition. This value proposition depends on your why.
• Your retention and engagement strategies are aimed at delivering value to users. Thus, they also rely on insights from the Why.

The core motivations

All users have one or multiple core motivations why they’re the solving the problem with your product. It’s the value a user gets from using your product.

We can split these core motivations into three distinct categories bases on the type of value you provide:

• Personal: The motivation is considered personal if the user gets some personal value from your product. This could be not having to do an annoying task anymore, or saving time.
  For example, Doodle and Calendly eliminated the need to compile a list of possible meeting times, send them to other people, and potentially repeat this a few times until you found a slot that suits everyone. Calendly users have a personal reason to use the service.
• Financial: Financial motivations often are the most straightforward ones. If you provide a monetary benefit to your users, then that’s a strong and easy to communicate motivator.
  Uber drivers make money. Shopify or Etsy sellers make money. Airbnb hosts make money. The core motivation to use these products — from a supply side at least — is a financial one.
• Social: Almost every human seeks social status and recognition from others. According to William Storr we’re all playing status games. Your product falls into the social motivation category if status and recognition are the users’ core motivators.
  People buy an Hermés bag for 20,000 USD because of what it says about them. I’d even argue that most people who order oysters and champagne are driven by the message it conveys — either in the restaurant or through posting pictures on social media — and would prefer the taste of a good pizza with a glass of wine. But I digress.

Since these three categories are fairly broad, we can further break them down into more specific types:

• Personal
  • Entertainment — I get more fun and avoid boredom.
  • Communication — I communicate with others (for selfish reasons).
  • Information — I gain knowledge or other valuable information.
  • Flexibility — I gain flexibility of something I value.
  • Time — I save time or get time back.
• Financial
  • More transactions — I get more transactions from my existing audience.
  • Saving money — I save money by lowering costs.
  • More customers — I make money by getting access to new customers.
  • Loss protection — I prevent loss of capital (insurance).
• Social
  • Recognition — I gain additional recognition, respect, reputation.
  • Connection — I gain a greater sense of connection/belonging.
  • Competition — I get a feeling of winning or achievement.
  • Confidence — I gain a sense of confidence.

Differentiators

Core motivations say why users any solution to solve their problem, i.e what they gain from solving it at all. Differentiators say why users choose your product. What makes you stand out compared to the alternatives?

Understanding why a user picks your product helps uncover the core actions that create value, define your positioning and messaging that differentiate your product from the alternatives, identify the value metrics that you charge for — and many other elements of your growth and product strategy.

A lot of companies struggle to come up with compelling differentiators. Simply stating “we are better”, “our product is easier to use”, or is of “higher quality” doesn’t cut it.

Those statements are too generic, too nondescript, too common. They are not convincing. To convince potential users, your positioning has to highlight contrast and be specific.

• Airbnb: I can earn a side income through property I already own, with low effort and no long-term commitment.
• Pinterest: I can find things on Pinterest I can’t find anywhere else. It’s also easier to discover more content based on what I like.
• Loom: It’s way faster, more personal, and more creates more effective messaging than the alternatives. Also, it’s asynchronous so we don’t have to agree on a meeting time.
• Thumbtack: I can access a larger pool of home professionals and can compare quotes from multiple professionals.

Let’s look at those four examples to see how the problem, persona, alternatives, and the why play together:

Casual hosts are people who own a second home, or maybe just have a large house with a spare guest room. They want to earn a side income by renting out these spaces but don’t want a long-term commitment.

Maybe they want to use their second apartment themselves as a vacation destination a few times per year, or they can earn more by renting by the day. That’s why they don’t put it onto the normal housing market and rent it out to classic long-term tenants.

The core motivation here is clearly a financial one — they want to get access to the pool of potential customers Airbnb offers.

Also, renting out through the platform requires only low effort, and the more often you do it — assuming good quality — the more new prospects you’ll get through Airbnb’s rating system.

One of the classic use cases for Pinterest is to collect inspiration for specific projects. Those can be weddings (e.g. table and venue decoration, invitation card design etc.), re-designing your apartment, ideas for a DIY project you’re working on, or design ideas for your garden.

The alternatives aren’t really compelling: You could get some fitting visuals through Google Images, dedicated communities such as subreddits, forums for gardening or DIY stuff, or sifting through dozens and dozens of YouTube videos.

The key differentiator of Pinterest is the almost infinite, on-demand supply of images around lots of interests and niches. Through the personalized recommendations you can also discover more related content based on what you like. And through “pinboards” you can organize and curate pins that you like.

Within this use case Pinterest provides information (e.g. all the wedding venue design ideas you have seen), as well as a sense of confidence. Since you have seen so many alternatives and possibilities, you’ll be more confident in the venue design that you ultimately choose.

Loom lets you record your screen and — if you want — simultaneously a recording of your front camera at the same time. You can then easily share this video with others a unique link.

A lot of people want to send personalized messages through email or text, maybe even with a screen recording. But it takes a long time to type out these messages, or to record and then send the video; which is only the screen anyway, hence not very personal.

This is the case for sales reps for sales pitches, product managers for product demos or messages to their team, or even support agents who want to record a quick walkthrough of the solution instead of typing everything out with a lot of screenshots.

With it’s easy to use solution, Loom provides the personal benefit of more flexibility in how to deliver your message, and a lot of time saved compared to the alternatives.

Thumbtack is a platform for consumers to hire professional services around the house such as plumbers, electricians, gardeners, or handyman services. They are so called “Pros”. The second use case is for small business owners to offer their services (see here).

Thumbtack is mostly used by your working professionals, usually in cities or suburbs. It provides flexibility: You can always get support right away once you have a job to be done. No need to ask around for referrals from friends and colleagues.

The large pool of Pros on Thumbtack also allows you to compare multiple offers which can be handy (no pun intended) especially for larger projects.

Understanding the users' motivation

Really nailing down the why will take time. But as the other parts of your use case map, it doesn’t has to be perfect from the start (and probably won’t be). It’s important to have a decent understanding and then iterating and improving over time.

The challenging part when researching your why is that often times users themselves are not fully aware of the deep motivations that made them go for your product. And sometimes they might know it but don’t share every aspect of it.

A lot of people would be uncomfortable admitting they bought their Tesla as a status symbol and will mostly focus on the environmental aspect.

Or take Cybex: A German manufacturer of high-end baby strollers that’s positioning itself more and more as a lifestyle brand for parents. Within the last couple of years, they have become a status symbol for upper-middle class moms and dads.

If you walk around wealthier neighborhoods of Hamburg, Munich, or other large European cities you’ll see baby accessories with their yin and yang inspired logo everywhere.

Are the products of high quality and convenient to handle in a parent’s day-to-day life? Yes. Is the status signaled by carrying around products with their logo a major purchase motivation? Absolutely.

With this gotcha in mind you again have to turn to your healthy, i.e. happy existing users for insights. The following questions can guide you to uncover your users’ motivations:

1. What is the healthy users' journey to your product? Some sample questions you could ask:
   • How did you hear about the product?
   • What made you try this product?
   • When was it?
   • Who were you with?
2. Why did they choose your product over the alternative?
   • Why did you stop using [alternative]?
   • When did you stop using [alternative]?
3. And in case they did choose the alternative over your product, when and why did they do so?
   • When did you last use [alternative]?
   • What made you choose [alternative] over the product?
   • Who were you with?

The last puzzle piece of our use case map is the natural frequency in which the persona experiences the problem.

Further into designing your retention strategy this will become the foundation of your retention metric: A user is considered retained if they return to your product in the natural frequency. In other words: If a user comes back to your product every time he experiences the problem, this user is retained.

There’s no retention strategy without knowing the users’ natural frequency.

Apart from the retention strategy, it’s also a key factor when designing a winning monetization model for your product.

How often users use your product will determine in what intervals it makes sense to charge them. It doesn’t make sense to have a monthly plan for a product that’s only used once per year such as a tool that helps your file your taxes.

Use case frequencies are a spectrum

Though it sounds like straight out of long forgotten physics lectures, the use frequency spectrum simply visualizes how vastly different natural frequencies can be across products.

Some products are used daily: Social media platforms like Instagram, or TikTok but also apps like Netflix, Spotify, development environments like VS Code, CRMs, weather apps, or media sites.

A lot of business software is used once or twice a week. Most people don’t record videos with Loom every single day, or create and sign contracts in DocuSign only once a week or even a little less. Figma, Miro, and other collaboration tools are in this bracket as well.

If we go further down the time bar, we’re getting to products like Tumbtack or Airbnb. While most hosts use Airbnb on a weekly basis, guests usually book around two to three stays per year.

Similar for Thumbtack: The home professionals use it weekly to reply to requests and send out quotes. Some might use it multiple times a week, some maybe every 10 days or so but a weekly frequency seems appropriate. But consumers only seek professional help around the house a few times per year.

Then the classic example for a product with a yearly frequency is tax filing software. Most people file their taxes just once a year, so they use tools like Turbotax on a yearly basis.

Finally, there are some verticals with a frequency of even less than yearly. Job portals like indeed are only of use if you’re looking for a new job. For a lot of people this will not happen every 12 months. And most people don’t buy and sell their house every year, so real estate platforms like Zillow also have a frequency less than yearly.

Now that we’ve seen how wide the range of natural frequencies is you might be wondering whether some natural frequencies are better than others? The clear answer is yes.

Using Spotify, Zendesk, or Loom quickly becomes a habit. People start using these tools on autopilot pretty quickly. Once Loom is set up and you’re happy with the results, you’ll automatically open it every time you want to record your screen plus video and/or audio.

Indeed or Zillow on the other side will have to invest a lot of money into brand awareness campaigns and acquiring new users. If you’ve got your last job through Indeed, chances are that in two years when you’re looking for a change you’re not automatically going back to Indeed.

Instead, you’ll probably look for open positions on LinkedIn or Google. Indeed will then have to e.g. invest into search ads again to win you back as a user of their platform.

Problem and persona impact the frequency

Other parts of the use case directly impact its natural frequency. This becomes very clear when we look at Shopify. Let’s consider these two exemplary problem statements:

• Problem 1: “I want to quickly build my e-commerce store without any coding.”
  • Frequency: Daily for maybe one or two weeks, until the store is fully set up. Then this use case is done, and the frequency is “never”.
• Problem 2: “I need to easily manage and grow my e-commerce business.”
  • Frequency: Daily for as long as the business is running. Every day users will log in to their Shopify account to ship new orders, update and add products, refund payments, provide customer support, and tweak the site to increase sales.

The second one is clearly preferrable. Nobody wants to build an e-commerce store just for the sake of building the website. They want to sell their goods.

The second problem’s scope justifies payment, inventory management, and reporting features that today are core parts of Shopify’s success.

It also lays the foundation for uses to interact with Shopify on a daily basis. This lets users form habits around using Shopify, making it a central part of their e-commerce business, and ultimately increasing Shopify’s customer lifetime value (LTV).

Determining your product’s natural frequency

To estimate the natural frequency, you'll need to understand how often the user is using your product to solve their problem.

So far you got most inputs for the use case map from talking to your users. So, to determine your frequency your first instinct might be to just ask them: “How often do you use the product?”

Unfortunately, this doesn’t lead to reliable insights. Just because they are using the product doesn’t mean it’s solving their problem. It might even be the opposite: They are using your product more often because it doesn’t solve the problem.

The newsfeed of your favorite social media app doesn’t really entertain you anymore? At least for some time you’re likely to open it more often because the itch of boredom isn’t scratched. Can’t find suitable jobs on Indeed or attractive homes on Zillow? Chances are you’re checking back more often than if you’d had a few interesting offers in the pipeline.

You can still ask your users to estimate your product’s natural frequency. But the questions should revolve around the problem and the alternatives, not the frequency of use.

• Problem. Ask users about the last few times they experienced the problem. By walking through past instances, you can start to identify patterns and estimate the natural frequency. You could for example ask:
  • When did you last experience the problem?
  • What were you doing when you experienced the problem?
  • How did you solve it?
  • When was the time before that? What were you doing?
• Why did they choose your product over the alternative?
  • Alternatives. Ask users about the last few times they used any of the alternatives. These are good indicators of how often they are likely to use your product.
  • When did you last use [alternative]? Why?
  • When was the last time before that? And before that? etc.

Hopefully, the answers to those questions gives a good idea of what frequency people use your product to solve their problem. Are they using it daily? Weekly? On a monthly basis? Or maybe only once or twice a quarter or year?

At the end of this guide, you find an extensive collection of use cases from companies across different industries and business models to give you further reference points.

Example: Airbnb — Use case map

Example: Pinterest — Use case map

Example: Slack — Use case map

Example: Eventbrite — Use case map

Example: Uber — Use case map

Example: DocuSign — Use case map

Example: Zendesk — Use case map

Example: Loom — Use case map