Grayscale Ventures, and the startups I advise

Tectonic is a fast Shopify storefront and app, with A/B testing and analytics built in. It was co-founded by Neelesh Soni, formerly Director of Product at Myntra and before that at Flipkart, and Nishant Khurana, formerly at Flipkart and Yahoo. Grayscale led its first round.

SafeDep is open-source software supply-chain security, founded by Abhisek Datta, formerly at Chargebee. It is backed by Grayscale and Transpose, and is in the Google Cloud and Microsoft startup programs.

Middleware is engineering delivery analytics, built on DORA metrics and Jira. It was co-founded by Dhruv Agarwal, formerly at Maersk, and Jayant Bhawal, formerly at Uber. It is backed by Grayscale and Misfits, and WeWork India is a customer.

Testsigma is no-code test automation, founded in 2019 by Rukmangada Kandyala with Pratheep Velicherla, Rajesh Reddy and Vikram Chaitanya. It has raised $12.8M from Accel, STRIVE, BoldCap and MassMutual Ventures, and is used by teams at Cisco, Samsung, Bosch, Nokia, DHL and KFC. Its early backer STRIVE is the firm the Grayscale partners came from, not Grayscale itself.

Why is selling to engineers different?

Because the buyer evaluates by trying, not by reading, and they do it before they ever talk to you.

That one fact rearranges the whole plan. The docs are the landing page. The quickstart is the sales call. A benchmark you publish with its method attached is worth more than a case study with a logo on it. And every claim in a headline is checked against the docs within about four minutes, which means a headline the product cannot support does more damage here than anywhere else.

Four things earn trust with this buyer:

• A quickstart that works the first time, on a machine that has never seen your product, without an account. Watch a stranger do it. The step that breaks is never the step the team expects.

• A pricing page with numbers on it. "Contact us" tells an engineer that the price is a negotiation, and most of them will not start one. They will find something with a price.

• Stated limits. Say what it does not do, and at what scale it stops being the right answer. The team that discovers the limitation themselves on day four does not come back, and they tell the next team.

• Proof from teams that look like theirs. For this buyer, "like theirs" means similar scale and a similar stack, not a famous brand name. A logo from a company 100 times their size proves nothing about whether this works at their size.

And the measurement. An active team is the unit, not a signup. One engineer trying something alone is a bookmark. Two people from the same company in the same workspace is a deal that has started.

What is the first experiment worth running?

The one that changes a decision whichever way it comes out. That test rules out most of what gets proposed as a first experiment, because most of it is activity with a hope attached.

At pre-seed the honest first experiment is almost always about who, not about how. Pick the narrowest group you could be the obvious choice for, find 20 of them by hand, and watch what happens when they try it. If 20 hand-picked people in your best-case segment will not get through the quickstart, no channel will fix that, and a channel test run before this one just buys you a more expensive version of the same answer.

The order I suggest:

1. A position you can say in one sentence, naming who it is for.

2. Twenty conversations, done by a founder, not a contractor.

3. A quickstart that works, with the first value visible inside it.

4. One channel, funded properly.

5. The second channel only when the first has produced a number you believe.

What goes wrong at this stage is almost always the same shape: three channels running at a third of the budget each, none of them with enough volume to tell you anything. Two channels run well is the honest limit for a small team, and at pre-seed it is usually one.

When should a founder stop?

This is the part nobody else around a pre-seed founder will say, because every other incentive points at continuing.

The only reliable method is to write the stopping rule down before the experiment starts, with a number and a date in it. "We stop if we cannot get 10 teams to a second week by the end of November" is a rule. "We will see how it goes" is not, and it always resolves in favor of carrying on.

Three things I treat as signals to stop and go back a step:

• The people who say yes are all unlike each other. Enthusiasm spread across five segments is not traction; it is five conversations that will not repeat.

• The usage is wide and shallow. Many first sessions and almost no second weeks means the product has not yet done the thing the page promised, and more traffic makes the number worse.

• Every deal that closed needed something custom. That is a consulting business discovering itself, and it is worth knowing before you hire a salesperson for a product that does not exist yet.

The opposite error is real too, and it is more common than founders think: stopping a channel after two weeks on a budget that was never going to produce a signal. Stopping early is only a discipline when the rule was set in advance.

What do I tell a founder who wants to hire for growth?

Founders this early do not need a growth team yet. Most of what I do here is help them pick the first experiment, and tell them when to stop.

The first growth hire goes wrong when it is made to avoid doing the work for the first time yourself. Whoever arrives will ask who this is for, what the one metric is and what happened in the last three experiments, and if those answers do not exist, you are paying someone to wait while you find them. The test for which gap you actually have is in Your first growth hire, and which stage they should own.