How to manage a project when you don't know what you're building

Table of Contents

• The blurry photo: why waterfall and agile aren't enough
• The signal that you already have resolution: you can draw the org chart
• Departments first, people later

  • Don't copy the org chart of a big company
• The minimum viable team
• Safe bet or R&D: the label that decides where your money goes

  • Rule 1: you can't do R&D on everything
  • Rule 2: spend differently on each
  • Rule 3: the maximum number of attempts per day
• The vertical slice and the three versions

  • The five paths to cover each function
• Do the math before buying the tool
• Don't scale a drawing you'll have to erase
• Publish before you're ready
• Launching isn't succeeding
• The real asset: the playbook
• Summary of the method
• Exercise for this week
• Watch the video

The blurry photo: why waterfall and agile aren't enough

Imagine a photograph of your project and the market it's aimed at. At the beginning it's blurry: you see patches of color, you guess at shapes, but you can't make out the details. You want to open a sourdough bakery and you know some people pay more for good bread, but you don't know how many there are, what time they buy, or whether your real problem will be the oven or the delivery.

That blurry photo is your starting point and there's no way to skip it. The only thing you can do is raise its resolution, and resolution goes up in only one way: by acting. Every customer you serve, every supplier you negotiate with, every version you ship gives you back pixels you didn't have before.

Here's where the two classic models break down:

• Waterfall assumes the map is already known. That's why PMBOK only works for a startup up to a point.
• Agile is more honest because it accepts that you have to iterate, but it assumes the backlog is already defined: that you know what's due in the next two weeks.

In an environment where technology, channels, and even customer behavior change every quarter, neither assumption holds. You need something else: not a complete plan, but a low-resolution plan that gains detail at the same time as your team does.

The signal that you already have resolution: you can draw the org chart

This is the part almost nobody says, and the most useful in the whole framework.

You know you've gained resolution when you can draw exactly the org chart you need. Not a list of tasks. Not a roadmap. An org chart: which functions exist, how many people go in each one, which are internal, which are hired per project, and which are solved with technology instead of people.

Until you can draw that, you're still blurry. And if you're still blurry, you shouldn't be hiring en masse or raising a big round.

Notice the change in the question. It stops being "when will the product be ready?" and becomes "when will I know what shape my organization needs to have to do this right?".

Departments first, people later

When you break down a project, the temptation is to think in people: I need a designer, someone in sales, a community manager. It's an ordering mistake.

First you break it down into departments, and here's the definition that changes everything:

A department is a problem. A role is a learned solution.

If you open a content agency, "video production" isn't a job opening: it's a problem you have to solve. "Getting clients" is a problem. "Getting paid on time" is a problem. Roles come later, once you've understood the problem well enough to know what kind of person solves it.

Confusing this leads to hiring someone with a fancy title for a problem you don't understand yet, and discovering four months in that the problem was a different one.

Don't copy the org chart of a big company

Talk to people in your industry, always. But don't copy the structure of a big company. As a company grows, it brings in people whose only job is preventing disasters: approving, reviewing, coordinating, filtering. It's legitimate in a thousand-person company and it's poison in a project of eight.

If you copy that structure from day one, a good part of your team will be supervising instead of producing. You won't gain resolution: you'll gain meetings.

The minimum viable team

Everyone talks about the minimum viable product. Almost nobody talks about the minimum viable team.

The rule is: in the first version you look for breadth, not depth. One person per department. Not two, not a team, not a lead with their people. One for each identified problem, even at seventy percent of what you'd need.

It sounds precarious, and it is. But the goal of that first lineup isn't to deliver the finished project: it's to discover where the gaps are. Going through the full cycle with a thin team makes the seams visible:

• where everything gets stuck,
• which function was doing the work of two,
• which problem turned out to be trivial,
• and which one was the real bottleneck.

With that you can add depth where it helps, not where you imagined it would.

Safe bet or R&D: the label that decides where your money goes

Of the whole framework, this is the tool you can apply this very week. Take the list of departments and put one of two labels on each.

Safe bet. You know the method. It doesn't mean you're the best in the world at it; it means you know exactly how it's done and could explain it to someone. Here scaling is a money problem: you hire more people or buy more tools and more results come out. Predictable.

R&D. You don't know the method. It's not that you're short on time: it's that nobody on your team knows yet how this gets solved. Here you don't scale with money, you scale with experiments. And it requires your direct attention as founder; you can't delegate it.

	Safe bet	R&D
Do you know the method?	Yes, you could teach it	No, nobody on the team knows it yet
How it scales	With money: more people or more tools	With experiments
Spend per unit	Higher: the return is predictable	Low and light: it's a bet
Team and tools	Buy and invest	Rent and test
Who runs it	It can be delegated	Requires the founder

Rule 1: you can't do R&D on everything

Pick one or two departments where you'll genuinely innovate and make all the others safe bets. If your entire project is labeled R&D, you don't have a six-month project: you have a four-year one, and you'll probably run out of money first.

And choose well where to innovate. If you're already great at the creative part, that one doesn't need R&D: lean on it and put the energy into what you don't master.

Rule 2: spend differently on each

Per unit, spend more on what you already know how to do and less on what you don't. A dollar in a safe bet returns one unit of results; a dollar in R&D is a bet that may not pay off. Keep R&D roles cheap and light.

It's the same logic as the client who pays you well for the service they know they need, and offers you a poorly paid pilot for the experiment they're not sure about. The same applies to your own portfolio of bets, something the 90/10 barbell strategy takes to the extreme.

