Hiring for a product that doesn't exist yet

The recruiting pitch for the first year of Helply was: we're a 12 year old company, we're at $5M arr and flat, we've decided the product is architecturally finished, and we're spending a year building a replacement that has no customers and no revenue.

That's the accurate version. I used it, more or less, because the alternative is hiring someone on a story they find out isn't true in month 2.

Who says yes to that

A narrower group than I expected, and not the group I assumed.

I thought the pitch would land with people chasing the AI wave. It mostly didn't. People chasing the wave want to be at the company that's already visibly winning, which is rational and also means they'd have left in 6 months when a louder one came along.

Who actually said yes were people who'd been somewhere with a codebase they hated and wanted to build something from a clean data model. The pitch that worked wasn't "AI." It was "the architecture is wrong at every help desk on earth and you get to do it properly."

The other group: people who'd been at a big company where shipping took 3 quarters. The offer of shipping something real in a month is worth more than most of what you can put in a comp package, at least to a certain kind of engineer, and you can find out which kind in about 10 minutes of conversation.

What I stopped screening for

Domain experience in customer support. I'd have said this was important. It wasn't, and in a couple of cases it was actively unhelpful, because people who knew the category well kept reaching for how the category already works. That's exactly what we were trying not to do.

What I screened for instead was whether someone could hold a strong opinion and then genuinely update it. We were going to be wrong about a lot in year 1. A team that can't change its mind cheaply is a team that ships the first architecture forever.

The thing I underestimated

Telling the existing team was harder than the hiring.

Bringing people in to build the replacement for the product your current team maintains is a delicate thing that I handled adequately and not brilliantly. There's an implicit message in every new hire's job description and everyone reads it.

What helped was being direct about what Groove is now: a funded, supported, stable business that pays for the future, staffed by people who chose that work. What didn't help was the period before I said that clearly, when everyone could see the resource allocation and hadn't been told what it meant.

What I'd tell someone doing this

Say the hard version out loud in the first conversation. Not the second. The people who are going to be great at this are the ones the hard version attracts, and you're wasting everyone's time filtering them in later.

Give them something real in week 1. When there's no product, there's no obvious onboarding, and a new hire spending 3 weeks reading docs about a thing that doesn't exist starts wondering what they've done. We got better at this after the first couple.

And be honest about the timeline including the boring middle. Ours was roughly 4 months of building ingestion and context layers with nothing to demo. That's the stretch where people lose faith, and if you've told them it's coming they hold up fine, and if you haven't they assume it's a sign.

Where it landed

10 engineers, 12 months, a product that's now at $1M arr growing 7% a month. Nearly everyone who joined for the rebuild is still here.

The one I got wrong: I hired for the build and didn't hire enough for the sell. We came out of that year with a genuinely good product and a go-to-market team that was thin, and we're still catching up on that. Building the thing was the part I knew how to hire for, which is probably why I over-indexed on it.

Distribution again. Always distribution.