
The short answer: most startups should run Kanban (a continuous board with work-in-progress limits) or Scrum (fixed one- or two-week sprints), and layer Lean thinking on top to decide what to build at all. Waterfall, the Critical Path Method, and PRINCE2 only earn their overhead when the scope is fixed and the deadline is external - a hardware run, a compliance project, a funded pilot with a contract. Agile itself is not a methodology you run; it is the set of values Scrum and Kanban put into practice. The right choice depends on how predictable your work is and how many people are doing it, not on which framework is trending.
Here are all seven at a glance:
| Methodology | Best for a startup that... | Cadence | Overhead | Watch out for |
|---|---|---|---|---|
| Agile | Ships software and expects requirements to change | Iterative (via Scrum/Kanban) | Low | It is a mindset, not a process - pick a framework |
| Scrum | Has 4+ people building one product in increments | Fixed sprints, 1-4 weeks | Medium | Meeting tax on teams under 4 |
| Kanban | Handles a continuous stream of requests, bugs, and ops | Continuous flow | Low | Becomes a to-do list without WIP limits |
| Lean | Is pre-product-market fit and needs to validate cheaply | Build-measure-learn loops | Low | Says what to build, not how to schedule it |
| Waterfall | Has a fixed scope, fixed deadline, and external sign-offs | Sequential phases | Medium | Late discovery of problems |
| CPM | Runs a launch or hardware build with hard dependencies | Scheduled once, then tracked | High | Fragile when tasks change |
| PRINCE2 | Delivers regulated or enterprise-contracted work | Staged, governance-heavy | High | Drowns a small team in documents |
That table answers the exam question. The harder question is which one to actually run on Monday, so the rest of this guide gives you a four-question decision guide, an honest look at each methodology, and a worked example of how a small SaaS team runs a hybrid on one t0ggles board.
Project management for startups is a lightweight system for turning limited time, money, and people into clear priorities and reliable delivery. It differs from project management at a large company in three ways, and each one changes which methodology fits:
The practical consequence: startup project management should be the smallest amount of process that keeps the team aligned and the work visible. Add structure when the pain of not having it shows up, not before.
Four questions settle it for most teams. Answer them in order and stop at the first clear match.
1. Is the scope fixed and signed off by someone outside the team? If yes - a hardware production run, a grant deliverable, a regulated integration - use Waterfall for the phases and CPM to schedule the dependencies. If the contract also demands formal governance, that is the one case where PRINCE2 fits a startup. Everyone else, keep going.
2. Does work arrive continuously, or can you plan it in batches? Support requests, bugs, ops tasks, and agency-style client work arrive continuously. That is Kanban. Product features you can plan a week or two ahead are batchable, so keep going.
3. How many people build the product? Under four, run Kanban with a weekly planning session - Scrum's ceremonies cost more than they return at that size. Four or more building one product in increments, run Scrum with one- or two-week sprints. Our Kanban vs Scrum comparison goes deeper on this exact fork.
4. Have you found product-market fit? If not, wrap whichever framework you picked in Lean: every sprint or week should end with something a customer can react to, and the backlog should be ordered by what you need to learn, not by what is easiest to build.
Most startups land on Kanban or Scrum plus Lean. If you are torn between the first two, the hybrid Scrumban - a persistent Kanban board with WIP limits, plus a weekly planning and retro rhythm borrowed from Scrum - is the safest default for a team of two to eight. The worked example near the end of this guide shows it running.

Agile is a set of values from the 2001 Agile Manifesto: working software over documentation, responding to change over following a plan, customer collaboration over contract negotiation, individuals and interactions over processes and tools. It is the philosophy nearly every startup already believes in. It is not, on its own, something you can run - you need a framework that turns the values into a weekly rhythm, and that framework is almost always Scrum, Kanban, or a mix of the two.
Why startups default to it: short feedback loops match how startups learn. Shipping a rough increment every week and adjusting beats spending a quarter building the wrong thing well.
Where it goes wrong: teams say "we're agile" and mean "we have no process". Without WIP limits, a regular planning cadence, or a definition of done, agile becomes a euphemism for reacting to whoever spoke last.
On t0ggles: the pieces that make Agile concrete are all on the board - a Kanban view for flow, milestones for increments, and AI task creation that turns a customer call into structured tasks in seconds. That last one matters more than it sounds: the faster an idea becomes a card, the less planning overhead the team carries.
For the full picture, read our guide to Agile project management.

Scrum organizes work into fixed-length sprints, usually one or two weeks for a startup (the four-week sprints in older textbooks are too long when the roadmap changes monthly). Each sprint has planning at the start, a short daily standup, a review to demo the increment, and a retrospective to fix the process. Three roles - Product Owner, Scrum Master, Developers - own the backlog, the process, and the build.
When it works for a startup: a team of four or more building one product where priorities can hold for two weeks. Sprints give investors and stakeholders a predictable demo cadence, and velocity gives you a defensible answer to "when will it ship?".
When it fails: teams under four, where the ceremonies eat a full day per sprint per person and nobody has time to be Scrum Master. Also any team where priorities genuinely cannot hold for a week - forcing a sprint commitment onto that work just produces constant sprint breaks.
Startup adaptations that work: one-week sprints, a founder as part-time Product Owner, a 10-minute standup instead of a 15-minute one, and a combined review-plus-retro on Friday afternoon. Our free standup generator and retro generator remove the prep from both.
On t0ggles: each product area (Core, Infrastructure, Design System, Tech Debt) is a project on one board, and each sprint is a milestone. The milestone progress bar and burndown report replace the sprint spreadsheet, and task comments keep standup context attached to the work instead of lost in chat.


