Beachheads, Wedges and Spikes

Early stage products are a collision between imagination and finite reality.

Founders with large ambitions usually start with a grand, opinionated vision like this:

But because ambition leads the way, there is a natural tendency to abstract further:

Eventually, the founder realizes the most abstract tier of software (the platform or network level) is the highest-leverage, most lucrative tollbridge in the ecosystem.

The tollbridge is exactly what AWS, GCP, and Azure are. As Chamath Palihapitiya noted in his early Social Capital days:

Intoxicated by this, founders start envisioning their own generalized platform. They want to build a tool to accommodate everyone, every workflow, and every edge case on day one.

However there is a massive gap between that grand vision and day-one reality.

Trying to build the tollbridge immediately usually leads to early-stage entropy.

Without a focused narrative, teams rely on the sheer brute force of "trying stuff" and throwing spaghetti at the wall. It feels romantic at first, but soon turns into treading water. Resources exhaust quickly, and market indifference swallows you whole.

You don't just build a platform you earn the capacity to build one by solving a specific problem first.

To avoid early-stage entropy, it’s helpful to align your team around identifying specific risks and methodically removing them.

In this post, I provide three models to identify core risk and provide a strategic tool to tackle them.

Risk: Everyone’s Got A Piece of It

I encourage you to checkout Rob Fitzpatrick’s The Mom Test for an exhaustive view of the various risks, however, three core ideas of interest are:

1. Market Risk - Can we actually create value if we built <WIDGET>? (e.g., Do bar owners want more foot traffic and would pay for it?)

2. Product Risk - If we combined the right resources to create <WIDGET> is it possible to deliver the promised value? (e.g., Bar owners definitely want more customers, can we actually generate more customers through an app?)

3. Technical Risk - Is <WIDGET> even technically possible? (e.g., can modern mobile hardware actually run Llama 400B parameter model?)

You cannot defeat every market risk at once, but you can isolate them in a given frame and tackle them.

With a good cross section, you can spin up threads to tackle the core problems inherent in each.

Market Risk: Finding the Beach

One way to deter market risk is a combination of Beachhead Market and Customer Discovery.

Borrowed from military strategy and detailed in Bill Aulet’s Disciplined Entrepreneurship, a beachhead forces you to narrow your focus.

The natural trap for entrepreneurs is what Peter Thiel mentions as the "China fallacy" in his 2014 Zero to One:

The issue is broad markets give diluted feedback.

Not only that, but humans want to save face and ego of other humans; their words don’t necessarily match their actions all the time: revealed preference theory shows us that.

Moreover, a multi-billion dollar TAM is composed of millions of people with opinions and (usually) pretty different pain points.

A beachhead forces you to pick a specific, tight audience that has a high probability of intersecting pain points.

And often, it’s uncomfortably tight: like after Christmas dinner, belt needs to come off kind of tight.

For financiers, it has to be juicy enough to matter in terms of dollar value (i.e., TAM), but for strategists, the beachhead has to focused enough that you can define a user/customer and their collective struggle (i.e., UX).

Using frameworks and tactics of customer discovery, you interrogate a specific niche to gain clarity on one clear signal: Are we building something people actually want? 

This chisels away at your Market Risk.

Once you secure the beachhead, the engineering mind usually wants to revert to building the ultimate, abstract solution (it’s the biggest toll taker after all).

However, a generalized tool rarely develops a cult following.

Product Risk: Using a Wedge

When people wanted a blank canvas computation tool, they just use Microsoft Excel.

It lacks opinions, it’s flexible and it doesn’t require tool-to-tool data migrations or subscriptions to keep running.

However, as Seth Godin describes in Purple Cow and This Is Marketing: marketing, in part, is an exercise in exclusion: creating the us-versus-them.

An audience member or loyal brand customer buys because they trust that:

That is to say, marketing is in part about defining and articulating an opinionated world view about your company or product and finding the “tribe” that believes in it.

Marketing, however, is the overture to the substance of your business’ product; you can only construct your marketing veneer from a base opinion.

Such base opinions are contained in your product philosophy and design: “how things should be”, while solving a genuine pain point.

