Product Development for Side Projects

Why enterprise product process breaks on a solo build

Every enterprise product ritual is coordination overhead in disguise. Sprints, standups, PRDs, design reviews, staging gates — each one exists to keep specialists who cannot see each other's screens working from the same picture. On a side project you are the product manager, the designer, the engineer, and the support inbox living inside one skull, so that coordination cost rounds to zero. Run the rituals anyway and you pay a tax to solve a problem you do not have: writing a two-page spec for a feature you could have built in the afternoon the spec took to write.

The incentives are inverted too. A company optimizes to avoid shipping the wrong thing, because a wrong bet there burns a quarter and a dozen salaries, so front-loaded planning is rational. Your wrong bet costs a Saturday. That single difference should reshape everything downstream — you want cheap, fast, frequent wrong bets, not expensive certainty. Any practice that trades your scarce evening hours for a little more confidence before you ship is almost always a bad trade at this scale, because the market answers the question faster and more honestly than your planning ever will.

What a one-person product cycle actually looks like

Replace the two-week sprint with a single loop you can run end to end across one to three weekends. Pick one hypothesis, build the smallest thing that could test it, put that in front of a handful of real people from the audience you actually care about, read one signal you named in advance, then decide to keep, cut, or kill. The discipline lives in running all five steps every cycle — not in the artifacts. Most stalled side projects are stuck forever polishing step two.

The step people quietly skip is the signal, and skipping it is exactly why projects drift for months without ever dying. Decide before you write a line of code what result would make you continue: five of ten testers coming back unprompted, three replies asking when it ships, one stranger who is not your friend actually paying. Without that line drawn ahead of time, every lukewarm outcome reads as a maybe — and maybe is the precise condition that keeps a dead project on life support while it eats the hours a live one deserves.

• →Hypothesis: one sentence naming who has the problem and what would make them stop what they are doing to pay attention
• →Slice: the smallest buildable version — often a single screen, a script, or a form, with no auth, billing, or settings
• →Ship: get it in front of five to ten real people in that audience this week — a direct message, not a launch
• →Signal: the one result you committed to before building — did they come back, reply, or hand over money?
• →Decide: keep, cut, or kill on a fixed calendar, not whenever guilt or enthusiasm happens to strike

How to scope a version one you can ship in a few weekends

The enterprise MVP is still far too heavy for one person — it quietly assumes accounts, billing, and an admin surface exist on day one. Cut harder than that. Aim for a walking skeleton: the single path that delivers the core value, with everything around it hardcoded, faked, or done by your own hands offstage. Concierge delivery — you manually doing behind the scenes what the product will eventually automate — is not cheating. It is the fastest way to find out whether the value is real before you spend six weekends building the machine that produces it.

Every piece you defer is also a piece you do not have to maintain, migrate, or debug while you are still deciding whether the thing deserves to exist. The test for any feature in version one is blunt: does removing it stop the very first user from reaching the core value? If the answer is no, it is not version one — it is a comfort you are building for yourself so the project feels more like a real product and less like an experiment that might fail.

• →Accounts and login: email a private link or share one password until someone specifically asks for their own account
• →Billing: take the first payments by hand with an invoice or payment link before you wire up Stripe
• →Settings and configuration: pick one sane default; a preference nobody has requested is scope you invented
• →Admin panel: you are the admin — query the database directly and skip the interface for now
• →Responsive polish: build for the one device your first users are actually on, not every screen size at once

Which enterprise practices to keep and which to drop

Not everything from a real product org is waste — a few practices survive contact with a team of one, in shrunken form. The test is whether a practice still does useful work once there is nobody to coordinate with. Keep the ones that sharpen your own thinking; drop the ones whose only job was to move intent from one person's head into another's.

The pattern across the table below is the same every time: strip each practice down to the single question it was actually asking, then answer that question in a sentence instead of a ceremony. A roadmap asks what is next. A retro asks what the last bet taught you. You can answer both over one coffee. What you cannot afford on five to ten hours a week is to let the artifact quietly become the work while the product stops moving.