What's Go to Market, and Why You Need to Think About It Before You Build

This article is the first of six on the steps of go to market.

There were 557,000 new app submissions to Apple's App Store in 2025, a 24% increase on 2024 and the first meaningful rise since 2016 (per Appfigures (opens in a new tab), published 5 December 2025). The 2026 numbers are steeper. Releases across the App Store and Google Play were up 60% year on year in the first quarter (opens in a new tab), and up 104% in April 2026 against April 2025.

Somewhere in that pile is a product built by someone who is very good at building but bad at marketing.

What go-to-market means

Go-to-market is everything between "the thing works" and "someone pays for it". Who it's for, why they'd switch, where they'd hear about it, and what you say when they do.

Gartner (opens in a new tab) defines it as "a plan that details how an organization can engage with customers to convince them to buy their product or service and to gain a competitive advantage". Harvard Business School Online's version (opens in a new tab) is a one-stop guide written for startups: a plan for reaching your target customers effectively and efficiently, where effectiveness is how fast you reach and convert them and efficiency is whether it pays for itself.

Both describe a document. Neither says when - or how - to write it.

Building stopped being the hard part

GitHub's Octoverse report (opens in a new tab) for the year to 31 August 2025 counted 36 million new developers joining, up 23%, and 121 million new repositories created.

A product that would have taken a small team six months in 2019 now takes one person a fortnight: software is no longer scarce; what is scarce now is being the one product a person can name when they need this problem solved. Nobody's IDE does that part.

What the shutdown data says

CB Insights (opens in a new tab) analyzed 431 VC-backed companies that shut down (opens in a new tab) from 2023 onwards, identifying failure reasons for 385 of them: ran out of capital: 70%. Poor product-market fit: 43%. Bad timing or macro conditions: 29%. Unsustainable unit economics: 19%. The percentages exceed 100 because companies get assigned more than one reason.

Two caveats before that 70%; running out of capital "is almost always the final cause of death, not the root problem". And the population is VC-backed companies, which is not most people reading this (a bootstrapped one-person product runs out of the founder's patience instead, and that's not quite as quantifiable).

Two in five of the companies that could afford to hire, market and iterate still built something not enough people wanted.

Eisenmann calls it a false start

Tom Eisenmann at Harvard Business School published "Why Start-ups Fail" (opens in a new tab) in the May-June 2021 issue of Harvard Business Review, drawn from interviews with hundreds of founders and investors and more than twenty case studies of failed ventures. One of his named patterns is the false start: founders adopt lean startup halfway, sprint into building an MVP, and skip the part where you find out what people need.

By neglecting to research customer needs before commencing their engineering efforts, entrepreneurs end up wasting valuable time and capital on MVPs that are likely to miss their mark.

It's qualitative work with no number on it - it describes a pattern and not a rate.

The number that can't be given

Founders spend X% of their time building and Y% on distribution, and the gap is the problem (I spent a while looking for it).

It doesn't exist. Every version of that statistic traces back to content written to rank on Google, citing other content written to rank on Google, with no study anywhere underneath. Techstars' 2024 State of Innovation survey (opens in a new tab) (1,550 respondents, fielded March 2024) covers founder concerns in detail and contains nothing at all on marketing, sales or customer acquisition.

Which leaves me somewhere awkward. What I believe most strongly here, that founders systematically underweight distribution, is not something provable with a number. The shutdown data, Eisenmann's pattern and 557,000 apps are evidence about the environment, but the behavior is still a mystery.

The case for building first

There's a decent argument on the other side.

If you don't know what you're building, go-to-market planning is a slide deck about an imaginary product. Some things only become explicable once they exist, because the demo is the explanation. And a founder who spends two weeks on positioning before writing a line of code has produced two weeks of nice opinions.

I think that's right up to a point; I don't write a channel plan before I build. I do make myself say out loud who it's for and what they're doing today instead, and if possible, get into a conversation where I hear a prospective user say it in their own words. Because if that isn't obvious, then the build is a guess.

What that means

The three I write down, in this order.

Who is this for, named tightly enough that I could go and list ten of them by name or by search this afternoon. "Small businesses" fails that. "Freelance bookkeepers running more than eight clients on QuickBooks" passes.

What are they doing instead, right now, today. Usually a spreadsheet, a person they're paying too much, or nothing at all while the problem quantifiably costs them something.

Where would they hear about a thing like this. The place that specific person already goes at 11pm when the problem is biting, which in my experience is rarely the channel the founder would most enjoy using (LinkedIn, looking at you).

All three change what gets built, which is why you should write it down before the build instead of after it.