Let’s assume you’ve created something that you think is the bee’s knees. How do you get people to take a look at it?

Girl scouts

The average girl scout sells about 200 boxes of cookies over the course of an 8 week season. For most fledgling companies, 200 paying users is nothing to sneeze at. So even if you think you’re more capable than elementary school girls, the evidence suggests you have a lot to learn.

Girl scouts have the advantage that their product has already been validated, and they know their market - adults who like to eat cookies. Since their product appeals to almost everyone, it’s just a matter of going door to door and asking people to buy it. Here’s a quote from one girl scout on how to do that:

I had to push and push and push. Sometimes they try to sneak past you and you look them in the eye and make them feel guilty.

She’s not messing around! And the most successful founders I know tend to have a similar approach. They will keep brow-beating until you tell them that you’re buying, or tell them exactly what’s missing for you to purchase in the future.

Forward deployment

The best example of the girl scout method that I’ve seen was while working at a company that specializes in tools for data analysis. The company had a platform for building “applications” for the customer, but it was highly configurable, in a way that today’s open-source software is not. For example, moving a button or changing a color usually took seconds for even a non-engineer.

That meant that we could build exactly what was needed, fairly quickly. The problem was, we didn’t know the customer’s needs that well. We were smart, but we weren’t experts at whatever industry the customer was in. What were their problems? What was most urgent? How do they solve the problem today? How much money and time do they spend on it?

There was only one company-sanctioned way to answer those questions. You flew to wherever the customer was, sat with them (usually in their office), and built the product. Until they were satisfied with what was built, you didn’t leave. This was true even if the customer was in Europe or Asia. We used a corporate card to expense countless meals, merchandise, and hotels, optimizing exclusively for whether we could build something valuable for the customer.

It was pretty wasteful. But the strategy was spot on. While it’s almost impossible to build a useful product in a vacuum, it’s also almost impossible not to build a useful product when you spend every day talking to your customer.

Virality

In epidemiology, we use a number called R to represent the number of cases directly caused by a single case. COVID-19, for example, apparently has an R value of 2-6, meaning you expect at least a few new cases for every case that you see. Virality in software is the same concept, though I haven’t seen it measured quite the same way.

Seen in that light, it’s easy to explain why the typical experience of a startup with a big, banner-filled launch is so bad. They do all sorts of shenanigans to get a large amount of traffic. People see the product, but many of them *collectively**shrug their shoulders, *then move on with their lives. With an R of less than 1, users don’t spread it to their friends, so while it might *seem *fine, eventually even lukewarm users churn off the product, and the entrepreneur ends up with bupkis.

On the other hand, a small launch, with an R of greater than 1, is much more likely to succeed. Your initial users are already cheering for you, they recruit other people, who recruit other people, and so on. It’s a positive feedback loop that builds on itself.

Essentially that means that above some minimum number, your success as a company is much more about making something people want than it is about some kind of tricky trick you can use to get lots of people to visit your page. It doesn’t really matter, to a first approximation, whether you have 100 users or 1 million. If your R number is high enough, you can simply wait and watch as your users grow exponentially.

What not to do

That has some practical implications for us. Remember that our goal is to iterate with users as much as possible, and we don’t really care about how many we have.

  1. Submitting your project to Hacker News or Reddit will get a lot of anonymous traffic (i.e. people you can’t easily talk to), which is exactly the opposite of what you need before you’re confident in your R number.
  2. Similarly, Facebook & Google ads are common mechanisms by which you can “add a billboard to the internet highway”. But if your initial users aren’t bragging for you, you aren’t delighting them enough, and your project will die even if you get traffic this way.

You may noticed that I caveated my point above with “some minimum number”. Why hedge?

The tubes are filled with customers

The Internet is big. Really big. Big enough that you can’t actually conceive of all of the people on it at any given time. Apparently 4.5 billion people in the world have access to the internet in some way. And because you’re building your little project on your own you don’t need very many people to buy it before you’re making a handsome profit.

The distribution advantage you get with the internet means you can go after seemingly small markets and still do well. How many people do you need, paying you $20 / month, to support your lifestyle? 1000, at most.

Depending on the problem you’re solving, maybe those 1000 people aren’t so easy to reach. In those cases, it probably does make sense to “spray and pray” to share your product as widely as possible, in the hopes that your potential fans recognize and identify themselves. After that, you can reach out to them and ask them for help directly.

User iteration

Once you have a few users who agree to have a regular cadence with you, it’s time to talk. At least at first, don’t talk at all about what you’ve built. It’s not about you, it’s about them. Here’s roughly the script I follow:

  1. Do you have at ?
  2. If yes, what are your current solutions? How do you deal with ?
  3. Interesting - how would you envision a solution?
  4. Thanks, that makes sense! We had similar thoughts on a solution, specifically on <example 1>, <example 2>, <example 3>. Would you be interested in seeing a prototype?
  5. Demo the software
  6. If I asked you to commit $X / month for a license to this product, would you agree to do it?

The best part about working in software is that as you talk to users you can change the product on the fly. In that sense, you aren’t “building an object”, you’re instead molding around the exact problem that you’re trying to solve, and customers are the ones who can tell you what the shape of the mold is.

Ignore them at your own peril. A lot of people think they know what product needs to exist independent of talking to users. That has about as much success as trying to determine the outcome of an experiment without actually trying it. As you get more information, you’ll build more features. And as you release those features, your not-yet-customers will transition to customers, who will then transition to customers with large R numbers.