Startup Success Stories Are Flawed

March 2025

In his book on mapping business strategy, Simon Wardley makes an observation that struck me hard recently.

You cannot learn chess from a list of moves. Even with access to every grandmaster game ever played, simply studying the sequence of moves will not make you a strong player. Without understanding the board position, the strategic context, and the invisible forces at play, these move lists are merely shadows of the actual game.

This observation triggered a thought that has been bothering me about how we approach startup knowledge and learning.

The Invisible Board

Here is a typical chess game move list:

  1. e4 e5
  2. Nf3 Nc6
  3. Bb5 a6
  4. Ba4 Nf6
  5. O-O Be7
  6. Re1 b5
  7. Bb3 d6
  8. c3 O-O
  9. h3 Na5
  10. Bc2 c5
  11. d4 Qc7
  12. Nbd2 Bd7

Without understanding the position, these moves tell us very little. If we try to learn chess just by reading lists of moves, we will never truly understand the game. We will always lose against someone who can read the board and see the deeper strategy at play. Was the bishop retreat on move 7 brilliant or desperate? Did castling on move 8 create safety or vulnerability? Without seeing and understanding the actual position, we cannot know.

What we learn from is not the notation you have but …

  1. Pawn Pawn
  2. Knight Knight

Not just this, but this

Startup Success Stories are a Move List

We consume endless articles, case studies, and advice about startup success:

  • “Talk to 100 customers before writing any code”
  • “Run a landing page test with £500 of ads to validate demand”
  • “Price high and work backwards to find your ideal customer”
  • “Don’t raise money, bootstrap your way to success”
  • “Reverse trials are a waste of time”
  • “Don’t hire developers, use AI”
  • “Build an email list of 10,000 people before launch”
  • “Focus on SEO from day one”
  • “How to get featured on Product Hunt and get to #1”
  • “Tools to cold email 1000 potential customers”
  • “How to create viral TikTok content to drive signups”
  • “Build in public and document everything”
  • “How we got featured in TechCrunch before launching”
  • “Hire only senior engineers at first”
  • “Ignore the enterprise market”

Each piece of advice represents a “move” that worked for someone else. We dutifully collect these moves, attempting to replicate them in our own ventures. Yet something is missing.

Just as a chess move list cannot convey the full strategic situation, startup advice often fails to capture the invisible forces that shape success or failure. Network effects create resistance or momentum. Technological constraints form boundaries of what is possible. Timing determines whether an identical strategy leads to breakthrough or bankruptcy.

We can take this further: startup business advice is even worse that the chess move list above, because at least the chess list has positional information that helps you infer the board. Our business advice is directly parallel “Pawn Pawn”, “Pawn Pawn Knight Knight”, which is even more difficult to interpret.

An example: in the early 2000s, I worked at a gaming company called Elixir Studios that attempted to simulate an entire country. The idea was brilliant. The team was capable. But the hardware of the time created an invisible wall. The moves were right. The wider environment made them impossible. (The company did not survive, although the games were great, and our founder went on to do great things, so perhaps it was for the best.)

Beyond the Move List

We talk about headwinds and tailwinds in business. About going uphill or downhill. These metaphors hint at forces we can feel but cannot see. Forces that no case study or advice article fully captures. Forces that determine whether copying someone else’s “moves” will lead to success or failure.

Perhaps what we need is not more move lists. Not more step by step guides or success stories. Perhaps we need new ways to map and understand these invisible forces.

Wardley gives us one type of map, showing how components evolve over time and create strategic positions across the value chain.

What other dimensions are we missing? What other forces shape the game we are trying to play?

How do we learn to see these invisible forces? How do we develop an intuition for timing, for resistance, for possibility? How do we move beyond copying moves to understanding the board?

The next time we read a startup success story or piece of advice, we should remember that we are seeing only the moves, not the board. The real question is not “what moves led to success?” but “what forces made those moves possible?”

And perhaps most importantly: what forces are shaping the board for us right now?


Thanks to Simon Wardley for feedback on an earlier version of this article, and for the original observation that sparked this one.


More articles

Coding with AI: How To Do It Well And What This Means

I am shipping AI-first production code every day. Not experimental features. Not throwaway prototypes. Real, deployed, mission-critical code powering Cherrypick’s tens of thousands of users.

Social media overflows with “vibe coding” demonstrations. These flashy but superficial examples show AI apparently conjuring perfect code in seconds. The reality of professional AI-assisted development runs much deeper. Real production work with AI is messier, more nuanced, and demands rigorous thinking, but very effective.

This is not about magical code generation. It is about a new way of thinking about development. It requires substantial real-world development experience to do well: the onus is upon those of us with this experience to teach the next generation how to harness these tools effectively.

This is how I am doing it, what it all might mean, and how we can help others find the way.

Read more

Founder mode is emergency surgery

“Founder mode” is emergency surgery. It is not the right way to run a healthy business.

If your company is sick, you need to fix it. That means courageous decisions only you can make. You will need to dive in and operate sometimes. That doesn’t mean you create bottlenecks by deciding everything for years to come.

Read more

How to Build a Robust LLM Application

Meal Generator

Last month at Cherrypick we launched a brand new meal generator that uses LLMs to create personalized meal plans.

It has been a great success and we are pleased with the results. Customers are changing their plans 30% less and using their plans in their baskets 14% more.

However, getting to this point was not straightforward, and we learned many things that can go wrong when building these types of systems.

Here is what we learned about building an LLM-based product that actually works, and ends up in production rather than languishing in an investor deck as a cool tech demo.

Read more

Why Hybrid Work Works

As someone who lives an hour and a half from my London office, I love working from home. I can help my teenagers out of the door in the morning, and I am present when the family comes home. I can have coffee with my wife Ellie before we start work. I prepare dinner during my lunch break, and receive deliveries. I can contribute more effort during my day to Cherrypick, free from distractions, interruptions and the long commute. I would struggle to work effectively five days a week in London.

I also love working from the office. It is an opportunity to spend real time with the people I work with. Communication is easier and I spend less time on screens. I can train less experienced colleagues much more efficiently than video chat. I can ask for and give advice and help in person, cutting down long feedback cycles. I would struggle to work effectively five days a week from home.

Much of the debate around hybrid working appears to be a zero sum argument about why working from home is “better” or “worse”, and why working in the office is “more” or “less” productive.

One is not better than the other; they are just different. I think we need both for a balanced life.

Here are some pointers for how to have a productive conversation about hybrid in your team.

Read more

The Job Is Not To Build

Startup CTOs or founding developers are the first technical people in the business. It is natural to think your job is to write code and build software. This is backwards.

Your first job is not to build software. Your role is to use your technical expertise to help the startup figure out fast if you have a valid solution to a compelling problem, and then a valid product for a big enough market.

You might do this through building software, but you might not need to.

Here is a story of how I did this wrong, and how you can do it right.

Read more