What Two Exits And Too Many Failures Taught Me About Growing Successful Companies
Founders don't fail because their idea is bad. They fail because they never stop to ask whether anyone actually needs it — at least not in the way they imagined.
Daniel Johnson has built around 100 companies over the past decade. The vast majority of them crashed. Two of them sold — one to a private equity firm, one to a competitor. And in the gap between those outcomes, he developed something more useful than any single tactic: a repeatable process for understanding customers and running experiments that actually tell you something.
His talk at Nomad Summit was a methodical walkthrough of that process. No abstract inspiration, no high-level frameworks divorced from reality. Just the hard-won logic of someone who has made most of the classic founder mistakes and eventually figured out what to do differently.
The Problem With Excitement
When you start a company, you have a number in your head. A revenue target, an exit, a vision of where it goes. That part is easy. The hard part — the part most founders skip — is figuring out the specific sequence of activities that gets you there.
Daniel describes his early approach as the conventional one: come up with an idea, build a website, convince yourself it's the best thing since sliced bread, launch a massive campaign, get zero results. Then repeat.
The problem wasn't effort. It was the absence of any systematic way to test whether assumptions were actually true before committing serious resources to them.
His answer to this is what he calls "slow, boring growth." Which is, admittedly, a slightly misleading name. It's not slow in the sense of timid. It's slow in the sense of deliberate — data-driven, structured, and designed to generate real signal rather than the illusion of momentum.
Four Questions That Replace Your Entire Marketing Strategy
Rather than building a comprehensive marketing strategy upfront — which most people either get wrong or abandon within weeks — Daniel's process starts with four questions:
- Why does your customer need this?
- How do they describe the problem?
- Where do they look for answers?
- Who specifically has this problem?
Each of these sounds simple. And they are, in the sense that they don't require any special expertise to understand. What they do require is genuine honesty — particularly the first two, which most founders think they've already answered when they haven't.
You're Not Selling What You Think You're Selling
The first framework Daniel uses is Jobs to Be Done — the idea that customers don't buy products for their features; they buy them to accomplish something specific, usually something emotional.
His example: when someone buys a skateboard, they're not buying the alloy components. They're buying the feeling of going over a jump.
He tells a more concrete story from his time contracting for a competitor to SAP, pitching enterprise software to young sales teams. When he actually talked to the users, they weren't describing their frustration in terms of software performance. They were describing it in terms of time — time spent on clunky tools, time away from their families. The campaign that performed best didn't mention efficiency at all. It said: "Get home to your kids sooner."
That reframe changed everything. Not because it was clever copywriting, but because it was accurate. It reflected the real emotion the product was solving.
The framework for capturing this is called a Strategic Messaging Map — a structured way of describing your product starting from the customer's actual language rather than your internal one. Daniel recommends Googling it and building a first version, even if it's wrong. The goal of version one isn't accuracy. It's having something concrete to test and update.
Your Customers Don't Describe Your Product the Way You Do
This is probably the sharpest practical observation in Daniel's talk, and it's one that experienced founders are just as prone to as new ones.
He describes working for a commerce platform where the entire team was developers. The internal language was all about speed, performance, JavaScript architecture. When he took customers to the pub and asked how they'd describe the platform to a friend, the answer was: "It's a shop in one line of code."
Not a word about speed. The thing that actually mattered to them was convenience — a concept the internal team hadn't even considered as a selling point.
This gap between founder language and customer language is one of the most consistent failure modes Daniel has observed. The fix is straightforward but requires setting aside ego: talk to customers, capture their exact words, and update your messaging to match. He puts it bluntly — the words customers use are always better than anything he could come up with himself.
The User Journey: Meeting People Where They Actually Are
The third framework is a user journey map — a way of tracing the path a customer takes from first feeling a problem to becoming an active advocate for your product.
Daniel's preferred model is the AARRR framework: Awareness, Consideration, Purchase, Retention, Advocacy. The insight here isn't the acronym — it's the implication for timing. Most people don't wake up ready to buy. They wake up frustrated about something. They go to WhatsApp, or watch a webinar, or search for articles. They're trying to understand their problem before they're ready to evaluate solutions.
Trying to sell to someone who's still in the awareness stage — still figuring out what the problem even is — is roughly equivalent to walking up to a stranger and proposing marriage. The relationship hasn't been established yet. What they need at that point isn't a pitch; it's something that helps them understand what they're dealing with.
Understanding which stage a customer is in changes both what you say and where you say it. And the only way to build that map accurately is, again, through conversation — asking real customers how they actually found you and what they were thinking at each step.
Three Reasons Daniel Failed
Before moving into the experimentation process, he pauses to identify the three failure patterns he kept repeating before he understood what was going wrong.
The first was scaling before validating. He thought he knew what customers wanted better than they did. He was wrong, consistently. The shift was learning to separate what he believed to be true from what he actually knew — and then testing the former before acting on it.
The second was focus. He describes himself as ADHD, currently running four businesses simultaneously, and openly admits this is a mistake. Spreading attention across too many things at once doesn't multiply output; it dilutes it.
The third was success criteria. When you run an experiment without defining what winning looks like in advance, you end up in a grey zone — too good to kill, not good enough to scale. Knowing upfront what you're measuring, and what threshold counts as success, is what makes an experiment actually useful rather than just busy work.
The Experimentation Process
The core of Daniel's framework is an eight-step experimentation loop: capture, hypothesize, prioritize, design, run, analyze, document, scale.
A few of these deserve particular attention.
On prioritization, he uses ICE scoring — rating each idea on Impact (how much will this move the needle if it works?), Confidence (how likely is it to work?), and Ease (how much effort does it require?). Each dimension gets a score from one to five, you total them, and you run the highest-scoring ideas first. It's deliberately crude. The point isn't precision — it's having a consistent method that prevents you from just doing the most exciting thing rather than the most promising one.
On hypothesis writing: each experiment should produce a binary answer. Did it work or didn't it? Vague hypotheses produce vague results. If you can't define in advance what success looks like, you won't know what to do with the data afterward.
On analysis and documentation: this is where most teams fail. They run an experiment, get a result, and immediately move on to the next idea. What they don't do is sit with the data long enough to understand what it actually revealed — which assumptions it confirmed, which it challenged, and why. Daniel keeps a Notion wiki that documents every experiment and its learnings, accessible to everyone in the company. The logic is simple: every failed experiment cost money; you might as well extract the learning from it.
Why the Basics Matter More Now, Not Less
One exchange during Q&A is worth noting. Someone asked what to do with all this analysis once you have it. Daniel's answer was that founders should run the initial experiments themselves — not delegate them immediately to an agency or contractor.
The reason is the gap it creates. Founders who hand off marketing before they understand it tend to struggle to evaluate what's working and why. Running the first few experiments yourself, even clumsily, builds a kind of intuition that's hard to develop any other way.
He also made a point about AI. He's in the process of building tooling that automates parts of this framework — feeding in business details, running customer research, generating the maps and hypotheses automatically. But his position isn't that the frameworks become less important as a result. It's the opposite. The better you understand who your customer is and what they actually need, the more precisely you can direct any tool — AI-powered or otherwise — toward the right problem.
As competition for attention increases and product development gets cheaper, the companies that have genuinely mapped their customers will be harder to displace. Not because they found a clever trick, but because they did the unglamorous work most others skip.
Growth as a System, Not a Moment
The thread running through Daniel's entire talk is the distinction between a process and a tactic. Growth hacking — the thing he explicitly says he dislikes — is typically a one-time intervention. Something goes viral, engagement spikes, and then it's over. It's not repeatable, and it doesn't compound.
What he's describing instead is something closer to a feedback loop. You build a picture of your customer. You run an experiment. You learn something. You update the picture. You run a better experiment. Over time, the model improves and the experiments get more targeted.
That's boring to describe. It doesn't make for a particularly dramatic slide deck. But it's what produced two exits from a hundred attempts — and it's what he's been refining ever since.
Sources & References
- Jobs to Be Done — Christensen Institute — Overview of the Jobs to Be Done theory of customer motivation
- Notion — Documentation and wiki tool Daniel uses to record experiment learnings