The playbook was built for another market · 00:00

I joined a startup that was already running a PLG motion, and it was working. Ten thousand free signups, then twenty thousand, forty, sixty thousand before they even launched the paid version. And when they did launch it, everyone expected some of those people to convert. So what percentage do you think did?

Fifty percent would have been incredible, but even the most bullish PLG advocate wouldn't ask for that. So what then? Twenty, ten, five?

Zero.

Not one of those sixty thousand signups converted.

Not roughly zero, not relative zero, absolute zero. And it wasn't a bad product. I mean, sure, not all sixty thousand stuck around, but a lot of them became genuine active users.

So what went wrong? And more importantly, how did we fix it?

Who this is for · 01:05

Most of you have been handed a playbook for selling your product, usually by someone with your best interests at heart, an investor, an advisor. That playbook wasn't built for what you're doing. What you're doing is selling deep tech, AI for engineering. Could be chip design, PCB design, CAD, simulation. Some people call it physical AI. You sell software business to business into the engineering organization of a large legacy enterprise. Not a startup, not even a large startup. Those are the logos that prove product market fit. And the cost of onboarding and supporting AI for engineering inside a company like that doesn't work at a credit card price. So product-led growth stalls. Founder-led sales stalls too. I've watched it happen to too many deep tech startups. So today I have just one question. Who actually buys this? Everything else, what you show them, how you find them, how you get your company ready, starts from there.

Hi, my name is Darin. I spent fifteen years in product marketing at the big companies in this space, Cadence, Synopsys, Altium. But for the past few years, I've worked with startups, taking the next generation of AI for engineering tools to market and selling them into the kind of companies that otherwise would only buy from Cadence or Synopsys.

So let's begin.

The engineer who loves it cannot buy it · 02:47

Think about the best demo you've ever given. The engineers lean in. Somebody asks to try it on their own project, and at the end they say, "We need this." You walk out sure you've got a deal.

And then nothing happens. Nobody says no. The replies just get slower, and the pilot never quite gets off the ground.

Because the user is not the buyer.

The person who uses your software isn't the person who pays for it.

They're measured on different things. And no matter how much the engineers love your product, they don't have any money.

Now let's think about a deal you're working on right now, and every person who could stop it. Most of them you've never met. Most of them you will never meet. And any one of them can kill the deal without ever talking to you.

Remember those sixty thousand signups? None of them were ever going to buy. The work that tool does only happens inside large legacy enterprises. And an enterprise is built to avoid risk, layer on layer of checks, all there to stop failure. Everyone's incentive is to not get blamed.

They're not paid to make things right. They're paid to make sure nothing goes wrong.

So even our users at the companies we wanted had nothing to gain by taking a chance on a startup, and no authority to even if they did want to.

This isn't a big versus small issue. A five thousand person startup still lets an engineer make the call because building is the job. Meanwhile, a legacy enterprise has already built its technology. Its job now is protecting shareholder value, and that makes it risk-averse. It's building versus protecting.

So you think, "fine, I'll skip the engineers and go CEO to CEO, founder-led sales." But founder-led sales runs on credibility. And to a legacy enterprise, you don't have any. You're an unknown risk walking into a building organized around avoiding unknown risks.

Which leaves you one move. Find the people inside that building for whom none of this is true.

Your buyer is the VP of R&D · 05:21

Now, they do exist. People in these companies who aren't measured on nothing going wrong.

Whoever they are, they need authority. In a large enterprise, that means a VP, but not every VP is your VP.

Some VPs want stability, reliability, predictability. You're a janky startup. You can't give them any of that. However, other VPs want new ideas fast. You're looking for the VP with the authority, the budget, and the job of being fast and creative.

That is the VP of R&D, not the VP of engineering. Engineering lives in production. R&D still lives in fail fast.

Look, that title will vary. Advanced development, office of the CTO, a venture group. Sometimes R&D is the team that ships, and what I'm describing lives somewhere else. So don't hunt for the title, hunt for the function, the group whose job is to find out whether something works, not to ship it.

And that group has a problem. The company is trying to deliver for shareholders, and from the outside, R&D doesn't look like it's doing that, especially not this quarter, not on any spreadsheet. So R&D gets squeezed more with less every single year. They lose the headcount argument every time.

