Writing User Stories When You're the Developer, PM, and CEO

Every agile textbook on user stories assumes you have a product manager, a business analyst, maybe a UX researcher. You have a laptop, a deadline, and three tabs open.

The standard advice doesn’t apply. But the underlying concept is still one of the most useful tools you have — if you strip away the ceremony and keep the core.

Here’s a system that works when you’re building alone.

Why User Stories Are Still Useful Solo

The purpose of a user story isn’t to fill a Jira board. It’s to force you to think from the user’s perspective before you write a single line of code.

Without stories, most solo developers build features they want to build. With stories, you build features that solve a specific problem for a specific user. The difference shows up in adoption.

The Minimum Viable Story Format

Forget the extended “As a [user type], I want [goal] so that [reason]” format with acceptance criteria tables and edge case appendices. For solo development, use this:

Story: [one line describing the user action]
Why: [one line on why this matters to them]
Done when: [the 2-3 conditions that tell you it's complete]

Example for a booking app:

Story: User can cancel a booking within 24 hours
Why: Plans change; not being able to cancel creates anxiety and abandonment
Done when:
- Cancel button is visible on booking detail page
- Cancellation sends a confirmation email
- Cancelled booking no longer shows as active

That’s it. Write this before you touch the code. It takes four minutes and saves you from building the wrong thing for two hours.

Story Sizing Without a Team

Story sizing exists so a team can estimate sprint capacity. Solo, you don’t need points. You need time buckets:

Small: Under 2 hours
Medium: 2–8 hours
Large: More than a day (split this into smaller stories if possible)

If you’re putting “Large” on everything, your stories are too big. Break them down. A story should describe one user action and its direct outcome — not an entire feature.

Prioritising Without a Product Team

Solo developers often have 30 things on the backlog and no framework to choose between them. Try this scoring method for each story:

User Impact (1–3): Does this affect the core journey? (3 = yes, 1 = edge case)
Effort (1–3): How much work? (1 = small, 3 = large)
Revenue/Retention (1–3): Does completing this directly affect whether users pay or stay?

Score = (User Impact + Revenue) ÷ Effort

High score = do first. Low score = do later or drop.

This isn’t perfect. But it takes 10 minutes across a full backlog and stops you from spending a week on the thing that felt urgent but didn’t matter.

The “Future Me” Test

Before writing a story, ask: “If I come back to this in three months having forgotten everything about it, will this story tell me exactly what to build and how I’ll know it’s done?”

If the answer is no, add one more “Done when” condition. That’s usually all it takes.

When to Accept You Need Help

You can run a lean product process solo for a long time. But there are signals that you’ve outgrown it:

You’re consistently underestimating stories by 3x or more
You keep building things users don’t use
You’ve shipped 3+ features in a row that needed immediate rework
Your backlog has more than 40 items and you’ve lost confidence in what matters

At this point, even 4–6 hours of fractional product help — someone to run a proper story mapping session with you — can reorganise everything and buy you weeks of clarity.

Building something and need someone to sense-check your product process? I do short-engagement product ownership work for solo developers and small teams. No retainer required.