Customers extrapolate from quality

By the fifth time we sent our demo to customers, we knew what to expect.

Early on, we identified the “main page” of our application that most prospective customers would care about when they saw our product. However, there were also the hundred other features and screens that were begrudgingly necessary but no one would think twice about: ways for users to change their email address and password, workflows for customers to create new posts on that main page, workflows to edit existing posts, notification systems to alert subscribers of new posts. We put in the time to build the main thing well, and then we spent at least as much time building the small annoying things.

We use a tool called FullStory that allows us to see how users interact with our site. Every time we sent the demo to a customer, they looked at the “main page” for about 20 seconds. Then they closed the demo. They’d shoot back an email along the lines of, “This looks great! Let’s meet next Tuesday to talk more.”

During later conversations with those prospective customers, we’d discover that they were making the entire purchase decision based on the sliver of the product they saw. They just assumed that the rest existed and was built to the same quality bar.

The lesson was stark: customers will extrapolate from the quality of what they can see.

If you build a big crappy product, people will assume you’re capable of building a bigger crappy product. If you build a small excellent product, they’ll assume you’re capable of building a bigger excellent product and may want to join you on the ride. People are constantly bombarded with new things trying to enter their lives: something needs to be remarkably good to warrant a try. The way to move fast but still pass that filter is to build something remarkably good and remarkably small.

There’s a reason that people can’t wait for the next Pixar movie, but mostly ignore 95% of other movies that come out: Pixar’s output volume is low, but their work is remarkable and consistently worth paying attention to. Similarly, when building a product, you should ask yourself: “What can I cut so that I can make the important parts remarkably good?”

In that spirit, it’s critical to identify:

  • Who makes the decision about whether to use this product?
  • What parts will they be looking at when making that decision?
  • How can I avoid building as much of the other stuff as possible?

Startups need to move quickly to find customers and prioritization is the single most important part to moving quickly.

A few nuggets to help with this prioritization:

  • Build an FAQ page with entries for how to do all of the things you didn’t build. For each entry, just say “Reach out to support@example.com for help doing this.” It’s important that you be responsive to that inbox, but the emails you receive there can help inform you which of the features you skipped should be built first.
  • Early customers are surprisingly accepting of the limitations of an early product that’s great at one particular thing. See: “Instagram only lets you post square pictures.”
  • When possible, use high-quality off-the-shelf solutions that require only small amounts of customization. For your homepage, you can use a good-looking Webflow template, strip out what you don’t need, and ship something that looks good in half a day.
  • Avoid cargo-culting things that “real companies do” but don’t affect whether customers will purchase your product. Your company doesn’t need a website unless potential customers will actually look it up. Your website doesn’t need a team page unless potential customers care who the team is.

It’s not an exaggeration to say I could have saved literally years of effort by building less before selling. If you can use prioritization to spend less time building and more time finding and talking to customers, you’ll put your company in a much better position to succeed.

If you enjoyed this post, please consider sharing it with others
by upvoting it on Hacker News.

This blog is my journal about how to start and scale software businesses.

Subscribe below and I'll send you an email when I write something new.

Previous post

No distribution, no dice