Kanban visualizes work on a board with columns (To Do, In Progress, Review, Done), limits how many cards can sit in each column at once, and measures how long a card takes to cross the board. There are no sprints, no required roles, and no mandatory meetings - when you finish something, you pull the next most important card.
When it works for a startup: almost always, which is why it is the default recommendation for teams under four. It absorbs continuous work (bugs, support, ops, client requests) without breaking a plan, and it takes an afternoon to adopt.
When it fails: when the team skips WIP limits. A board with twelve cards In Progress for three people is a to-do list with extra steps, and everything takes forever because everything is started. Our guide to mastering WIP limits covers how to set them; a limit of one or two per person per column is the right starting point.
On t0ggles: the Columns view is a Kanban board with drag-and-drop and per-column WIP limits, and several projects share one board so a founder can see product, marketing, and support flow side by side instead of tab-switching between boards.


Lean started in Toyota's factories and reached startups through Eric Ries' Lean Startup: build the smallest thing that tests an assumption, measure how customers respond, learn, repeat. Its five pillars - identify value, map the value stream, create flow, establish pull, pursue perfection - are about eliminating waste, and in a startup the biggest waste is building features nobody wanted.
When it works for a startup: before product-market fit, always. Lean is not a scheduling framework; it is the rule for ordering the backlog. Pair it with Kanban or Scrum for delivery.
When it fails: when "MVP" becomes an excuse to ship something too broken to learn from, or when a team measures vanity metrics (signups) instead of behavior (retention, usage of the new feature).
On t0ggles: a public board or an intake form gives customers a direct line into the backlog - feature requests arrive as tasks with reactions showing demand, so the "measure" step is not a separate spreadsheet. The Calendar view makes it obvious when a learning loop has gone longer than a week.

Waterfall runs a project through sequential phases - requirements, design, build, test, deliver - with each phase signed off before the next begins. It is the methodology most startup content dismisses reflexively, which is a mistake: some startup work really is fixed-scope.
When it works for a startup: a hardware production run, a certification (SOC 2, CE marking, a clinical process), a contracted pilot with a defined deliverable, a marketing launch with a date that cannot move. In all of these, the cost of changing course mid-way is high and the requirements are known up front.
When it fails: any software product where you will learn something during the build that should change the plan. Waterfall discovers problems in the test phase, which is the most expensive place to find them.
On t0ggles: the Gantt view lays out the phases with dependencies and dates, so a founder managing contractors can see whether the design phase slipping moves the delivery date.

The Critical Path Method finds the longest chain of dependent tasks in a project. That chain is the critical path, its length is the shortest possible project duration, and any delay on it delays the whole project. Tasks off the path have slack and can slip without consequence.
When it works for a startup: launches and physical builds. A hardware startup waiting on a PCB revision, a certification, and an enclosure supplier has a real critical path, and knowing which supplier can be late and which cannot is worth the planning time. Event-style launches (conference demo, app store release with a press date) benefit for the same reason.
When it fails: when tasks change often. A critical path drawn on Monday is fiction by Thursday if the scope moves, so CPM belongs with fixed-scope work, not with a product backlog.
On t0ggles: task dependencies with lag days and cycle detection, drawn on the Gantt chart. Move one task and every dependent date moves with it, which is the part spreadsheets get wrong.


PRINCE2 (Projects IN Controlled Environments) is a staged, document-driven methodology built around a business case, defined roles, and formal approval at each stage boundary. It is the standard in UK public sector and much of enterprise procurement, and the current edition is PRINCE2 7.
When it works for a startup: when a customer or regulator requires it. Fintech and healthtech startups selling into institutions sometimes have to show PRINCE2-style governance to close a contract, and running the delivery that way is cheaper than translating after the fact.
When it fails: everywhere else. PRINCE2 assumes a project board, a project manager, and time to write stage plans. Adopting it voluntarily at ten people is how a startup ends up with more documents than customers.
On t0ggles: public boards give a project board or client read-only visibility into progress without extra seats, and the change history records who changed what and when - the audit trail PRINCE2 wants, without a separate reporting process.

The methodology matters more than the software, but the wrong tool can quietly force the wrong methodology. Jira is built Scrum-first and pushes you into sprints and story points before you have decided you want them. Trello is Kanban-only and has no Gantt, dependencies, or milestones when you need them for a launch. Notion is a wiki that can imitate a board, but it does not enforce flow. Four things to look for in a startup tool:
t0ggles was built around the first two. Every board has Columns, List, Calendar, and Gantt views over the same tasks, several projects live on one board, and the free plan includes 1 board, 3 team members, 5 projects, 100 tasks, and 25 AI actions a month - with dependencies, milestones, and all four views switched on. When a team outgrows it, the paid plan is $5/user/month (billed annually) with everything unlimited. For an honest comparison of what the other free plans offer, see our roundup of free project management software, or the head-to-head pages for Trello, Jira, Linear, and ClickUp.
Here is how a four-person SaaS startup runs the hybrid most small teams end up with. The Viva Metric template is a ready-made version of this board you can copy.
This is not pure Scrum or pure Kanban, and that is the point. It is the least process that keeps four people aligned, and it is the same board the team keeps when it becomes eight.
Methodology guidance tailored to specific teams:
Get updates, design tips, and sneak peeks at upcoming features delivered straight to your inbox.