Ch6 02: Build the Team You Need Today. Not the Team You Daydream About.#

You’ve been searching for the perfect co-founder for three months. Technical chops, business sense, industry connections, willingness to work for equity. You’ve met dozens. None check all the boxes.

Meanwhile, your competitor launched with three “good enough” people. Their product is live. They’re learning from real users. They’re iterating weekly.

You’re still recruiting.

This is the “perfect team” trap—and it kills more startups than bad products do. Not because founders are lazy, but because they’re too ambitious about team composition at the wrong stage. They’re assembling an orchestra when what they need is a garage band that plays loud and learns fast.

The Real Cost of Waiting for Perfect#

Every week spent searching for the ideal hire is a week not building, not learning, not shipping. In the early stage, weeks are everything.

Do the math nobody does: you spend three months hunting for a CTO. During that time, you could have built a crude prototype with no-code tools, tested it with real users, gathered feedback, and iterated twice. By the time your dream CTO arrives, you’d already know what to build. Instead, you’re starting from zero—with a higher burn rate.

The “perfect team” illusion shows up three ways:

Waiting. You know exactly who you need, and you refuse to start until you find them. The project sits idle. Momentum dies.

Hoarding. You hire for roles you’ll need in six months, not now. Head of Marketing with no product to market. VP of Operations with no operations. Data scientist with no data. Expensive, underutilized, frustrated.

Over-specifying. Job descriptions read like wish lists. Ten years in your exact niche. Led teams of twenty-plus. Both startup and big company experience. Below-market salary. You’ve described a unicorn. Unicorns don’t answer your job posting.

All three optimize for the wrong time horizon: building for where you want to be, not where you are.

The “Good Enough” Principle#

What actually works in the early stage: hire for the three most critical tasks of the next ninety days. Nothing else.

Not the next year. Not the next fundraising round. The next ninety days.

List everything that must happen in the next three months for your startup to survive. Not thrive—survive. Identify the three tasks that matter most—the ones where, if they don’t get done, nothing else matters.

Now ask: who can do those three things? Not brilliantly. Adequately, starting next week.

That’s your team.

A product manager wanted to launch an app. Couldn’t code. Conventional wisdom: find a technical co-founder. She searched for four months. Nothing clicked. Then she reframed: “What are the three most important things in the next ninety days?” Answer: build a working prototype, get it to twenty users, gather enough feedback to validate the concept.

She didn’t need a CTO for that. She learned Bubble in two weeks. Built an ugly but functional prototype. Got it to twenty users through her personal network. Collected feedback that reshaped her entire product direction.

Three months later, when she recruited a technical co-founder, she had something to show: a validated concept, real user feedback, a clear technical direction. He joined immediately—not because she was persuasive, but because she’d done the work proving the idea was worth his time.

She saved three months, spent zero on technical salaries, and ended up with a better co-founder because she had something real to offer.

Execution Over Ability: The 70/100 Rule#

In the early stage, a person who scores 70 on ability but 100 on execution will outperform a person who scores 95 on ability but 50 on execution. Every single time.

Why? Because at the early stage, the bottleneck is almost never quality. It’s speed. You’re not building the best version of something—you’re building any version and learning whether it matters.

The 95-ability person wants to do it right. Researches best practices. Designs elegant architectures. Writes comprehensive specs. Produces beautiful work—slowly.

The 70-ability person wants to get it done. Cuts corners where corners can be cut. Ships rough drafts. Fixes things after they break. Output is messy—but it exists. And existing beats perfect every time in survival mode.

A friend who runs an agency once told me: “I’d rather have someone who ships a B-minus deliverable on Tuesday than someone who promises an A-plus on Friday. Because Tuesday’s B-minus gets client feedback by Wednesday, and by Friday we’ve iterated to an A. Meanwhile, the perfectionist is still polishing.”

That’s the execution principle in one sentence.

How to Set Your “Good Enough” Line#

This isn’t about lowering standards. It’s about matching standards to your stage.

Step 1: Define the current stage. Pre-product? Pre-revenue? Pre-PMF? Post-PMF scaling? Each has different needs. Be honest about where you are, not where you want to be.

Step 2: List the three critical tasks. What must happen in the next ninety days? Be ruthless. More than five? You haven’t prioritized. Force yourself to three.

Step 3: Define “good enough” for each. Not excellent. Not world-class. The minimum output quality that lets you move to the next step. For a prototype: it works, it doesn’t crash, users can understand what it does. That’s it. No pixel-perfect design. No elegant code.

Step 4: Match people to tasks, not roles to org charts. You don’t need a “Head of Growth.” You need someone who can get fifty people to try your product in the next month. Maybe that’s a full-time hire. Maybe that’s you spending evenings in online communities. Maybe that’s a freelancer on a two-week contract. Match the person to the task and timeframe, not to a permanent title.

When to Upgrade: Four Signals#

“Good enough” is a stage strategy, not a permanent philosophy. At some point, you need to upgrade. Here’s when:

Signal 1: The bottleneck shifts from speed to quality. Early on, the problem is “ship faster.” Later: “what we’re shipping isn’t good enough to retain users.” When quality becomes the bottleneck, hire for quality.

Signal 2: The same problems keep recurring. If your “good enough” developer keeps shipping bugs that take longer to fix than prevent, the cost of “good enough” has exceeded its benefit. Time to level up.

Signal 3: You’re turning away opportunities. Customers or partners interested, but your team can’t deliver at the required level. Real revenue lost to capability gaps. Time to invest in better talent.

Signal 4: You can afford it. A senior hire should be funded by the growth they’ll enable, not by burning runway faster. If you can’t articulate how this hire pays for themselves within six months, it’s too early.

Four Pitfalls#

Pitfall 1: “Good enough” as an excuse for mediocrity. There’s a line between pragmatic and careless. A pragmatic hire is genuinely capable but not overqualified. A careless hire is someone you settled for because you were tired of looking. The first ships functional work. The second ships problems.

Pitfall 2: Never upgrading. Some founders fall in love with their scrappy early team and can’t make changes. Loyalty is admirable, but if your day-one developer can’t handle day-three-hundred demands, keeping them in the same role hurts everyone. Upgrade the role, not the relationship.

Pitfall 3: Hiring ahead of need. “We’ll need a CFO for Series A.” Maybe. But that’s twelve months away and not guaranteed. Your accountant and a good spreadsheet are fine until then.

Pitfall 4: Confusing team size with team strength. Ten people doesn’t mean ten times the productivity. In the early stage, it often means twice the productivity at five times the cost. Communication overhead, alignment meetings, and coordination costs eat gains. Keep the team as small as possible for as long as possible.

Reflect and Self-Diagnose#

Pull up your team list. Next to each person, write their primary task—the one thing they must deliver for the company to move forward.

Look for two things:

First: Is anyone’s primary task something needed “eventually” rather than “right now”? If so, that role was hired too early. You’re paying today for value you’ll receive tomorrow—if tomorrow comes.

Second: Is anyone’s role defined by a title rather than a task? “Head of Marketing” is a title. “Get fifty beta users by June 15” is a task. Titles are comfortable. Tasks are useful. In the early stage, every person should be defined by their task, not their title.

One last exercise: Imagine cutting your team to three people, including yourself. Who stays? Why? The answer tells you who’s essential now and who’s a bet on the future.

Build for now. Optimize for later. The founders who ship with a “good enough” team this month will always outrun the founders still assembling their dream team next quarter.

Sufficient beats excessive. Every time. Get moving.