Project Management for People Who Just Want to Ship
You don't need a PMP certification to ship a product. You need four concepts, a simple system, and the discipline to call something done. Here's the whole thing.
“Project management” sounds like something that happens in conference rooms with Gantt charts and status reports. For most solo builders and small teams, it brings up images of process overhead that slows things down instead of speeding them up.
Here’s the reality: some version of project management is happening on every build, whether you’ve named it or not. The question isn’t whether to have a system — it’s whether your system is intentional or accidental. Accidental systems produce inconsistent results. Intentional ones let you move fast without losing track of what you’re doing.
You don’t need much. Four concepts, a simple weekly rhythm, and one rule about when something is done. That’s it.
The Four Concepts
1. The Backlog
A backlog is everything you’ve decided to build, in the order you’ve decided to build it. Not a wish list — a prioritized queue. The most important item is at the top. The least important is at the bottom. When you finish something, you pull the next item from the top.
Your backlog comes directly from your PRD. Every requirement, every feature, every piece of behavior you defined there becomes an item in the backlog. Your parking lot from scope creep prevention lives below the line — deferred items that are real but not yet prioritized.
A healthy backlog is: written down, ordered, and honest about what’s actually next.
2. The Story
A story is a single unit of work, written from the perspective of the person who needs it. The classic format is:
As a [type of user], I want to [do something], so that [reason / outcome].
This format is not just academic. It forces you to stay connected to the user’s actual need instead of describing implementation details. The moment you write a story, you’ve answered three questions: who is it for, what do they need, and why does it matter.
Example from SendJob:
As a dispatcher, I want to receive an alert when a new job is created and assigned to me, so that I can confirm coverage without checking the system manually.
One story. One person. One need. One outcome.
Stories should be small enough to build in a day or two. If a story takes a week, it’s not a story — it’s a feature. Break it down.
3. The Sprint
A sprint is a fixed period of time — typically one or two weeks — where you commit to completing a specific set of stories from the top of your backlog.
The sprint does three things:
It creates a forcing function. Without a sprint, work expands to fill whatever time is available. With a sprint, you’ve made a commitment to finish specific things by a specific date.
It creates a natural review point. At the end of every sprint, you look at what you built, test it, and decide what’s next. This prevents the heads-down marathon that leads to building the wrong thing for three weeks.
It makes progress visible. You finished X stories this sprint. That’s real. That’s momentum you can measure.
For solo builders, one-week sprints work better than two-week sprints. A week is short enough that you can hold the whole sprint in your head. Two weeks is long enough to lose the thread.
4. The Definition of Done
This one is underappreciated. A story is not done when you’ve written the code or built the workflow. It’s done when it meets the definition of done.
Write yours down. A simple version:
- Builds without errors
- Tested with real data (not just happy-path)
- Edge cases identified and either handled or documented
- No new bugs introduced that weren’t there before
A story that passes the definition of done is shippable. Not perfect — shippable. You can show it to someone and it does what you said it would do.
The definition of done is your protection against the trap of calling things done before they are. When you’re tired at the end of a sprint, it’s tempting to count things that are “mostly working” as complete. The definition of done makes that call honest.
A Simple Weekly Rhythm
Here’s the system I’d recommend for any solo builder or small team:
Monday morning — Sprint planning (30 minutes) Pull items from the top of your backlog. Commit to what you’ll finish this week. Write the stories if they aren’t written yet. Be conservative — it’s better to finish five stories than to plan ten and finish seven.
Daily — Work the stories Pick the top unfinished story. Build it. Apply the definition of done. Move it to done. Pull the next one.
Friday afternoon — Sprint review (20 minutes) Look at what you finished. Demo it to yourself or someone else — actually use the thing you built. Note what worked and what didn’t. Move unfinished items back to the top of the backlog for next sprint.
That’s the whole system. No Gantt chart. No status report. One backlog, one sprint, one review per week.
Tools (Keep It Simple)
The best project management tool is the one you’ll actually use. For a solo build or a small team just starting out:
A text file or Notion page works fine for a backlog. A simple list with items you can drag and reorder.
Linear is worth it if you want something lightweight but purpose-built. It’s fast, it has stories and sprints built in, and it doesn’t require a week to learn.
GitHub Issues is a good option if your build lives in GitHub anyway. Stories become issues, sprints become milestones.
Don’t spend time evaluating tools. Pick one and use it. The tool matters far less than the habit.
When to Adjust Mid-Sprint
Two things justify changing what you committed to mid-sprint:
A blocker you couldn’t have anticipated. An API that’s broken, a dependency that isn’t what you thought, something that makes the story impossible to complete as written. Adjust, document it, move on.
Evidence from real users that changes priority. If you shipped something and users are all hitting the same wall, that wall moves to the top of the backlog immediately.
Everything else — new ideas, better approaches, things you notice while building — goes to the parking lot. Not mid-sprint.
The Launch Question
At some point, the sprint review at the end of a sprint looks like this: the core loop works, the must-have stories are all done, the definition of done is met. That’s the moment to ship, not to plan another sprint.
The most common mistake at this stage: one more sprint. “Let me clean up a few more things first.” This is usually fear wearing the costume of diligence. The PRD told you what success looks like. If you’ve hit it, you’re done with version 1.
Ship it. Put it in front of real users. Run the next sprint based on what they tell you, not on what you imagined they’d want.
Real feedback from one real user is worth more than another sprint of solo build time. Every time.
The Full Picture
You now have the four-piece system that underpins every successful product build:
- PRD — what you’re building, for whom, and what done looks like (Part 1)
- MVP — the smallest version that actually solves the problem (Part 2)
- Scope discipline — the framework for what goes in now versus later (Part 3)
- A simple build system — backlog, stories, sprints, definition of done (this article)
None of this requires a project management background. It requires writing things down, committing to a rhythm, and being honest with yourself about what “done” means. That’s it.
The people who ship are not more talented than the people who don’t. They have a system.
This is Part 4 of 4 in the Build It Right series. Start from the beginning: Start With a PRD
Subscribe below — we publish new build guides every week.