The Roadmap to PMF (Jason Cohen's essay)
Jason Cohen took two companies past a billion dollars in valuation — SmartBear and WP Engine — but by his own account only one of them actually followed his eight-step roadmap to product-market fit. Jack walks through the whole roadmap, including the parts Cohen admits he personally skipped.
This is a solo essay episode. Jack digs into an article by Jason Cohen, founder of WP Engine and SmartBear, laying out an eight-step roadmap from an initial idea to product-market fit, drawn from eighteen years of his own writing on the subject.
Along the way, Jack pulls in a short ad-read clip from Uttpal at Digger.dev, and reacts throughout with his own commentary on where the roadmap maps onto what he's experiencing building his own startup.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
What's the overall shape of Jason Cohen's roadmap?
Cohen frames it as the step-by-step process that took WP Engine from an idea to a unicorn, while acknowledging there's no fail-safe formula — just a progression that describes how it actually happened, backed by eighteen years of his writing. The eight steps are: personal fit (passion is useful, but winning requires a personal edge); market fit (most good ideas aren't good businesses); customer fit (talk to customers before wasting months building the wrong thing); build and ship the SLC — simple, lovable, complete, essentially Cohen's version of an MVP — quickly, since that's where real learning happens; marketing and sales, which matter more than writing code; retention-driven product development, attending to existing customers first; ruthless, systematic prioritization; and managing your own psychology through a journey of constant rejection. Jack notes this expands on what Marc Andreessen wrote about market — Andreessen's essay is great at lighting a fire under you, but Cohen's roadmap goes further toward giving you an actual opinionated process.
Step one: personal fit. Why isn't passion enough?
You start a company with nothing — no product, no customers, no brand, no distribution, and less money and time than your competitors. To succeed you need an edge. Is passion that edge? Cohen says no — most artists, philosophy majors, and the 80% of startups that fail despite genuine founder passion prove that passion alone doesn't cut it. It's necessary, especially in the dark times when your savings are depleted and you're facing constant rejection, but it doesn't give you a competitive edge, because every other founder has passion too, and big companies have mountains of advantages that make passion look like a slingshot against an aircraft carrier. The real question is: why are you the perfect person to build this company? That comes from your unique mix of leverage — talents, taste, and experience — combined with your specific approach to the problem. Cohen's example is cartoonist Scott Adams: not the best illustrator, not the best comedian, but uniquely positioned by being in the top 25% across illustration, humor, and tech-sector experience simultaneously. The goal isn't to be the best at any one thing, but distinctive in the combination.
Step two: market fit. Why can't you just build for yourself?
Once you understand your own edge, you turn outward to figure out whether the idea actually fits the market — the world of customers, competitors, trends, and jobs to be done that you don't control but must understand and exploit. Product-market fit means fitting into the market, not building something fun or ego-enhancing — that's a fine reason for a side project, but not a reason it'll become a real business. 'I had the problem myself, so I built a product to solve it' is probably the most common startup origin story, but your own relationship to the problem, as a founder rather than a typical customer, makes you a poor proxy for your actual market — your customer, after all, isn't quitting their day job to build a business around it. Cohen quotes Paul Graham here: the way to get startup ideas is to look for problems you have yourself, but the very best ideas have three things in common — something the founders want themselves, that they can build, and that few others realize is worth doing. Building for yourself is necessary groundwork, but you still have to test it against people who aren't you.
How do you actually validate whether a market is real?
Cohen lays out a set of questions to run any market idea through: is it plausible — do 10 million people or 100,000 companies actually have the problem? Are they self-aware enough to know and care they have it? Is it lucrative — do they have real budget, and are they willing and able to buy right now? Do they want to buy from you specifically? Will they still be paying a year from now? A lot of people told Cohen they wished they'd read this article before wasting two years building a failed startup. Even when the idea feels too new for existing data to apply, he argues you can use Fermi estimation to get a working answer — a technique useful for more than just market sizing.
What does Cohen say about early strategy, before you've even nailed customer fit?
Even better than a great business model is a great strategy — not a twenty-page document, but a one-pager explaining how you'll win. It's never too early to ask how you'll leverage your strengths into a product that's great and differentiated despite your weaknesses, and to write your assumptions down so you notice, methodically, when reality contradicts them. The first idea is usually wrong — but you still need a specific one, because wandering in a random direction isn't progress, and the only way to discover the right direction is to have a clear theory of the world and notice when it's contradicted. That's what actually happened at SmartBear, Slack, WhatsApp, and Flickr: each had a specific, personal starting idea, backed by real passion and edge, that turned out wrong in a way that revealed what customers actually wanted — and only a deliberate pivot from a clear starting theory got them there. It wasn't a lucky accident; it was an intentional correction from a clear hypothesis.
Step three: customer fit. Why is talking to customers non-negotiable, even though they're unreliable?
There's only one source of truth for what customers will actually buy: customers — not advisers, not experts, not Twitter polls, not competitors' behavior. Customers are fickle: ask if they'd pay $100 for a feature and they'll say yes, then not buy it once you build it. But you don't talk to them to get a reliable yes — you talk to them to get a reliable no. Yes is maybe; no is no. If someone says they don't have the problem or don't care, you can trust that and move on, saving yourself months or years. If they say they do have it, that's worth exploring further, but still needs evidence. Talking to customers also tells you where they look for solutions, what language they use to describe the problem, how their budgets work, what they're doing about it today, and what specific event causes them to finally act. It's easy to find survivorship-biased examples of companies that never asked customers what they wanted and still succeeded — that happened to Cohen himself at SmartBear — but that relies on luck, and most of the time you don't get lucky. The instinct is always to skip this and just build, because building is the fun part, but if you can't get potential customers to talk to you now, before you have a product, you won't be able to later either — building the product first only guarantees you built something without knowing if anyone wanted it.
How did Cohen actually run these customer interviews for WP Engine?
He calls it the iterative hypothesis customer development method: a system for interviewing that maximizes learning and drives toward a specific, executable theory. For WP Engine, he used LinkedIn to find people with the exact title and industry he was targeting — web developers using WordPress — and asked for an hour of their time on a new startup concept, offering to pay whatever they wanted for it, since he genuinely valued their expertise rather than asking for a favor. Out of 50 requests, 40 agreed, and only one asked to be paid; thirty eventually became customers. The bigger goal of these interviews isn't just validating the market, but discovering your ideal customer profile — a segment so specifically matched to your product that when they land on your homepage, it's obvious within three seconds that you built this for them. Founders worry that targeting only the ICP limits their market, but the opposite tends to happen: for every ICP customer, there are roughly ten times as many people who make similar buying decisions, and a hundred times more who take more convincing but ultimately agree too — so you end up reaching a wider market while still earning the attention and loyalty that comes from having a genuinely clear, unique message.
Step four: build and ship the SLC. Why not just build an MVP the usual way?
Interviews give you a better model of the world, but the real learning only starts once people are actually using, or not using, a product. Cohen's term is SLC — simple, lovable, complete — instead of MVP. Simple, because complex things can't be built quickly, and you need to ship fast to learn fast before running out of money and willpower. Lovable, because crappy products are insulting, and love can overpower bugginess or a thin feature set. Complete, because customers want a v1 of something simple, not a v0.1 of something broken — the product still has to actually accomplish the job. If you spend six months building and no customer has used it yet, you're not on the road to product-market fit at all; you've only proven you can build software, which you already knew. Learning starts the moment customers try to use it.
Step five: marketing and sales. Why should this come before more coding?
Your natural inclination as a builder is to do what you enjoy and understand — writing code — so you have to consciously push yourself into marketing and sales until it feels uncomfortably like too much. Ask yourself daily: what can I do today that gets more of the target market to the website, converts more visitors into trying the product, or converts more trials into paying customers? Sometimes the answer is inside the product — improving onboarding might lift the try-to-buy conversion — but more often it isn't, and several of these steps happen before someone has even used the product. Code can become your enemy in the sense that it's the comfortable thing you'll do anyway; you don't need to be reminded to write it. Setting an explicit daily intention to make progress on one of those three questions is how growth actually happens.
Step six: retention-driven product development. What does a cancellation actually tell you?
Think about what it means for one person, out of billions, to notice your ad or post, click through, get intrigued enough to try the product, like it enough to pay, start using it — and then cancel. After every one of those positive signals, they decided this isn't what they want. That means you made the right promise but didn't keep it: marketing is where you discover the promise customers want, and retention is where you discover whether you're actually fulfilling it. Some people believe low retention is fine if you can outrun it with growth, but that's false for two reasons — growth eventually slows and halts sooner than you expect, and if customers don't want to keep using the product, the growth you did get is fake, because it's not real product-market fit if the market decides, after actually using the product, that it isn't a fit. To improve retention, you need to understand why people cancel, which is hard because they don't want to talk to you once they've left — you might incentivize interviews with gift cards, or better, watch for signs someone's struggling before they churn and reach out while they're still in it. The goal isn't finding what unsuccessful customers have in common, since successful customers often share those same traits — it's finding patterns unique to unsuccessful customers, which points to specific fixes: promoting an underused feature, adding an integration, or tuning your ICP toward industries, company sizes, or use cases that are already a better fit.
Step seven: ruthless prioritization. What system does Cohen recommend?
More than a general admonition to focus, Cohen wants you to combine milestone planning with the rocks-pebbles-sand prioritization system. First, be crystal clear on the single next milestone — finding a business model, a public launch, 20 paying customers, moving trial conversion from 1% to 5%, cutting monthly cancellation from 7% to 4%, hitting $10k MRR so you can quit your day job — write it down, look at it every morning, and treat everything else as either a distraction or a necessary evil to dispatch quickly. Second, be equally clear on the current obstacle blocking that milestone — pick the uncomfortable, existential one, not the comfortable one. Third, use rocks-pebbles-sand: if you fill a jar with sand first, the pebbles and rocks won't fit, but if you put the rocks in first, everything fits. Prioritize one rock that attacks both the milestone and the obstacle together — you don't have time for more than one, and if you can't think of a good enough one, don't proceed with a mediocre plan for the next three months; go brainstorm a better one with friends or customers instead. Schedule pebbles sparingly using an ROI framework for whatever else justifies your remaining time, and let almost everything else be merely good enough — almost nothing you do will actually determine whether the company succeeds, which means most metrics should be satisfied, not maximized, and design matters less than you think, except for the occasional obsessive detail that turns out to define the whole experience.
Step eight: managing your psychology. What's actually hard about this?
Facing the truth about your abilities, your customers' actual wishes, and the real shape of the market, without letting what you wish were true get in the way. Finding yourself — figuring out what's genuinely important versus merely necessary or temporary. Making clear decisions: what you're not good at and shouldn't try anyway, your place in the market, your ICP, your current milestone — and having the fortitude to actually commit. Enduring constant rejection: bad ideas, invalidated assumptions, silent website visitors, dead-end sales calls, customers who buy and then leave, employees and investors who say no. Accepting fluid change, even though rejection demanding a change is difficult to accept and hard to distinguish from noise. And acting while uncertain — being all-in while knowing you're wrong about some things, while experts tell you you're doing it wrong, while feeling like an impostor, even while it looks like everyone else has it figured out. Cohen's reassurance: they don't, really. This might be the hardest thing you ever do, and it's why so many people quit. It's much more comfortable to retreat into what you already know how to do — writing code, learning a new framework, building whatever feature excites you — and call that perseverance, when it's actually diligence in the wrong direction. Perseverance is a virtue only if you're doing the right work toward the right goal.
Did Cohen's own companies actually follow this roadmap?
Only halfway, by his own admission. SmartBear's first product, CodeHistorian, was a personal project Cohen built to learn .NET, with no customer interviews beforehand. He talked to customers a lot after they started paying, and learned many were abusing it to accomplish something else entirely — which led him to build CodeReviewer, whose architecture and features were still all wrong, but whose customer feedback gave him the confidence to rewrite everything into CodeCollaborator, which made millions. He's clear that interviewing customers up front, using his own iterative hypothesis method, would never have surfaced CodeCollaborator, because he wouldn't have known what to ask and they wouldn't have known what to tell him — he'd have just learned CodeHistorian wasn't a good idea, full stop. So SmartBear followed steps one, four, five, and six — personal fit, building and shipping fast, marketing and selling, and listening to customers for retention — but skipped market and customer fit entirely, and it still would have failed if he'd also skipped the steps he did follow: coding in isolation instead of selling, or ignoring what customers actually wanted.
What did WP Engine do differently?
WP Engine followed the roadmap exactly. The original idea wasn't a hosting platform at all — it was a marketing analytics tool with features Google Analytics lacked. Twenty customer interviews later, Cohen learned the idea wasn't strong enough, but the process itself worked: a specific idea, vetted with real customers, saved him from wasting years on it. From there he had the idea for a managed WordPress platform, because his own blog kept crashing whenever it hit the top of Hacker News, and other bloggers told him they had the same problem and no solution. The iterative hypothesis method this time confirmed real willingness to pay and a market that was already huge and growing — WordPress powered 11% of the top 10 million websites at the time, 43% by 2023. He built the first version in thirty hours, without even a customer dashboard, taking credit cards through a generic third-party web form. He did marketing and sales before the product even had a login screen, launching with 30 paying customers. WP Engine hit $1 million ARR in eighteen months, and sometimes went a full year without shipping a new feature because all engineering time went into scale, speed, and uptime instead — which produced best-in-industry retention for fifteen years, feeding growth back through word of mouth, referrals, and reviews. WP Engine hit product-market fit in 2012.
Does that mean everyone has to follow every step in order?
Cohen points to a thread from Simon Heuberger explaining why his second bootstrapped company, Feedhive, succeeded where his first failed: talking to users and listening instead of assuming he knew better, building in an already-validated market instead of trying to innovate, marketing consistently and sustainably instead of chasing growth hacks, keeping the product slim instead of solving everything for everyone, prioritizing UI and UX, and focusing on users who genuinely appreciated the specific way the problem was being solved. Cohen's answer to whether you have to walk the whole road, like Simon and WP Engine did, or can stumble onto it halfway like SmartBear, or take a totally different route, or cherry-pick the parts you like: yes to all of it. Everything is possible, but not every road is equally likely to succeed — outlier stories are interesting precisely because they're exceptions, and exceptions aren't repeatable, so they may not teach you anything useful. Cohen believes this roadmap is repeatable: not a guarantee, but a process that makes sense. It's your life and your choice which road to take.
Links & references
This episode is brought to you by WorkOS.