At the moment, I’m trying to understand what the different use case are for a product I’m working on. This is by far the messiest part of growing a product. The tricky bit is finding the right level of abstraction.
What are we even talking about when we talk about use cases or jobs-to-be-done, or personas or any other framework for grouping people’s core motivations for using something? It’s tempting to just define your use cases by listing out your feature set.
The use case for the newsletter widget is to get more people on your newsletter. Boom! Case closed 🎯 Nope, this is lazy and unhelpful when you’re trying to figure out why people are trying to grow their news letter.
The goal is to understand what the product, or in this case the feature, means to them and how we’d even begin to frame what a ‘better’ version of the feature means for this person.
So then you swing the other way and go too broad. The use case for our product is to make people’s lives better 👼 Equally unhelpful. We are still exactly zero steps closer to understanding what ‘better’ means to this person.
The real work is way more interesting. It’s more archeological in nature, you have to gently dust off nuggets of insight from real conversations with people, look at behaviour patterns, and listen
to feedback in customer support.
If you bring a sledgehammer and blast out a survey, people will just tell you what you want to hear. Surveys are great, no beef there, they’re just more useful for confirmation than exploration.
Figuring out the right questions is the messy middle where all the fun happens. Getting to the right level of abstraction is hardest bit of the process. It’s also the most crucial, without it you have no idea why people care about your product or what better means to them.