What product management actually means

Product management is the discipline of deciding what to build, why to build it, and in what order. That sounds simple. It is not. The reason it exists as a role is that the intersection of user needs, business constraints, and technical feasibility is genuinely hard to navigate without a structured approach.

A product manager is not a project manager. A project manager ensures that things get done on time and on budget. A product manager ensures that the right things get done at all. The distinction matters because you can execute perfectly on the wrong problem and still ship something nobody uses.

At its core, product management is about three things: discovery (understanding the problem), definition (deciding what to build), and delivery (shipping and learning). Most teams are strong at delivery and weak at discovery. They move fast, but in the wrong direction.

When I was building Sunna Planner, I was not thinking in product management terms at first. I was building for myself, fixing my own problems. But over time I realized that every decision I was making, what to ship, what to cut, what to delay, was a product decision. Having a mental framework for those decisions changed everything. It made me faster, not because I was moving quicker, but because I was wasting less time on the wrong things.

Good product management reduces rework. It reduces the cost of being wrong. And it gives you a shared language for talking about tradeoffs, even if the only person in the room is you.

The discovery process: understanding the problem before you build

Discovery is the most underrated phase of product development. It is the work you do before you write a single line of code, before you open Figma, before you write a spec. It is the work of understanding whether the problem you want to solve is real, who has it, and how painful it actually is.

There are several methods for discovery. User interviews are the most direct. You talk to people who have the problem you are trying to solve and you listen more than you speak. The goal is not to validate your solution. The goal is to understand the problem in enough detail that a good solution becomes obvious.

Jobs-to-be-done is a useful lens here. Instead of asking what users want, you ask what job they are hiring your product to do. A person using a productivity app is not just trying to manage tasks. They might be trying to feel in control of their day, or to signal to themselves that they are serious about their goals. Understanding the real job changes what you build.

For solo founders, formal discovery sessions are not always realistic. But the principle still applies. Read support tickets. Look at what people say when they churn. Pay attention to the features people request most, but more importantly, pay attention to the underlying need behind the request. A user asking for a calendar view is not asking for a calendar view. They are asking to see their week at a glance. Those are different problems with different solutions.

Discovery never really ends. It is a continuous practice, not a phase you complete once at the start of a project.

Prioritization: the hardest skill in product

Once you know what problems exist, you have to decide which ones to solve first. This is where most product decisions go wrong. Teams either prioritize based on who shouted loudest, or they try to build everything at once and ship nothing well.