So when you walk in talking about 10x-ing their engineering, nobody in the building listens harder because they know they'll never get 10x the engineers.

But just finding the right person isn't enough.

They're still trapped by circumstance. The big incumbents lock these companies down. Nobody ever got fired for buying IBM. They sell exactly what the company thinks it wants, nothing going wrong. They standardize everyone on their platform and make it sticky so nobody in production dares try anything else. So you're not gonna start with production because they'll only see risk.

But R&D doesn't have to follow those rules. R&D isn't in the production flow, so nobody measures them on nothing going wrong. R&D in general, and prototypes specifically, are the part of the company most open to a new vendor like you.

Look for the squeeze. Every large company has a shared resource everyone needs, and there's never enough of it. A verification team, a simulation cluster, a firmware group taking requests from six product teams. Two teams compete for it, and one loses. The team that loses has to find another way, and that's your opening.

And look for the right kind of work, projects with no risk because they were never going to leave the building. Prototypes, one-off, disposable, isolated. They exist to generate learning. The learning goes to production. The prototype gets thrown away.

The incumbent's flow looks safe, so you need to show that the real risk is getting left behind. And on prototype, failing isn't a risk because that's what prototypes are for.

So that's who you sell to, the team that's allowed to fail.

Now, some of you are thinking you won't build a billion-dollar company selling prototyping tools to one squeezed department. And you're right. We'll come back to that.

Get in, then prove it · 09:13

But first, how do you get in front of R&D? Through the innovation department.

Even the most risk-averse companies know they need innovation, so many of them run a team for it. Maybe it's called corporate innovation, an innovation lab. Its whole job is bringing new tools in. Some even have a venture arm, so they'll pay you to use your tool and give you access to capital. They're out scouting for startups like you, so we need to make sure they can find you.

But there's a catch. The innovation department is measured on how many new tools it brings in. Production is measured on shareholder value. R&D is measured on new results. Three teams, three different objectives.

So yes, the innovation department brings you in, and then it moves on. Closing them is the start of your next sale, which is to get the rest of the company to use you.

And their money is a one-time deal. If a team wants to keep using your tool, it comes out of that team's budget, and that's where your results come in. By then, the team has data showing you make them faster and more productive. So when they go for budget, they're not asking for a favor. They're showing numbers that matter to the company.

The innovation department's money gets you in. The team's own results keep you there.

That's how land and expand starts. One team in one part of the business, then the next and the next until you've taken over the organization.

But it won't happen on its own. These companies are execution systems, not knowledge-sharing systems. The team down the hall has never heard about your deployment, and nobody's going to tell them. So while you make the first R&D team successful, you find your own way into the next. Don't wait for an introduction.

Even your champion can only take you so far. In electronics, there is, for example, a line between RF and analog. The RF team has its trusted tools and its rejects. The analog team has completely different ones. Neither buys just because the other did. Whatever you sell, there is a line just like that. You need to know where it is, because then you'll know what your champion can and can't do.

So if every expansion is really a new logo sale, how do you start? With proof, not hype.

Inside the building, that's a case study, not a public one. They'll never let you put their name on your website. Their legal team's job is to protect them from people like you. But you can still build the case study. You just can't publish it outside.

Give it to your champion. Your champion wants to show results because results are what get them promoted. So make them the hero. Then put two teams in a room and call it a knowledge transfer. Team A explains what they did. Team B listens because it rhymes with their own work.

Outside the building, you need proof people can see, and your early customers won't give it to you. So build it yourself. Point your own product at a real problem and make something that didn't exist before.

Now, I've done this plenty of times. Let me tell you about one example. We took a real piece of hardware, not a toy, not a demo. We ran it end to end through our tool and manufactured it into something that you could hold in your hand. Then we counted every hour of human effort and measured it against doing the job by hand.

It came out over 10x faster, just shy of 15x.

We published everything, including the parts that didn't work. And boy, there were parts that didn't work. The story was never look at our tool. It was look at this cool thing we built in a way nobody had built before. And that's why the media talked to us.

That was the same startup with sixty thousand free signups. This campaign turned it around and helped land the raise.

