Quick answer: Solo PM needs three artifacts, not a methodology: one prioritized backlog (everything goes in it, most of it dies in it), a current milestone defined as a playable slice ('demo a stranger can finish'), and a weekly fifteen-minute review where you re-aim. The system's whole job is forcing the decisions drift would otherwise make for you.
Solo PM needs three artifacts, not a methodology: one prioritized backlog (everything goes in it, most of it dies in it), a current milestone defined as a playable slice ('demo a stranger can finish'), and a weekly fifteen-minute review where you re-aim. The system's whole job is forcing the decisions drift would otherwise make for you. That's the short version — the sections below get into the how, the why, and the mistakes worth dodging.
One backlog, ruthlessly ordered
Every idea, bug, and task lives in one list — never in your head, scattered notes, or seventeen apps. The list's power is its ordering: the top ten items are the project's actual plan, and everything below the fold is honestly labeled 'probably never'. Adding ideas costs nothing; promoting them must displace something.
Tooling barely matters — a text file, Trello, or a bug tracker all work. The discipline that matters: capture immediately (open loops eat focus), and re-rank weekly rather than living off stale priorities.
Milestones are playable, or they're lies
'Finish combat system' is unfalsifiable; 'a stranger can play three encounters and tell me if it's fun' is a milestone. Define every milestone as something runnable and showable, 2-6 weeks out, and cut scope — not quality, not the date — when it slips. Playable slices force integration (where the real problems live) and produce testable builds as a side effect.
The sequence that de-risks: core loop first, then the vertical slice, then content breadth, then polish. Any plan that defers 'is it fun?' past the first milestones is a plan to discover failure expensively.
The weekly review is the steering wheel
Fifteen minutes, same time weekly: What shipped? What's blocked and why? Is the top of the backlog still the fastest route to the current milestone? Anything here that should be cut? Solo projects don't fail in a day — they drift for months, and the review is where drift gets caught while it's cheap.
Track only two metrics: milestone date confidence (gut, but written down) and weeks of motivation runway. When either trends down two reviews running, the answer is scope surgery, not harder work.
Momentum is a resource — budget it
Progress you can see is fuel. Long stretches of invisible work — refactors, systems with no on-screen result — drain motivation even when they're necessary. Good project plans alternate: one stretch of plumbing, then something you can watch move on screen.
When motivation dips, shrink the loop. Pick the smallest change that makes the game visibly better today. Shipping anything, even a menu fix, restarts the engine.
Decide how you'll know it's working
Every project needs a definition of done that isn't a feeling. Pick the few signals you'll trust — playtesters finishing the demo, crash-free sessions, wishlists per week — and check them on a schedule. Otherwise you'll steer by whichever anxiety is loudest that day.
This is also the honest defence against endless polishing. When the signals say players get through it, enjoy it, and nothing breaks, the feature is done. Move on.
The quiet work that protects all of this
Everything in this post gets undone by an unstable build. A great store page, a clever marketing beat, a perfect jam entry — none of it survives 'crashed twice, refunded'. Stability isn't a feature players praise, but it's the floor everything else stands on.
Give yourself visibility before you need it: crash reports with stack traces, a simple way for players to flag issues from inside the game, and a habit of fixing the top recurring error before adding anything new.
Putting it to work
Don't try to act on all of this at once. Pick the one change that costs you the least and pays the most this week, do it, and see what actually happens before reaching for the next.
Most of this rewards steadiness over intensity. A small improvement made every week, checked against how real players respond, outruns any single burst of effort — in this corner of game development and every other one.
Scope to the hours you really have, then ship the small game that fits them.