Stop Planning for Your Massive Hire P&L

I see a lot of seed-stage budgets. The mistake I keep seeing is a structural one.

‍

The P&L is built like it's 2016: A long line for headcount… A modest allocation for cloud compute... A polite line for SaaS subscriptions… And somewhere near the bottom, almost as an afterthought, a small bucket for ‘AI tooling’ that's typically smaller than the line for office snacks and coffee.

‍

The founder pitching me this budget will, in the same conversation, tell me they're building an AI-native company. The two things are not compatible - you cannot run a 2026 company on a 2016 cost structure and expect the math to work.

‍

I've been on both sides of this. I co-founded SignifAI in 2016 and ran it as CTO until New Relic acquired us. After that I spent years running their AI engineering platform, which means I've shipped production AI systems through three distinct generations of what that even meant. The thing I'm watching now is different in kind, not in degree. The founders who get this in their bones are running fundamentally different companies than the ones who don't, and the gap compounds weekly.

‍

The new founder operates agents before they hire people

‍

The old reflex was simple: Raise more, hire more, deploy capital into people, and treat headcount as the universal solvent for any organizational problem.

‍

The new reflex is quieter and more interesting. Build leverage first, and hire only into the gaps the leverage cannot cover. The cleanest companies I see right now are running with three or four humans and a layered set of agents handling work that a year ago would have required a team of fifteen.

‍

This is not a cost-cutting exercise. It's a different theory of the company.

‍

You're a PM before you're anything else

‍

Whatever the title on your deck says, in the first eighteen months you are a product manager. Nothing else. CEO, CTO, Chief Product, doesn't matter. Your single job is to reach a clear understanding of your customers' problems faster than anyone in your category and to design a creative solution worth building. Everything else is overhead until that's proven.

‍

Here's the part nobody warns you about. Operating at PM speed surfaces a problem most founders don't see coming until they're already underwater in it. The daily operational layer of the company has to run somewhere. The recurring research, the competitive monitoring, the inbox triage, the status syntheses, the customer-call follow-ups, the small repeatable workflows that quietly compound into half your week. Without a team, that layer runs on you. And the moment it runs on you, it becomes the reason you slow down.

‍

I've watched founders lose three months to this without naming it. They think they have a focus problem when they have a routing problem.

‍

Claude as the operating layer, not the assistant

‍

The interesting shift right now isn't about prompting better. It's about treating Claude (or whichever frontier model you've standardized on) as the operating layer of the company rather than the assistant in the corner. The work stops being "what can I ask it to do" and starts being a routing problem: where does each piece of work actually live?

‍

Most of the confusion I hear from founders around "which Claude product do I use" dissolves once you stop comparing features and start asking three questions in order. The first question that gets a yes routes you to the right tool.

‍

Question 1: Does it touch your disk? → Cowork

‍

Start with the filesystem. If the work reads from your local drive, edits a spreadsheet sitting on your desktop, or saves output somewhere Spotlight can find it, you're looking at Cowork Scheduled Tasks. Routines and Managed Agents both run in the cloud and can't see your hard drive. That constraint isn't a limitation to route around. It's the whole reason Cowork exists as a separate product.

‍

The use case I see most often: founders who already have years of accumulated context living in local files (deal memos, founder notes, customer transcripts, financial models) and want an agent that can actually read and write to that corpus without uploading everything into a cloud workspace. Cowork is the only answer.

‍

Question 2: Does it need to fire while you're offline? → Claude Routines

‍

If the filesystem doesn't matter but the work needs to fire while you're not at the keyboard, on a flight, asleep, triggered by a webhook or a GitHub event, that's Claude Routines. They run on Anthropic's infrastructure, so the state of your laptop is irrelevant.

‍

The tradeoff is the one you'd expect. No local file access, and each run pulls from the same usage allowance as your interactive sessions. Worth calibrating the schedule to actual need rather than maximum frequency. I see founders set a Routine to run every fifteen minutes when twice a day would do the job, and then wonder why they hit limits.

‍

Question 3: Does it serve a team? → Managed Agents

‍

If it needs to serve a team rather than one person, every PM querying the same support-ticket agent with scoped sessions, audit trails, role-based permissions, that's Managed Agents.

‍

The catch is real and worth saying out loud. An engineer wires the initial infrastructure. This is not a no-code path. Your job as the founder using it is the brief, the success criteria, and the review loop. If you don't have an engineer to spare for setup, this isn't the right product yet.

‍

The trust layer underneath all three

‍

The piece that makes any of this trustworthy is quieter than the product announcements, and I think it's the most underrated capability shift of the past year.

‍

Opus 4.7 now verifies its own outputs before reporting back. For Routines and Managed Agents, which run for hours without anyone watching, that's the difference between an automation you trust and one you end up babysitting. Without verification you don't actually have leverage. You have a second job watching the agent, and you've just rebuilt the bottleneck you were trying to escape.

‍

This is the thing I'd push founders to internalize. The product names will change. Verification as a default behavior will not, and it's what makes the routing logic above actually work in production.

‍

What this means for the budget

‍

So back to the P&L. Stop spending on a headcount plan you copied from a 2016 playbook.

‍

Expand the budget around tooling, repeatable automation, model tokens, and the operational discipline to run multiple models in parallel for different jobs (because you should, and the founders who refuse to are paying a focus tax for false simplicity). Treat the token line the way you treated the AWS line a decade ago: variable, scaling with usage, instrumented so you actually know what's burning.

‍

The new founder archetype isn't the one who raised the largest seed. It's the one operating five agents before their first hire. Capital efficiency stops being a constraint imposed by a difficult market and starts being a design choice you made on day one.

‍

I see this most clearly in Israeli founders. The instinct to do more with less, born from small teams shipping under constraint, is suddenly the dominant operating model globally. The companies I'm watching most carefully right now are the ones who recognize that and lean into it, rather than importing an American playbook that was already starting to crack before this latest shift.

‍

Pick the question. Route the work. Build the leverage before you build the team. Then, and only then, hire.

‍