Side Projects That Prove You Can PM (and the Kind That Waste Your Time)

A good product side project proves you can find a real problem, choose what to build and what to skip, and ship a defensible decision — not that you can code a polished app. The strongest ones document a discovery-to-decision trail: who you talked to, what you deprioritized, and why. Weak ones are portfolio pieces nobody asked for.

Quick Answer: Pick a side project that forces you to run discovery, make a trade-off, and defend a shipped decision — then document that trail explicitly. Skip anything where the only artifact is a finished app.

Hiring managers reviewing a PM candidate's side project are not evaluating your Figma skills or your ability to deploy a Next.js app to Vercel. They're pattern-matching against the job itself: did this person talk to users, did they say no to something, and can they narrate a decision under ambiguity? Most side projects fail that test not because the idea was bad, but because the artifact left behind was code, not judgment.

What Makes a Side Project "Signal" Instead of "Noise"

Signal side projects leave behind evidence of a decision-making process — discovery notes, a prioritization rationale, a documented trade-off — while noise side projects leave behind only a finished product. The distinction isn't ambition or polish; it's whether an interviewer can reconstruct how you thought, not just what you built.

A hiring manager skimming your portfolio is looking for three specific things, in order:

1. Evidence you talked to real users or approximated it rigorously (not just your own opinion of what's missing in an app category).
2. Evidence you said no to something — a feature you scoped out, a segment you didn't build for, a v1 you deliberately kept thin.
3. Evidence you can narrate the "why" behind a shipped decision, including what you'd do differently.

None of these require shipping code at all. A discovery memo with a scoped-down feature list and a one-page rationale can out-perform a fully functioning app in an interview, because the app answers "can you build things" — a question nobody's asking a PM candidate — while the memo answers "can you decide things," which is the actual job. If you're earlier in the transition and still mapping out what the role expects day to day, the complete guide for aspiring PMs and a walk through a PM's day in the life, hour by hour are useful before you pick a project, since they clarify what "PM work" actually looks like versus what engineering or design work looks like.

The Noise Pattern to Avoid

The most common noise project is the solved-problem clone: a to-do list app, a recipe organizer, a habit tracker, rebuilt because it was a fun weekend build, with zero discovery behind the feature list. It's noise not because the execution is bad — it's often technically impressive — but because there's no evidence of a PM decision anywhere in it. The feature set matches the last five clones of the same app, which tells an interviewer you copied a spec, not that you wrote one.

The Project-Selection Filter: Four Questions Before You Start

Before committing to a side project, run it through four filter questions; if you can't answer at least three with a real (not hypothetical) plan, pick a different project. This filter matters more than the idea itself, because the same app idea can be signal or noise depending entirely on how you approach it.

Reachable segment beats broad audience. If your target user is "anyone who wants to save money," you can't run real discovery interviews because you can't find five specific people to talk to. Narrow until you can name a Slack community, a subreddit, or a set of coworkers who fit.

A named exclusion is worth more than a feature list. Anyone can list what they'll build. Naming what you won't build — and why — is the actual prioritization skill interviewers want to see, and it's the one candidates skip because it feels like doing less.

Three Project Shapes That Tend to Work

1. A narrow tool for a community you're already in (a Discord mod's moderation dashboard, a fellow parent's daycare-comparison tracker) — you get free access to real users for discovery.
2. A teardown-and-redesign of an existing product's weakest flow, backed by usability observations, not opinion — this works even without writing code, since the deliverable is a redesigned flow with rationale.
3. A "spec-only" project: a full PRD, discovery synthesis, and prioritized roadmap for a real, unsolved problem, with no code shipped at all — controversial with some interviewers, compelling with others, and worth having as a backup format.

Running Discovery on a Side Project Without a Team or Budget

You can run credible discovery on a side project with 5-10 structured conversations, a simple synthesis method, and one prioritization pass — the same rigor a scaled-down team would use, just without the tooling budget. The bar isn't sample size; it's whether you can show your reasoning traceably.

Use a lightweight version of Jobs to Be Done (JTBD), the framework Clayton Christensen popularized and Tony Ulwick operationalized into outcome-scored opportunity interviews: instead of asking "what features do you want," ask what job the person is "hiring" a solution to do, and what's currently getting in the way. Bob Moesta's later work on the "Four Forces of Progress" (push, pull, habit, anxiety) is a useful lens for why someone hasn't already switched to an existing tool — often the more interesting finding than the feature gap itself. If jobs-to-be-done is new to you, the complete guide to Jobs to Be Done walks through the interview structure and synthesis method in more depth than fits here.

A Minimal Discovery Loop You Can Run in a Weekend

• Recruit 5-8 people from a community you already have access to — not cold outreach, which burns your limited time on response-rate problems instead of interview quality.
• Ask about the last time they tried to solve this, not hypothetically whether they'd use your idea — specific past behavior is far more reliable than a stated future intent.
• Map responses to a simple journey: where does friction spike, where does it recede? A structured pass through the customer journey framework gives you a shared vocabulary — awareness, consideration, onboarding, ongoing use — so your synthesis reads as method, not vibes.
• Score the 3-5 recurring pain points, not every idea that came up, so your v1 scope traces back to what people actually said.
• Write a one-page synthesis before you touch a feature list — this is the artifact that survives, whether or not you ship code.

Documenting the Decision So the Artifact Carries the Story

The documentation you produce matters more than the code, because an interviewer reads your writeup in five minutes but would need an hour to evaluate your codebase — so the writeup is what actually gets judged. A good template has four sections: the problem framing, the discovery synthesis, the prioritization call, and the retrospective.

A shipped feature with no documented "why" reads as a hobby. A documented trade-off with no shipped feature still reads as product work.

A Documentation Template That Works in an Interview

1. Problem framing (3-4 sentences): who has this problem, what job are they hiring a solution for, why does it matter now.
2. Discovery synthesis (half a page): how many people you talked to, the method, the 3-5 things you heard repeatedly, and one surprising finding that contradicted your initial assumption.
3. Prioritization call (the core artifact): the shortlist of features you considered, the framework you used to rank them (a simple RICE score — reach, impact, confidence, effort — is enough), and specifically what you cut and why.
4. The trade-off you'd defend (2-3 sentences): the one decision you'd want a hiring manager to push back on, and your answer for it — this is the section that actually gets discussed in the interview.
5. Retrospective (3-4 sentences): what you'd do differently with more time or budget, and what you learned about your own blind spots.

Section 3 is the load-bearing one. Interviewers rarely ask "walk me through your feature list" — they ask "why did you build A instead of B," and if your only answer is "I thought A was cooler," the project stops working for you regardless of execution quality.

Running the Discovery-to-Prioritization Pass in Prodinja

If you want structure around this instead of building the template from scratch, Prodinja's Customer Jobs studio walks you through a JTBD-and-Ulwick-style opportunity-scoring pass on your own side project idea, and its RICE Studios let you run the reach/impact/confidence/effort scoring and get a defensible prioritization call out the other side. Using both turns a weekend build into something that reads as a discovery-to-decision trail rather than a hobby project — which is exactly the gap this article has been describing. Prodinja is shipping today as an interactive prototype, so treat it as a structured way to practice the muscle, not a finished production tool.

Choosing a Format When You're Coming From Engineering or Design

The right side-project format depends on which skills you're translating, not just which idea sounds most impressive; an engineer's default (build something end to end) and a designer's default (make it beautiful) both need a deliberate correction toward discovery and trade-off documentation.

If you're coming from engineering, the engineer-to-PM transition guide covers this correction in more detail — the risk is defaulting to "let me show you what I built" when the interviewer wants "let me show you what I decided." If you're coming from design, the designer-to-PM transition guide covers the parallel correction, where visual craft needs a prioritization layer added on top to read as product work rather than portfolio work.

Key Takeaways

• A side project's value is the decision trail it leaves, not the code — discovery notes, a prioritization rationale, and a defended trade-off outlast a polished app in an interviewer's memory.
• Run the four-question filter before starting: a reachable segment, a real validation plan, a named exclusion, and a defensible trade-off — skip the project if you can't answer three of four honestly.
• Solved-problem clones (to-do apps, habit trackers) are the most common noise pattern because they signal execution, not judgment, unless discovery is added deliberately.
• A lightweight JTBD interview loop with 5-8 people, synthesized against a customer-journey map, gives you real discovery without a research budget.
• The documentation template — framing, synthesis, prioritization call, defended trade-off, retrospective — is the actual interview artifact, whether or not you ship a working app.
• Engineers should correct toward documenting "why"; designers should correct toward adding a prioritization artifact on top of visual polish.