An operator founder with fifteen years of supply chain experience decided it was time to build software for the industry. The product had legs. The early customers were interested. He had the domain knowledge, a clear problem, and a handful of warm relationships. Then he made his first hire: a senior supply chain manager from a Fortune 500 who "really understood the space."
Six months later, the senior manager was frustrated. The processes weren't defined. The role wasn't structured. Nobody had outlined clear priorities. He'd been hired to apply expertise, but the company was still figuring out what it was building. The parting was expensive and demoralizing — and it was entirely predictable.
Operators hire for early-stage startups the way they hired for their corporate roles. It's not a failure of judgment. It's a failure of translation — the skills you used to build a team inside a functioning organization are largely wrong for the first few hires inside a startup.
The instinct that gets operators in trouble
In a corporate role, the best hire is usually someone with deep experience in the function you need filled. You need a controller? You hire someone who's been a controller. You need a logistics manager? You hire someone who's spent ten years in logistics. The bet is: this person has seen enough of these situations that they'll execute well from day one.
This instinct is correct for scaled organizations. It's wrong for early-stage startups.
The problem is that deep functional expertise is almost always paired with expectations. Senior hires expect structure, clarity about their role, defined success metrics, and managers who have answers to the questions that come up. None of that exists in a pre-revenue startup. The senior hire arrives with a toolkit that requires conditions that don't exist yet — and when those conditions don't materialize, both sides get frustrated.
The other problem is timing. Domain expertise becomes valuable when you have something to apply it to. Before product-market fit, the job is to find the product, not to optimize it. Hiring a domain expert to help you find the product is like hiring a production manager before you know what you're producing.
What the first hire actually needs to do
Before you write a job description, get specific about what the first hire is actually going to do in months one through six. Not their job title. Their actual tasks.
At the early stage, that list probably includes: document feedback from every customer call, handle inbound support requests that aren't product bugs, help prepare demos, assist with outreach to prospects, manage the CRM, identify patterns in what customers are saying, and run whatever project emerges that week. Some weeks there's no single project — there's six half-projects, and the first hire is helping on all of them.
The person who does this well is not a senior domain expert. It's someone with a high tolerance for ambiguity, an instinct for what matters, the ability to do good work without being told exactly what good looks like, and no expectation that their role will be defined for them. Startup experience helps, but the disposition matters more than the experience.
The equity and cost trap
Operators who try to hire senior domain experts for their first hire also usually try to pay them market rate — either in cash or in equity that far exceeds what the role warrants at that stage. The reasoning is: if I need their expertise, I need to pay for it.
The problem is that the first hire's equity stake affects the cap table and the signal it sends to investors. A first hire who takes 3 to 5 percent equity in a pre-revenue company is getting a founder-level allocation for a non-founder role. That same percent becomes problematic when you're raising your seed round and investors look at the option pool and outstanding grants.
Early hires should take meaningful but appropriate equity — enough to be genuinely motivated, not so much that it creates cap table confusion. What "meaningful but appropriate" means depends on the stage, the role, and the market, but for a first non-technical, non-executive hire at pre-revenue stage, it's typically in the 0.25 to 1 percent range with a four-year vest.
The domain expertise hire comes later
None of this means domain expertise doesn't matter in a hire. It does — at the right stage and for the right role.
Once you have product-market fit, once the sales motion is repeating, once you're growing customers and need to specialize the work — that's when you hire someone who has done the specific function you need done, at the scale you're trying to reach. That hire knows what good looks like in their function because they've operated there before.
Before that, the job is to find the product and find the customers. The people who do that well are not the ones with the most specialized expertise. They're the ones who can figure things out in real time, stay motivated without external structure, and build something from nothing without a playbook.
If you've spent a decade inside a vertical, you already have the expertise the company needs. What you need is someone who can move fast alongside you while you're still figuring out what you're building. That's a different profile than what operators typically hire, and recognizing the difference is one of the first real identity shifts that comes with founding.
Working with a venture studio that's been through this before can help you avoid the early hiring mistakes that burn significant time and equity. If you're at that stage, tell us what you're building.