So a journalist, though, doesn't care that your product is awesome.

They get thousands of those pitches every day. They care about something done for the first time or a result that means something to their readers. One editor put it to me bluntly. Every minute he spends wading through corporate waffle is a minute he's not finding something interesting for his readers.

A result they actually want gives him something to build his own brand with. So publish what worked and what didn't. Publish the effort. How long it took with your tool and how long it would have without. You need numbers, not claims.

Now, backing up, remember the innovation department that needs to find you?

This is how. You take your results to the trade press because that's what the innovation teams read, not vendor websites. Your public project isn't just proof for the people you're already talking to. It's actually how you get their attention in the first place.

How a prototype becomes production · 15:02

Now let me tell you about another company. It became massive by selling to the prototype team first. Prototype teams in R&D are free of the constraints the rest of the company lives under, so they aren't tied to the CAD managers, IT, InfoSec. So they aren't tied to the incumbent. They can try tools from a startup, and what they care about is speed and productivity, and they need the data to prove it. So for a while, we sold into the R&D and the client built their prototypes with our tool because it was better.

Then production rebuilt the same designs in the incumbent's official flow. Nobody thought it was weird. These are different teams with different objectives, which means, yes, the company was paying for both. Yes, two full sets, two full workflows. And the incumbent didn't lose a single seat, so they had no idea up until the last moment when they lost all of them.

Because eventually someone asks, "Why are we building the same thing twice? If it works in prototype, why wouldn't it work in production? If it works, it works, right?" Yeah, good enough. Now, the engineers might have disagreed. They might even have been right, but they didn't decide. The people who decide sat a few floors up looking at two teams and two sets of numbers.

From up there on their spreadsheet, the engineers' objections don't show. But what does show was one team using a tool that made them ten times faster than the other, and there was data to back it up. So we displaced the incumbent in production too. The account grew substantially, and we did it again and again. That path is open to you.

That's how you build a big company starting with prototype tools. You don't go straight for production. You don't go for the jugular. You sell to the team that's allowed to fail, and you let production come to you.

Be enterprise-ready before they ask · 17:10

But once you do that, you've crossed a line. The moment you move towards production, you're under every constraint that R&D got to skip.

So you need one more kind of proof, and this proof isn't about your product, it's about your company. There are people who can say no, and you'll never meet them: IT, legal, security, procurement. They'll send you security questionnaires and run a vendor risk assessment, and you won't be in the room to defend yourself.

The only person in that room is your champion. And can you really trust them to tell your story for you? So you need to put it in writing before anyone asks. Ideally, it's already on your website in a trust center because the procurement team will go looking. When they find it there, published, polished, finished, it tells them they're not the first to ask.

Someone's already gone down this road, and it was fine. So specifically, I'm talking about your SOC 2 Type II certification, terms of service, policy on AI training, policy on how you protect their IP, business insurance, all that boring stuff written out clearly in advance, not thrown together in nine hours on a Thursday night.

And please have lawyers on standby to review NDAs immediately. Not tomorrow, not next week, but they need to be ready immediately. Enterprises will buy enterprise-grade tools from enterprise-ready vendors. You need the proof too about you, not just your product. Because look, everybody wants to be early, but no one wants to be first.

The short version · 18:58

All right, so what stands between you and 18 months of runway burnt on a go-to-market motion that was never gonna work for you to begin with? One, engineers can't buy, no matter how much they love your product.

The buyer is in R&D. Sell to the teams building prototypes because failing there costs no one anything. Three, the innovation department is what gets you in. Proof, not hype, gets you everywhere else. Inside the building, a case study that never leaves.

Outside, results the press actually wants. Four, let the prototype become production. Sooner or later, somebody a few floors up will ask why they're building the same thing twice. And five, you've got to look the part. Enterprise-grade tools get bought from enterprise-ready vendors.

So go back to that deal you were thinking about in the beginning and every person who could stop it. Only a few of them can say yes, but all of them could say no. Now you know which is which, and you know what each of them needs from you. Whether the deal is closed-won or closed-lost gets decided in rooms you'll never be invited into.

Make it possible for everyone in them to say yes without you. Thank you.