The Narrow-and-Deep Community Wedge
Win one persona, one context, one use case in a community you can meaningfully influence — then widen.
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 93%
Snyk reached its first ~100 users (and eventually ~5,000 free users) not by addressing the whole security market but by picking a single persona in a single context with a single use case: Node.js developers worried about vulnerabilities in their open-source dependencies. The community had to be small enough that the founders could personally influence it, yet large enough to support a business. Depth beats breadth on the path to product-market fit because a JavaScript developer does not care that you support Go — they care that a key feature works fully for their ecosystem.
Origin
Described by Ben Williams (VP of Product, Snyk) as the strategy of founders Guy Podjarny, Danny Grander and Assaf Hefetz. Williams notes it is now a well-proven playbook in developer tooling, citing New Relic's early focus on the Ruby community as a precedent.
Core principles
- 01Narrow enough to build a compelling solution fast; wide enough to be viable for growth.
- 02Depth in one ecosystem validates the solution; breadth only dilutes pre-PMF.
- 03Pick a community you can meaningfully influence in person, not just address.
- 04One repeated question, asked to that community, is a better hook than a feature list.
- 05The lure of the big total market is a trap before you have earned the right to capture it.
How to run it
- 1
Find the market shift you can ride
Identify an adjacent technology or workflow shift already gaining traction (for Snyk: DevOps plus the surging adoption of Node.js and the explosion of open-source dependencies). The wedge should sit on a curve that is already moving.
Pro tip Look for a community that is growing but still small enough that a handful of founders showing up at conferences moves the needle.
- 2
Define the super-specific who
Reduce your target to a single persona in a single context with a single use case. Snyk's was: developers building applications with Node.js who were pulling in open-source components and wanted to know they were secure.
Pro tip Write the persona as one sentence with no 'and also' clauses. If you need a comma-separated list, it is not narrow enough.
Watch out Do not add a second ecosystem 'while we're at it'. Each one halves the depth you can deliver.
- 3
Build one hook question that creates urgency
Craft a single question you can repeatedly ask the community whose honest answer is 'I don't know — and that scares me'. Snyk's was: do you have known vulnerabilities in your apps? The product exists to answer it.
Pro tip The best hook is a question the person cannot answer without your product.
- 4
Go where the community physically is
Snyk's founders went all-in on the Node.js community: presenting at dev conferences and meetups, running online content, being deeply and personally involved. Snyk was first unveiled at the Velocity Conference in Amsterdam.
Pro tip It is less about one forum or subreddit and more about the people themselves — follow the persona, not the channel.
- 5
Nail depth before you widen
Deliver every key feature (for Snyk, automated package upgrades) completely for the one ecosystem before supporting a second. Only expand when retention proves the solution, or when a monetization constraint forces breadth.
Pro tip Snyk only broke depth-first when enterprise buyers — accountable for an entire application estate with diversified tech stacks — made narrow coverage a blocker to the sale.
Watch out Expanding on the lure of a bigger market rather than on evidence is the failure mode. Build a service to the market well enough to capture it first.
In the wild
Rather than selling security tooling top-down to CISOs like every incumbent, Snyk's founders embedded themselves in the Node.js community, presenting at conferences and meetups and repeatedly asking developers whether they had known vulnerabilities in their apps. The command-line tool ran locally or in CI/CD, letting developers own their own security without being pulled out of their workflow.
→ The first ~100 users came purely from founder engagement with the Node.js community, growing to roughly 5,000 free users before any monetization was attempted; Snyk later reached an $8.6B valuation with 2,000+ paying customers.
Even at the time, npm hosted around 200,000 open-source packages downloaded roughly 2.5 billion times a month by over 2 million developers, and a typical Node app carried hundreds of mostly indirect dependencies — each one a security risk.
→ The 'narrow' wedge was still a multi-million-developer market, proving that a single persona and use case can be both deep and commercially viable.
Common mistakes
Going too wide too early
Supporting many languages and ecosystems shallowly means no single developer gets a complete solution. A JavaScript developer will not care that you support Go or Rust, but will absolutely care if automated package upgrades don't work for their ecosystem.
Confusing the addressable problem with the initial target
Vulnerable open-source components affect every language. That size speaks to the opportunity to be unlocked later — it is not a reason to start there.
Is it for you?
Best for
Founders of developer-tool and technical B2B products pre-product-market-fit who have a broad problem and must choose one entry community.
Not ideal for
Companies whose buyer is a centralized executive with an estate-wide mandate from day one, where partial coverage is an immediate deal-breaker.
From the transcript
“they started with a really narrow early Focus as a single Persona single context single use case”
“the key for sneak I think was just not to go too wide too early”
“a JavaScript developer just won't care if you support golang or rust but will absolutely care if a key feature like automated package”
From the episode
How Snyk built a product-led growth juggernaut
Ben Williams (VP of Product at Snyk)