There are several frameworks worth knowing. RICE (Reach, Impact, Confidence, Effort) gives you a numeric score for each initiative so you can compare them on the same scale. It forces you to be explicit about your assumptions. MoSCoW (Must have, Should have, Could have, Won't have) is simpler and useful for release planning. The Kano model helps you distinguish between features that prevent dissatisfaction and features that genuinely delight users.

In practice, no single framework is perfect. What matters is having a consistent logic. When I was deciding whether to add Google Calendar sync to Sunna Planner, I did not run a formal RICE calculation. But I thought through reach (how many users would benefit), impact (would it change their daily behavior), and effort (what the integration actually required). That thinking led me to prioritize it for the v2 to v3 transition, and to put it behind the premium tier because it added real value without being a core feature.

One principle I keep coming back to: say no by default. Every feature you add is a feature you have to maintain, document, and support. The best product decisions are often the ones that remove something, not the ones that add something.

If you want to go deeper on how prioritization connects to growth strategy for small teams, this article on SaaS growth for solo indie hackers covers how those decisions compound over time.

Roadmapping: planning without lying to yourself

A roadmap is not a promise. That is the most important thing to understand about roadmapping. It is a living document that communicates direction, priorities, and intent. It changes as you learn more. Treating it as a fixed commitment is one of the most common and most damaging mistakes in product teams.

There are different types of roadmaps. A now-next-later roadmap is the most flexible. It organizes work into three time horizons without committing to specific dates. It is honest about uncertainty. A quarterly roadmap is more structured and useful when you need to communicate with stakeholders who want dates. A feature roadmap lists specific features. An outcome roadmap lists the problems you are trying to solve, which is often more honest and more useful.

For solo founders and small teams, I recommend starting with a simple document: three columns (now, next, later), populated with problems or outcomes rather than features. This keeps you focused on why you are building, not just what you are building.

The other thing a roadmap does is force prioritization conversations. When everything is on the list, nothing has priority. The act of ordering your roadmap, of deciding what comes first and what gets pushed, is itself a product decision. Do it deliberately.

Tooling matters less than the habit. I have used Notion, Linear, and simple spreadsheets. The tool you will actually maintain is the right tool. For anyone building a mobile product and thinking through sequencing decisions early, this guide on building a mobile app solo gets into how those decisions play out in practice.

Agile in practice: what actually works for small teams

Agile is a set of principles, not a process. The Agile Manifesto values individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. Those principles are genuinely good. Most of what gets sold as Agile is not.

Scrum, the most common Agile framework, was designed for teams. It has sprints, sprint planning, daily standups, sprint reviews, and retrospectives. For a solo founder, most of that overhead is waste. But some of it is valuable. The concept of working in timeboxed iterations, shipping something at the end of each sprint, and reviewing what you learned before starting the next one, that is valuable at any scale.

What I use is a lightweight version. I work in two-week cycles. At the start of a cycle I decide what I am going to ship. At the end I review what shipped, what did not, and why. That is it. No standup with myself. No velocity tracking. Just a rhythm that forces regular decision-making and prevents endless work-in-progress.

Kanban is useful for ongoing work that does not fit into sprints, support, bugs, content, small improvements. A simple board with three columns (to do, in progress, done) is enough. The key is limiting work in progress. Finishing things is more valuable than starting things.

The Sunna Planner Projects module actually reflects this. Kanban boards, sprints, and a vision board in the same tool, because I built the workflow I wanted to use myself. That is the most honest form of product validation there is.

Building product solo: what changes and what stays the same

Solo product development compresses all of the product management roles into one person. You are the product manager, the designer, the developer, the customer support agent, and the growth person at the same time. That is genuinely hard. But it also has advantages that are easy to underestimate.

When you are solo, feedback loops are short. You talk to a user, you understand the problem, you ship a fix, you see the result. There is no translation layer, no handoff, no misinterpretation. The insight goes directly into the product. That speed is a real competitive advantage against larger teams.

The risk is losing the discipline of product thinking when you are deep in execution. When you are coding, it is easy to keep adding features because you can, not because you should. Keeping a regular habit of zooming out, looking at your metrics, reading user feedback, and asking whether what you are building is actually the most important thing, that habit is what separates a productive solo founder from a busy one.

One thing that helped me significantly was automation. Not to replace product thinking, but to reduce the time I spent on things that were not product thinking. If you are spending hours on tasks that could be automated, that is time you are not spending on the decisions that actually matter. I wrote about the automation stack I use for solo development at this link.

The fundamentals of good product management, understanding the problem, prioritizing deliberately, shipping and learning, do not change based on team size. What changes is how you implement them. Solo, you have to be more disciplined, not less, because there is no one else to catch your blind spots.

FAQ

What is the difference between product management and project management?

Project management is about execution: delivering on time, on scope, on budget. Product management is about direction: deciding what to build and why. A project manager ensures the plan is followed. A product manager questions whether the plan is the right one. Both matter, but they answer different questions. On small teams, one person often does both, which is why the distinction gets blurry.

Do you need a formal framework to do product management well?

No. Frameworks like RICE, MoSCoW, or Jobs-to-be-done are tools, not rules. What you need is a consistent logic for making decisions: a way to compare options, explain your reasoning, and revisit your assumptions when new information comes in. A simple spreadsheet with clear criteria beats a sophisticated framework you do not actually use.

How do you prioritize when everything feels urgent?

The first step is separating urgent from important. Most things that feel urgent are not actually important. Ask: if I do not ship this in the next two weeks, what actually happens? Then ask: what is the one thing that, if I get it right, makes everything else easier or less necessary? That second question is harder but more useful. Start there.