Rule 3: the maximum number of attempts per day

In R&D, speed isn't measured in hours worked but in attempts. What you were going to solve in three months, solve in five days by running twenty tests.

It's worth investing time upfront in anything that shortens the cycle: seeing the result live instead of waiting for the render, or having the decision-maker watching while it's made instead of giving feedback two weeks later.

The vertical slice and the three versions

When you don't know what you're building, the worst strategy is to build it all halfway. The best is the vertical slice: take a small piece of the project and do it whole, from start to finish, with all its depth.

Don't do the first ten chapters of your online course half-finished. Do one complete chapter: the video, the exercises, the support, the payment, the follow-up. That slice is your unit of learning.

Then you repeat it, roughly three times:

1. First pass. You do it with the minimum viable team and it will come out mediocre. Publish it anyway, gather feedback, and discover what the real hard problem was.
2. Second pass. It no longer fails for the same reason: it fails for another one, and that other one is new information.
3. Third pass. You're no longer discovering the product: you're fine-tuning the org chart.

That's the real purpose of the three passes. It's not reaching the perfect product, it's reaching the complete map of functions: knowing which ones you need, which are internal, which go on contract, and in which nobody in the market knows how to do it.

The five paths to cover each function

For each function you end up choosing among five paths, and the choice is only obvious once you have resolution:

1. Do it in-house with whoever is already on the team.
2. Hire someone full-time.
3. Replace it with technology.
4. Outsource it temporarily.
5. Train someone internally with an outside mentor.

The last one is the slowest, and sometimes the only one available when the profile you need simply doesn't exist in your market.

Do the math before buying the tool

There's a right moment to invest in technology, and it isn't "when you can afford it". It's when the math asks for it.

The procedure is simple:

1. Measure how long it takes a person to produce one unit of whatever it is.
2. Multiply by the units you need to finish.
3. Divide by the deadline. You get how many people it would take if you keep doing it by hand.
4. Compare that annual cost with the tool that automates it.

For example: if a person takes 2 hours to edit a video, you need 600 videos and you have 3 months (about 480 working hours per person), you'd need 2.5 people dedicated to just that. When the number of people is absurd, you already have your answer, plus the argument in numbers to defend it to a partner or an investor.

Two rules go with this math:

• Rent while you're in R&D and buy once it's a safe bet. Don't tie up capital in equipment you might not use again, but invest as soon as a department changes labels: at that point you're no longer betting, you're scaling.
• Add a 30% buffer to any estimate, and ask yourself which complementary role would accelerate the main one. Sometimes the cheapest way to double output isn't hiring another expensive specialist, but adding someone who sets the stage for them.

Don't scale a drawing you'll have to erase

We've reached the most expensive mistake of all, and it's a mistake of sequence, not strategy.

When you finish your three passes and have a clear org chart, that's the moment to scale: put in money, hire, buy tools. Before that, no.

The reason is that redrawing the org chart requires going back to low resolution, and you can't redraw a big team. With five people, pivoting is an afternoon conversation. With forty, it's firing people you made promises to and fighting work habits the team already internalized. The organization resists, and rightfully so.

That's why order matters so much: first you find the shape, then you pour in the fuel. If you raise a big round before knowing the shape, you're not buying speed: you're buying the obligation to get it right on the first try.

And a scheduling detail almost nobody puts in the plan: between identifying the person you need, convincing them, and their notice period, three to four months go by. Your hiring plan has to run a quarter ahead.

Publish before you're ready

This whole method depends on one thing: getting real feedback. And real feedback doesn't arrive if you don't show your work. It's the same idea behind Steve Blank's customer development and validating an idea in one week.

Publishing intermediate versions gives you three things at once:

• Shape, because every critique is one more pixel of resolution.
• Talent, because nobody leaves a stable job for an idea they haven't seen, but plenty of people join something that already exists, even half-built.
• Mentors, because nobody with real experience gives you their time if they can't verify you're serious.

Showing imperfect work isn't a reputational risk. It's the mechanism by which you get the pieces you're missing.

Launching isn't succeeding

A project isn't successful because it launched. Things nobody cares about launch every day. Before you feel satisfied, define which signals you'll watch:

• Whether people really like it: that a significant share of those who try it, say half, love it.
• Whether they'd pay: what percentage says they'd pay, knowing that number always comes inflated and that what you're looking for is the proportion, not the figure.
• Whether there's a market: how many people are really out there for what you do.

The real asset: the playbook

When you've been through the whole cycle, you take away something more valuable than the project: the playbook.

And it's not the document where you wrote down how things were done. Documents get read, but they don't get learned: nobody learned to edit video by reading a manual. The playbook is the org chart you discovered, the network of collaborators and mentors you built, and the judgment that now lives in your people's heads.

That's the asset. The project is just the excuse that produced it.

Summary of the method

1. Accept that you start with a blurry photo and that only action raises the resolution.
2. Break the project down into departments (problems), not people.
3. Put together a minimum viable team: one person per department.
4. Label each department safe bet or R&D, and leave at most two in R&D.
5. Build a complete vertical slice and repeat it about three times.
6. Invest in tools when the math asks for it, not before.
7. Scale only when you can draw the exact org chart.

Exercise for this week

If you're in the middle of a project right now, do this: write the list of departments —not people— and put the safe bet or R&D label on each one.

If you have more than two in R&D, there's your deadline problem.

Watch the video

If you'd rather see it explained, here's the full method on video (in Spanish):

Watch on YouTube