Project Management for Startups: Just Enough Process

Project management for startups should be the least process that keeps everyone working on the right thing. For a team of two to ten people that is four habits: one board that holds all the work, priorities reset once a week, decisions written down with who made them and why, and bugs kept in the same place as new work. Skip sprints, Gantt charts and heavyweight tools until a specific problem demands them. Add process one piece at a time, each piece in answer to something that went wrong twice. If you are building with AI coding agents, connect them to the same board from the first day.

What a 2-10 person startup actually needs

The Manifesto for Agile Software Development↗ (opens in a new tab) values “Individuals and interactions over processes and tools,” and at startup size that is literally true: five people in one channel can settle most questions in a message. What they cannot do is remember everything. Project management at this stage is mostly memory: a shared record of what is being built, what matters most this week, what was decided, and what is broken.

• One board: every task in one place that everyone can see.
• Weekly priorities: a short list of what matters this week, reset every week.
• Decisions written down: what was decided, by whom, when and why.
• Bugs in the same place: broken things compete for the same time as new things, so they belong on the same board.

One board

Put all the work on one board: product, marketing, hiring, the investor update. Separate tools for each function feel organized and make it impossible to see the trade-offs, which are the whole job at this size. When the founder spends Thursday on a customer call instead of the release, the board should show what slipped.

Keep the lanes simple: to do, next up, in progress, completed. Label tasks by kind if you build software (new feature, improvement, bug) and give each a priority number. That is enough structure for a year. A simple project management tool for small teams makes the case for fewer features in more detail.

Weekly priorities

Once a week, usually Monday, spend thirty minutes together choosing what matters most this week. Move those tasks into the next-up lane and leave everything else where it is. A startup’s priorities change faster than any quarterly plan, so the weekly reset is the plan. If you do set quarterly goals, OKR examples for small teams shows how to link each one to the tasks behind it, so the Monday choice has something to aim at.

Keep the list short. If everyone has five top priorities, nobody has any. Two or three per person is a useful ceiling, and the founder’s job on Monday is often to say which good idea waits.

Decisions written down

Startups make dozens of decisions a week, most of them in chat or on calls, and forget the reasons within a month. Then someone new asks why the product does not support single sign-on, and the argument starts again from the beginning. Write each real decision down in three lines: what was decided, who decided, and why, including the option you turned down. Decision-making frameworks for small teams covers how to make the decision; the habit here is only to record it.

Some decisions are standing rules: “we never ship on Fridays,” “customer data never leaves the production database.” Keep those somewhere every new hire, and every AI assistant, reads before they start.

Bugs in the same place

A separate bug tracker creates a second backlog nobody prioritizes against the first. Keep bugs on the main board with a clear label, so the Monday choice is honest: fixing the checkout bug or building the new report, not one from each list. A bug report template keeps the reports useful when customers or teammates file them.

What to skip until later

Most process is built for coordinating people who do not talk every day. Until you have that problem, skip it:

• Sprints. The Scrum Guide↗ (opens in a new tab) describes Sprints as “fixed length events of one month or less to create consistency.” Consistency is valuable once customers and teams depend on your release rhythm. Before that, a fixed commitment window mostly gets in the way of reacting to what you learned yesterday.
• Gantt charts and detailed timelines. They are worth their upkeep when work has long, known dependencies, such as hardware, regulated launches or a fixed event. For software that changes weekly, the chart is out of date before it is shared.
• Story points and velocity. A rough size on each task (an afternoon, a day or two, about a week) answers the same question without a calibration meeting.
• Heavy tooling. Custom fields, multi-step workflows and approval chains all need someone to maintain them. Nobody at a five-person startup has that job.
• Long planning documents. The Small Business Administration’s guide to writing a business plan↗ (opens in a new tab) notes that lean startup plans “can take as little as one hour to make and are typically only one page.” The same spirit applies to project plans: one page, revised often.

When to add process

Add a piece of process when the same problem happens twice, and add only the piece that fixes it. Some common signals and the smallest fix for each:

• Two people built the same thing: a daily written check-in, or a rule that work starts only from the board.
• Customers keep hitting bugs you already fixed: a short release checklist and a note on each task saying how it was tested.
• A new hire asks the same ten questions: a one-page working agreement and the decisions list.
• Releases surprise sales or support: a fixed release day, announced in advance. This is where sprints can start to earn their place.
• Nobody knows who is doing what: an owner on every task. How to assign tasks to team members covers the habit.

The Scrum Guide puts a typical Scrum Team at “10 or fewer people.” Past roughly that size, or when you split into several teams, more formal planning usually stops being optional.

Working with AI coding agents from day one

Many startups now have an AI coding agent doing a real share of the engineering from the first commit. Treat it like a team member who starts every session with no memory. It needs the same four things the people need: the board, the week’s priorities, the decisions and the bug list.

• Write the standing rules into the files your agent reads at startup. Anthropic’s Claude Code best practices↗ (opens in a new tab) describe CLAUDE.md as “a special file that Claude reads at the start of every conversation,” for commands, code style and workflow rules. AGENTS.md examples shows what to put in one.
• Connect the agent to the board, so it reads tasks and records what it did instead of leaving the record in a chat window. The Claude Code task tracking workflow walks through the rhythm.
• Give it small tasks with a check it can run, and have a person review the result before it counts as done.
• Keep the decisions human. An agent can write a decision down; a founder or a teammate makes it.

A startup board on fenbs

fenbs was designed around these habits. A team gets one board with four lanes, To Do, Next Up, In Progress and Completed, and every task is a feature, an enhancement or a bug with a priority from 1 to 10. Decisions and standing rules go on the Decisions and rules page, with who decided and when, and every connected AI assistant reads the rules first. Roles are set per company, with Client and Reporter suggested for investors and early users who should see or report but not change.

claude mcp add --transport http fenbs https://fenbs.ai/api/mcp

What fenbs leaves out matters as much at this stage: no sprints, due dates, WIP limits, epics or Gantt charts. If you need dated timelines for a hardware launch or a fixed event, use a tool built for that alongside it. History records who changed what, for people and assistants alike, so when you do add process later, you can see how the work has actually been going.