Project Management for Startups Under 10 People

The correct amount of process at eight people is genuinely small, and confidence about that is more useful than any framework.

Quick answer: A startup this size needs shared visibility and an ordered list of priorities. It does not need estimation, sprint ceremonies, dependency management, permission schemes or formal reporting. The failure mode is not too little process — it is adopting process designed for organisations twenty times the size, then abandoning it because maintaining it competes with building the product.

What a Startup This Size Actually Needs

Three things: everyone can see what everyone is working on, priorities are ordered rather than labelled, and decisions are written down somewhere durable.

Visibility, not process

The problem a small startup actually has is that two people work on overlapping things, something gets forgotten, or nobody is sure what the current priority is.

All three are visibility problems. A shared, current list of active work solves them. Ceremonies, estimation and reporting solve problems you do not have yet.

The threshold where informal stops working

Under four people, everyone hears every conversation and coordination is nearly free. A shared document is genuinely sufficient.

Between four and eight, that breaks. Conversations happen in subsets, two people agree something the others do not hear, and someone starts asking "what's the status of..." several times a day. That question is the signal, and it usually arrives before anyone thinks they need a tool.

What you can safely ignore

Story points and velocity. Formal sprint planning and review ceremonies. Dependency management and critical paths. Custom permission schemes. Detailed status reporting.

Resource levelling.

Each solves a coordination problem that appears at scale. At eight people, adopting them costs maintenance and returns nothing, and the maintenance loses to product work every time.

The Minimum Viable System

Signals it is time

One list, ordered

Everything active, ranked, no ties Minutes daily

Owner per item One name, always None Rough due dates Where a date genuinely matters Minutes Weekly planning 30 minutes, what matters this week 30 min weekly Weekly look-back 15 minutes, what got in the way 15 min weekly

Decisions written where the work is

Reasoning recorded where relevant Minutes Nothing else — —

Running Work Without Ceremony

Keep one ordered list, hold a short weekly rhythm, and write decisions where the work lives rather than in chat.

One list, ordered Everything the team might do, in one place, ranked top to bottom with no ties.

Ordering is the mechanism. Priority labels let everyone avoid the decision — twelve items marked high priority contain no information. A ranked list forces the trade-off, which at a startup is the entire point, because the constraint is always what to not do.

A short weekly rhythm

Thirty minutes on a Monday: what matters this week, who is doing what, what is blocked. Fifteen minutes on a Friday: what got in the way.

That is the whole ceremony budget. It gives you the planning and reflection that sprint frameworks provide, at a fraction of the cost, and it scales up naturally later if you need more.

Decisions written where the work is Startups make decisions constantly and forget them constantly, then relitigate the same question a month later.

Record the decision and its reasoning on the relevant item. This costs seconds and saves the recurring conversation — and it becomes genuinely valuable when a new joiner asks why something works the way it does. Tools that let you attach a document to a task keep the reasoning next to the work rather than in a separate wiki nobody opens.

Handling the Startup-Specific Problems

Three problems are characteristic at this stage: everything appears equally urgent, founders work inside the system with context nobody else has, and priorities change mid-week.

Everything is a priority

At a startup, most things genuinely are important. The list is not the problem; the absence of an order is.

Force a ranking. When someone argues two items are equally important, ask which one you would do if you could only do one this week. That question always has an answer even when "which is more important" does not.

Founders working in the system

A founder who does delivery work carries context that never reaches the tool, because they do not need it themselves.

This produces a system that looks incomplete to everyone else. The rule has to apply to founders too — if it is not written down, it did not happen — and founders are the hardest people to hold to it.

Priorities changing mid-week

Startups genuinely do learn things that change the plan. That is not a failure of discipline.

What matters is that the change is visible rather than implicit. Move the item, tell the person whose work is affected, and note why. Changing priorities silently is what makes teams feel like the plan means nothing.

Adding Structure as You Grow

Add process in response to observed failures rather than on a schedule, and expect the first real additions around ten and twenty people.

What to add at ten people

Around ten, add a clearer separation between planned and unplanned work, and a slightly more formal look-back. You will also start needing a simple way to see who is overloaded.

This is also the point at which the founder can no longer hold everything, which is usually the trigger.

What to add at twenty

Around twenty, teams begin to specialise and coordination between them becomes the problem rather than coordination within one.

That is when dependency visibility, a shared roadmap view and some form of capacity planning start earning their cost. Not before.

Signals it is time Specific and observable: people maintain private lists outside the shared system, nobody trusts the status shown, the same question is asked repeatedly in chat, or work is duplicated.

Any of these means the current process has stopped covering the coordination load. Adding process without one of these signals is adopting a solution to a problem you do not have.

Common Startup Mistakes

The three errors are adopting enterprise process early, having no process until something breaks, and running a tool only the founder opens.

Enterprise process at eight people

A founder who used Jira at a 500-person company installs it at eight, then discovers the configuration burden has no corresponding benefit at that scale.

The tool is not wrong; the timing is. Adopt heavy process when you have the problem heavy process solves.

No process at all until something breaks

The opposite failure. A missed customer commitment, duplicated work, or an embarrassed apology finally prompts adopting something.

The signals appear well before that. Acting on them costs an afternoon; ignoring them can cost a customer.

A tool only the founder opens

If one person updates on everyone's behalf, the tool is a status document with a subscription fee.

The cause is almost always friction rather than willingness. If updating takes more than a few seconds, people batch it and then stop. Reduce the friction before addressing the behaviour.