Go-to-market strategy for engineers
Roughly, a go-to-market strategy is the answer to the question "how will you sell what you've made?" Roughly, but not quite.
When you start playing a new game, an expert can easily predict the mistakes you're about to make. It's easy for the expert to do because anyone who doesn't yet have an intuition for the game will make the same class of novice mistakes.
For example, in chess novices make blunders because they miss something trivial on the board. They'll often recognize the blunder immediately, even before their opponent makes the next move. In the game of Go novices attack stones by attaching to them even though attaching to an opponent's stone makes it stronger. And in business novices make a product nobody wants.
You can't transmit product intuition verbally any more than you can do that for chess. Improvement happens over time with considerable trial, error and repeated feedback. Still, some explanations are better than others, and all currently available explanations aren't good enough. We know that because perfectly smart, capable people will read everything available on the subject and still make products no one wants. Let's try to do better.
Imagine two startups-- A and B. Startup A has a great product and list of potential users that's longer than they know what to do with. They've hired an army of sales people and still barely scratched the surface of the list. Almost any time a salesperson calls up a potential user, the person on the other end is interested. They get what the product is about quickly. A third of the calls result in a second call, and almost all of those result in a sale. Users love the product. The office is vibrant and the energy is palpable. The company grows quickly. Life is good.
Startup B has a great product and technology that's years ahead. They have a list of potential users too-- from inbound emails, social media conversations, investor introductions, and their personal network. They can't quite tell if the product is a good fit for people on the list, but they have hunches. When they call, it's difficult to explain the product-- it takes a while for people to get it. Those who get it aren't quite sure if the product is for them. They ask about a few features. Maybe there is more back and forth. Ultimately, few people buy. In an attempt to get users, startup B builds features that pull it in different directions. After years of trying it runs out of money and shuts down.
Go-to-market
What's the difference between the two startups? Startup A has what the industry calls a well executed go to market strategy. Roughly, a go-to-market strategy is the answer to the question "how will you sell what you've made?" Roughly, but not quite. If you build the product and then try to answer this question, you'll find that it's nearly impossible. No matter how hard you try, the product doesn't sell. You become startup B. That's because there is a nuance in the question. The definition is almost correct but not quite. This one nuance probably killed more startups than almost anything else.
The problem is that the question implies sequential steps. First you make a product, then you figure out how to sell it. That's wrong. The product and the go to market strategy intricately depend on each other, the way two species may depend on each other in an ecology. Without one, there is no other. They must co-evolve together.
You might say "well, what about Facebook and Google? They didn't figure out how to make money until long after they've launched!" Fair enough. Replace "sell" with "get users". How will you get users for what you've made? That's still the wrong question. The making and the getting are one process-- they must co-evolve together.
There is an unpleasant corollary here. You can't apply this essay to an existing product that isn't selling. You can try and you may be able to salvage it, but you'll need to throw large pieces of your product out. You might need to throw all of it out. It's a difficult thing to hear, but that's what you've signed up for when you started a company.
Partition functions
At the heart of a go-to-market strategy is a user partition function. It works like this. Imagine you have a set S with every person on the planet as its member. A partition function user? takes members of this set as input and outputs a binary value-- true if the person is a target user of your product, false otherwise. Another way to think about it is that user? partitions the set S into two-- a set of target users U and a set of everyone else E. For example your company, Linen Candy Corp., is building a new product for everyone who likes cotton candy. In that case your user partition function looks like this:
fn user?(person) { return person.likes_cotton_candy == true;}This is easy enough. But there is more. The function must have two additional properties.
First, it must be precise. It doesn't have to be a computer program, though that wouldn't hurt. It could be specified in pseudo-code or in natural language. But if I point you to a person and give you the necessary information about them, you must be able to instantly tell whether they're a target user or not. No fuzziness. No maybe. No confusion. You must have complete and immediate certainty. Either true or false.
Second, the range of the function must be efficiently computable, and it must be efficiently computable by you. Imagine that your product is immensely successful. So successful that anyone in the set of target users U who gets a cold email immediately buys it. Will you be able to efficiently generate a list of cotton candy lovers and their emails?
One way to think about it is that all functions that can be expressed using Facebook's ad targeting API are valid user partition functions because they satisfy both criteria. They're specific; and you can reach everyone in U by paying Facebook.
Not all valid user partition functions can be expressed using Facebook's API. For example your product may be targeting everyone who's first name is Bill. That's not something Facebook ad targeting can do but you can find these users in a phone book. Or at least you could have back when we still had phone books.
To go back to the two startups, the concrete advantage of startup A is that it has a good user partition function. The target users understand and buy the product quickly because it was built just for them. The product solves their problems, and deliberately doesn't solve anyone else's. There is no confusion. The partition function unifies sales, marketing, and engineering. And it pulls everyone's work in exactly the same direction.
Scoring
Of course a function that splits users into two sets, is precise and is efficiently computable is a partition function, but that doesn't mean it's a good partition function. Most partition functions are bad, and a bad partition function won't give you startup A-- it will give you a more focused startup B that fails quicker. That's valuable in itself, but not good enough. So we need a way to measure the quality of partition functions.
Let's define a higher order function score, which takes a partition function as an argument and returns and returns a number between 0 and 1. The score of zero means you won't sell anything. The score of one is the impossible platonic ideal-- it means you'll sell to every potential user you encounter. The higher the score, the closer you are to building the coveted startup A. Most partition functions have scores that hover around zero.
Here is one implementation of score that's very simple. First, make a demo of the product as quickly as possible. The demo isn't the actual product, and it doesn't need to be a prototype. You can make it a Figma design or even a slide deck. All it has to do is communicate the problem and how your product solves it.
Then take a sample of potential users generated by your user partition function. About thirty would do. Call them all and try to get them to pay you. After a week, divide the number of potential users that sent you money over the sample size. That's your score. If you couldn't get anyone to pay you, the score is 0 / 30 = 0. If twenty people paid it's 20 / 30 = 0.66. If everyone paid it's 30 / 30 = 1.
There are many reasons this specific implementation may not work for what you're doing. You can tweak the sample size, the sales cycle length, or change the desired outcome from money in the bank to some other action or metric. Letters of intent, number of minutes spent per week on your site over a certain threshold, some minimum number of friends invited to the platform. You can adapt score to any business, but be sure the outcome is meaningful! Money in the bank is best. There isn't a second best, but for complex business models a specialized metric can work too.
Focus
Think of early startup work in two stages. The first stage is generating many (partition_function, demo) pairs and scoring them. Once you find a pair with a good score you enter the second stage. In the second stage you abandon everything else and completely focus on the one high scoring pair.
If you run into a potential customer who isn't in the current partition list, you don't work with them. If there is a feature that doesn't benefit users on the current partition list, you don't build it. When you design a landing page, you write only for the potential users on your list. They need to land on the page and answer the question "is this for me?" in one second, and then reaffirm the answer with every additional sentence. Discard anything that doesn't accomplish this goal, no matter how appealing it sounds.
What's a good score? It depends on your business. Here is one way to think about it: suppose a demo takes forty minutes, and between all the other work a sales rep (who early on is probably you) can only do five of these per day. A score of 0.2 means the rep will close one customer per day. A score of 0.1 means the rep will close one customer every two days. A score of 0.05 means the rep will close one customer in a week, give or take.
How do the economics work out? Does the product cost $500 or $50,000? Closing a $500 contract once per week is very demoralizing-- the sales reps can't even pay for themselves! Closing a $50,000 contract every week, now that's exciting! Which of the two offices would you rather work in? Look at the numbers, see if the math works out, then picture yourself working on a company with these numbers. Is it exciting? If it isn't, don't do it!
Sophistication
I've made a lot of simplifications here. That's deliberate. Early stage startups don't fail because they aren't sophisticated enough. They fail because they screw up the basics. For example, you can define a user partition function that returns a probability instead of a binary result. This is called lead scoring. It's useful when you've built a winning product for an audience and want to expand its reach. But until then it will blunt your focus and will do more harm than good.
It's important to learn about basic metrics for your space and look out for them as you're building. For example, The fundamental equation of SaaS. But before the product even exists, you must excel at the fundamentals. Don't use multiple categories when a binary decision will do. Don't use a continuum when you can get away with discrete categories. Simplify, simplify, simplify, and excel at the fundamentals. If you do, there will always be time for sophistication. If you don't, no amount of sophistication will help.