When it comes design and software, opinionated products like Superhuman or Things 3 appear to do well, because, in theory, they create a rigid point of view of “how things should be done”.

People don’t want to fight their tools.

They have so much going on in their job, they want the tool to just work.

If it doesn’t work exactly how they need, as quickly as they need it (i.e., low friction, no obstacles, not too expensive, available), they flip to the next tool.

Products are tools intended to solve a problem, so as the builder, it is prudent to avoid building an “everything tool”.

Figuring Out What To Build

A great way figure out what to build is a product strategy called a Wedge.

A Wedge is an embodiment of Paul Graham’s advice to "do things that don't scale."

Instead of building a massive, all-in-one podcasting platform, you build a highly targeted long-form content lead-gen tool exclusively for wellness coaches between 5-10K MRR and plateaued and dying for some help to get them to the next level.

Their CRM is falling apart (or non-existent), their days are infested with insidious “social media content upkeep” and they are burning out between working “in the business” and “on the business”.

In seeing that they would absolutely pay for more leads and a more sane way to manage this process you build a popsicle stick and glue automation that is almost falling over with just 10 users.

Picking a single workflow and solving it completely for a tight audience, without generalization, creates a highly targeted tool that can peel off the product risks and get you to start learning:

It sounds like a horrific idea for the engineering mindset (“Couldn’t we just generalize from the start?! Then we could have coaches, mentors and consultants!”), but at the product level you are de-risking the viability of a product idea.

For young founders or developers, this is an experiential point that’s best developed through side projects; you have to build enough crap in the “right way” (i.e., generalized, abstract, thinking of all the use cases) to realize the time invested usually worth it if there’s no business case to be made.

A wedge cuts through a distinct shard of the product spectrum and attempts to remove Product Risk efficiently.

Technical Risk: Using a Spike

Sometimes market and the product elements are obvious and feel almost entirely solved (but never assume!).

Speculating a moment:

There is a strong business case that if Apple could run a 'frontier-level' LLM (with the reasoning capabilities of a massive cloud model like GPT-5 or Claude Opus 4.6) entirely locally on an iPhone requiring: no internet, subscription, and offering total privacy, they could command a massive premium for their devices.

The Market and Product risks appear to be near zero; consumers demonstrably want this. But the Technical Risk is immense:

Before Apple engineers can design the chat UI, they have to deploy a 'Spike': a raw, UI-less, timeboxed prototype designed simply to push the thermal and processing limits of their chips to see if the physics even allow for it.

Pharmaceutical companies, synthetic biologists and drug development pipelines are constantly developing spikes.

For example, the first iteration of Isoprenoid Pathway Optimization for Taxol Precursor Overproduction in Escherichia coli, researchers demonstrated they could engineer E. coli bacteria to product taxol (an effective cancer drug pre-cursor).

However, even after the first “spike”, the technical risk is still the primary driver of the project: How does yield scale with inputs? What are the limits of host toxicity to the exogenous metabolic engineering elements? What is the upper bounds of yield to a bioreactor?

The product and market risk appear pretty low at first glance: we give you cheaper input materials, your margin expands.

The only question is “is it possible”?

Spikes help to answer that question, one by one.

Wrap Up

I know, you’re an execution driven founder and all this theory and framework stuff smells like BS.

However, I generally think if you arm yourself and your team with vocabulary, you can start building a story.

When you have a story, you have the strongest seedlings of alignment towards your goal.

When you have alignment, you can be sure you’re working efficiently towards the main objective: de-risking the business.

Layer by layer, you shed elements of risk from the business which also can coincide with further fundraises.

The opposite looks like this: multiple stakeholders with different agendas and framings, all rowing in different directions.

The result is predictable, maybe you move north west by a margin, but half the boat is rowing in the wrong direction.

Using tools like a beachhead, wedge and spike are means to create a shared alignment in objective and remove obstacles towards your business’ goal.

P.S. If you’re a entrepreneur in need of a thinking partner to talk strategy, tactics or product just drop me a line I’d love to explore how to work together.

Appendix

Table of Risks & Tools