Strengthening Product-Market Fit

As I said in the introduction, this book assumes you have some semblance of product-market fit, but it is a long road from launching a product to building something people want and are willing to pay for.

So much of your company’s success will depend on developing a deep understanding of your market and ideal customer. Often, this understanding becomes a moat of sorts and is one of the best ways I know to strengthen the love your customers have for your product.

Although there are many ways to develop this understanding, one of the most reliable is having conversations.

Most entrepreneurs don’t have enough conversations with potential, current, and past customers. It’s time-consuming, and while running a company, you’re doing everything from building new features to troubleshooting security issues to answering support emails. Even if you see the value of customer research, how do you find the time to do it?

There’s another reason entrepreneurs don’t talk to customers: fear—fear that they’re bothering them, fear the customer will say something they don’t want to hear, fear that it’s a waste of time.

In my experience, the conversations you have with customers, whether via email, chat, or on a call, will be some of the most valuable time you spend understanding your market, especially in the early days.

These conversations will inform your product road map and how you build features as well as your positioning, marketing copy, and pricing. You’ll build a better product for your ideal customer faster than if you try to guess what people need.

When Ruben Gamez, the founder of SignWell, decided to build an e-signature tool, he knew he needed to do something unique to make his product stand out. He talked to people about the problems they had with e-signature tools, and one thing he kept hearing was that customers wanted to send a link to the document that needed to be signed rather than having the email come from an impersonal third-party service.

Ruben listened, and that was one of the many features he heard through customer conversation that helped SignWell become a strong player in an incredibly competitive market.

Who should you be talking to?

• Prospects
• Customers
• People who decided not to become customers
• People who became customers and then canceled

The key to getting actionable information from customers depends on whether you’re doing early customer discovery or researching how (and whether) to build a new feature. But typical questions might include:

• Can you walk me through a sample flow?
• What problem are you trying to solve?
• What do you currently use to solve this problem?
• What did you use in the past?
• What are some of your biggest frustrations about this solution?

As a general rule, ask open-ended rather than leading questions. If you say, “We’re thinking about building this. Check out this mock-up,” most people will have a hard time being honest. They don’t want to hurt your feelings, so they go along with it and you don’t get useful data.

Deep dives into customer conversations have literally filled books. For a great resource on doing customer interviews as a founder, check out the book Deploy Empathy: A Practical Guide to Interviewing Customers by Michele Hansen. You can also listen to my interview with Michele on Episode 586 of the Startups for the Rest of Us podcast.

In these conversations, this is the time to put your consultant hat on and have a conversation entirely focused on your customer’s needs, not your product—this part is important.

As Jim Kalbach, author of The Jobs To Be Done Playbook, told me on Episode 577 of my podcast, when you look at the people you serve through the lens of your own solution or product, it clouds your judgment.

“By taking yourself and your offering out of the equation, potentially —there’s no guarantee of this—you can actually find opportunities that you wouldn’t see otherwise.”

One of the popular memes in the entrepreneurial world is that your customers will tell you what they want—just launch something ASAP, and they’ll tell you how to make your product better.

But that is assuming your customers know what they want.

Henry Ford never actually said his customers wanted faster horses instead of a car, but the wisdom in that story is strong enough that people have been repeating it for 100 years.

Your customers don’t know how to build software as well as you do, and even if they did, they’d never match the insights about the market you’ve learned building your product. In fact, if they could, you should probably close up shop, go to bed, and try something new in the morning.

As my last startup, Drip, began to grow, we received several feature requests per day, and we had to constantly make difficult decisions about which ones we were going to invest our limited time and resources into building.

I wanted to build a product that people used—a lot of people—and that meant learning how to take certain points of feedback to heart and discard the rest. A big part of the reason Drip was successful was that we used the feedback from our best customers to find and solve problems other email service providers didn’t.

This involves learning how to separate valuable ideas from distractions, and until you hire a product manager (something that typically happens north of $1 million in ARR), you’re the person who needs to decide which features will strengthen your product-market fit.

I filtered them by putting them into three buckets: The Crackpots, No-Brainers, and In-Betweens.

The Crackpots. First up are the crackpot requests: ideas so far out of left field you can’t imagine why they want it or even understand what they mean.

The crackpot suggestions are the easiest to process because you know right away you’re not going to build them.

Here are some examples of oddball requests:

• Features that would require building an entirely new product (e.g., “Why can’t I use your email provider to publish blog posts?”)
• Features that would turn your product into a clone of your competitors (e.g., “It’d be great if you could add a shopping cart, and a CRM, and lead scoring, and . . . just build a clone of Hubspot and charge me one-tenth of the price.”)
• Features that are the opposite of your product’s strengths (e.g., “I like that your UI’s so streamlined, but can you add these ten new options to fit my rare and unique use case?”)

