Use cases before Features

You, as a person in tech, can you relate to this situation: You talk to a prospect and enumerate all the great tech you’re using in your SaaS product, hoping to close a deal? It’s very likely the prospect is not super convinced and will politely bow out of the conversation.

That’s frustrating. Building this fantastic product, you spent so much time and money on this magnificent tech stack. We’re people with technical backgrounds, and we care about the technologies used to build products. If somebody told me that they’re using more memory-safe programming languages to develop their product, I would feel better about using them. It is a valid argument, but that’s not what prospects want to hear at the beginning of a conversation.

I recently was at AWS Re:invent, working at my employers booth. A few people who stopped by pointed out that our booth didn’t give any clues about what we do. Those who got curious stopped and asked. It was an excellent opportunity to try out a few things.
Initially, I started the conversation like this: “We do distributed tracing on AWS for Microservices and support so and so many different languages. Let’s walk over here, and I demo it for you.” Interest quickly vanished. Most visitors politely tried to end the conversation and walk away.

That didn’t work well, so it was time for a different approach. Whenever visitors asked, “So, what do you do?” I replied, “We do Distributed Tracing.” I chose to start with that to put everything that follows into a frame and test if they had any knowledge about this topic. Now come the sentences that are different: “You may have run into situations where your microservices start to throw exceptions, like your public-facing API endpoint, but it’s unclear which exact service is responsible. Or, you notice that API calls don’t perform as fast as they should be. It’s difficult to diagnose where the extra time is spent.”

The response: Lots of nodding and the first follow-up questions.

What changed?

My former approach focused on features while the latter emphasized use cases. If you have never heard about distributed tracing, it’s unlikely a list of features will convince you to sign up for a free trial.
On the other hand, if you hear a use case or scenario you experienced yourself before, you want to know how this company solves it (differently).

At the booth, I’m interested in talking to people who have never heard of the company and haven’t considered distributed tracing to solve their problems.
With that in mind, I need a tailored message to reach them. That includes the focus on use cases and problems. Later on, once we’ve established rapport, I can talk about features to support my initial claims.

If I only focused on buzzwords and technical details, I’m in the same bracket as everyone else. Then, it’s the same as “sort by price” when looking for a hotel room.

We want to avoid “sort by price.” Especially if competitors have all the features. Visitors become customers when they have the feeling, “Hey, this company understands me.” We build this level of understanding by focusing on their use cases and problems. We are technical people; we like to talk about technical topics. And I promise you; there’ll be plenty of opportunities for it.

Leave a Reply