No, no, and no—these folks make it easy to say, “Sorry, these requests are not a fit for us.”

No-Brainers. You’ll also get requests that are either already on your road map or make you wonder why you didn’t think of them.Once in a while, your customers will come up with an idea that’s so awesome you want to put it into production immediately.

These are also easy to handle because you know they’ll objectively improve the product and make it more valuable for your users.

For instance, at one point, a customer reached out to see if there was a way to retroactively add a tag to his subscribers based on links they had clicked in the past.

Well, no . . . but it was a great idea and not terribly hard to build. Drip was (and might still be) the only product that offered that feature, and it became a powerful tool for our users that they couldn’t use anywhere else.

List pruning is another example of a no-brainer feature. Subscribers zone out over time, driving up the cost of your email plan and skewing your metrics with “dead” users that wouldn’t open an email if it contained the cure for cancer.

Most list management systems don’t have built-in list pruning, and it’s a big chore to go back and figure out which subscribers to delete from your list.

So when a customer reached out and asked if we could make a button that would prune inactive subscribers according to some basic best practices, we immediately put it on our road map.

In-Betweens. I’d estimate only 10% to 15% of the feature requests are crackpots, while maybe 20% are no-brainers, so that leaves a lot of judgment calls.

The reality of running a software product is that you will get dozens of feature requests that aren’t necessarily bad, but aren’t slam dunks either.

You can’t build all of them—that’s how good software bloats into a mass of buttons, boxes, toggles, and settings. As the founder, you’re the gatekeeper. You’re going to have to say “no” to an awful lot of good ideas.

I usually roll my eyes when people quote Steve Jobs as their reason for taking a particular course of action because he was such an outlier that his thinking won’t work for most of us. But on the topic of saying “no,” he nailed it:

“People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas . . . Innovation is saying ‘no’ to 1,000 things.”

As we just discussed, one way to weed through feature requests is to figure out the problem your customer is trying to solve. When a customer asks you to add a new kind of button, they don’t really care about the button—they’re trying to do something in the software they can’t figure out and believe a button is the best way to accomplish that.

Your job is to figure out the problem your customer is trying to solve, not just build the solution they suggest. Then, figure out whether that solution requires a new feature and whether it’s worth building.

It’s pretty easy to do this in a way that makes people feel like you’ve listened to them, whether you end up building what they want or not.

Ask yourself these three questions:

Question #1: What’s the Use Case for This? Or, in layman’s terms, what problem are you trying to solve?

You can get at this by asking questions such as: “What leads you to want that? What problem are you trying to solve with this feature? What are you currently using to get that done?”

Sometimes you’ll realize you already have a way to solve the customer’s problem but in a way they hadn’t discovered yet. At that point, it’s up to you to explain how they can use your tool to accomplish their goal and maybe add something to the UI to help other users find it more easily.

If your product doesn’t already meet the customer’s needs, you must determine whether you can build the feature and whether you want to. At the end of the day, this depends on how many people you think will use it. This leads us to . . .

Question #2: What Percentage of Customers Will Actually Use This Feature? More than 5%? Ten? Twenty? You won’t know for sure, but spitballing your best-guess percentage can help you decide whether to build the feature and how prominent it should be in the UI.

If you think only 5% to 10% of your customers will use something, go a step further and spot-check which users they are.

If it’s a random group of users, it might not be worth building. But if that 5% to 10% are power users and this feature would make your product more useful to them, consider building it and keeping it hidden from the average user by omitting it from the standard UI and only enabling it upon request.

Why hide these features? Because if the vast majority of your users will never need them, adding dozens of checkboxes and drop-downs will make your core product confusing for them.

If you think 20% or more of your customers will use a feature, it’s something to consider building.

But first, you have to ask yourself one more question . . .

Question #3: Does This Fit with My Vision of the Product? Every feature has opportunity costs. Every hour you spend building a feature is an hour you don’t spend building a different one.

Ultimately, you’re the founder. If a feature request doesn’t fit with your vision of what the product should be, it’s probably not one you should build.

One elegant solution to many of those “big lift” feature requests is to add integrations. Problems that might take weeks or months to solve are often already solved by another product. If you can integrate their application programming interfaces (APIs) into your product in just a few days, fulfilling those requests can be a win-win for you and the customer.

Too many products get cluttered with obscure features that only help one or two customers, and too many entrepreneurs get bogged down in building endless feature requests instead of focusing on making great software.

As a bootstrapper, time and money are precious, and feature requests can wipe out both quickly.

But the most important resource in your company—and the most scarce—is your vision for your product and how it solves your customers’ problems.

Solving your customers’ problems is the road to strengthening product-market fit. Expect a long, slow road of customer conversations and hard decisions with incomplete information as you work to build something people want and are willing to pay for.