Short answer: Product management is the job of deciding what to build, in what order, and proving whether it worked. The four habits that compound: talk to users regularly, decide priority weekly, define done in user terms, measure outcomes against pre-committed metrics. Everything else in the PM literature is variation. Most new PMs over-index on framework names and under-index on these four habits.
The responsibility of a product manager is to establish what should be constructed, in which sequence, and indicate if it was effective. That's the entire job. Lean, Agile, Jobs-to-be-Done, Continuous Discovery, Shape Up are frameworks for doing it, but the certifications are exits the industry built to monetise the question.
The rationale: most PM advice has been created by consultants or vendors that have a framework they want to sell. A Project Manager who uses the 4 habits consistently will outperform a Project Manager with 3 certifications who doesn't use the 4.
This guide explains the day-to-day work of a PM, the four habits that help earn this privilege, what to ignore in standard PM literature, and the most common new-PM failure mode Aiming new/first six months PMs and engineers wanting to transition or become a PM.
Product management basics, plainly
A PM is responsible for three decisions.
- What to build. Which problems are worth solving for users, and which solutions are worth shipping.
- In what order. Given everything that could be built, what should be built next.
- Whether it worked. After shipping, did the metric that should have moved actually move.
That is all we did. The remaining tasks involve supporting activities, such as organizing planning meetings, drafting product requirement documents (PRDs), communicating with engineers, managing stakeholders, and overseeing the project roadmap. All of it is a consequence of the three decisions.
A PM doesn’t do that.
- A project manager. Project managers track timelines and dependencies for already-decided work; PMs decide what work is worth doing in the first place. The boundary is sharper than most teams admit — see where product management and project management intersect for the friction points.
- A scrum master. SMs facilitate process; PMs make product decisions.
- An engineer with a different title. PMs work with engineers; they don't typically code in production.
- A designer. PMs work with designers; they don't typically own visual or interaction design.
In small teams, like PM/founder, PM/eng lead or PM/designer, the lines blur. When working in bigger teams boundaries are clear. In any case, the PM makes the three decisions.
The four habits that compound
| Habit | Cadence | Why it compounds |
|---|---|---|
| Talk to users | 5–10 conversations/quarter, minimum | Without it, the PM invents personas |
| Decide priority | Weekly | The order is what determines output |
| Define done in user terms | Per story | Engineers need to know what 'done' means |
| Measure outcomes | Per shipped feature, 30-day window | Without it, the PM repeats mistakes |
Every habit is ordinary. It is repeating wise practices every week, for years, even if the team is busy.
Connecting with your users is essential to the success of your team’s product. Anything less than that and the PM is deciding based on stakeholder asks, analytics and gut feel none of which beat actually hearing real users talk about their problems. Discussions need not be formal user research; coffee chats with existing clients, support ticket triage, and casual product-channel lurking all count.
Determine the priority. The PM’s job in a regular week is to be aware of what should the team work on next. Not “what is important” what’s literally next. This means simply maintaining an ordered backlog (not a “P1 / P2 / P3" matrix), which is also why prioritising across the themes in your product matters more than rank labels. Returning the decision to the meeting through the use of P1s results in an ordered backlog. For the maintenance side of that habit, grooming your backlog is a core PM skill.
The PM needs to write the done state from the user perspective, for each story. ‘A user can do X’. Not "the code is deployed." The done state is either complete or incomplete, can be confirmed visually, engineers can build on top of it, and QA can verify it. There is a craft to this — how to invest in your user stories covers the patterns that hold up.
Every shipped feature measures its success and we check back on it 30-days later. Has it changed? Measurable workplace indicators: With the estimated value? It is important to be upfront about negative results as they lead to the next round of discovery and not failures. The trap is picking the wrong metric in the first place — why vanity metrics don't correlate with long-term product success is the short version.
For two years, a PM who practices all four habits continuously develops product instincts faster than a PM who reads all PM books but skips one or two. The practice is where the compounding occurs.
What a PM actually does in a week
Overview of a working week of a mid-stage PM.
| Activity | Time |
|---|---|
| User conversations (interviews, support triage, customer calls) | 4–6 hours |
| Backlog grooming and prioritisation | 3–4 hours |
| Writing definitions / specs | 2–4 hours |
| Talking with engineers (1:1s, design discussions, ad-hoc questions) | 4–6 hours |
| Stakeholder updates and meetings | 3–5 hours |
| Metric review and analysis | 1–2 hours |
| Strategic / planning work | 2–4 hours |
| Admin, email, slack | 2–4 hours |
Cumulatively 25-35 hours of actual work; all other is overhead. Shifting of distribution per phase: early-phase PMs spend a majority of their time in discussions and definition; later-phase PMs spend a majority of their time in stakeholder management and metric review.
The formula behind smaller story estimates is: cycle times drop from days to hours, teams reach users up to 14× faster, and the PM’s availability is the rate-limiter. When the stories are small, and the team is shipping often, the PM is in the build/handoff loop every day. Ensure that your calendar indicates that your PM work is interruptible. You should not have large meetings blocking it off.
What to skip in the PM literature
7-Word Challenge: Early Deliverables minimize Later Overhead
Skip these specific things.
- OKR mechanics. The principle (set objectives, measure with key results) is fine. The dedicated software, the multi-level cascade, the "Are these stretch goals?" conversations are mostly ceremony.
- Roadmap formats. Now / Next / Later, OKRs-mapped-to-quarters, Gantt-style roadmaps. The format matters less than whether you can answer "what's the team working on this month" without checking a tool.
- Personas as standalone artifacts. Personas are useful as a shared shorthand for talking about user types. They're not useful as multi-page documents in a wiki that nobody updates.
- PM-specific certifications. Pragmatic Marketing, CSPO, Reforge programs. Skills matter, certifications generally don't.
- AI-generated user research summaries. Read the transcripts yourself; the summary loses the bits that make the user real.
- "Hill charts" / "Shape Up phases". The underlying ideas are useful; the proprietary vocabulary is a Basecamp marketing artifact.
From where I stand, and I do hope to make friends, most PM contemporary lit is designed to sell consulting services or a SaaS product. You can read Marty Cagan's books, Steve Blank, essays from Intercom as well as your user transcripts. Bypass everything else.
The most common new-PM failure mode
As we’ve added enough new PMs, one pattern stands out: the PM tries to do everything other than the four habits. (If you're still weighing the role itself, so you want to be a product manager lays out the trade-offs honestly.)
Symptoms.
- Are you spending hours reformatting the roadmap without a single user conversation per month?
- The lengthy PRD that no one reads.
- Backlog priorities should be set in meeting, not maintained between them.
- Shipped features do not have any metrics.
- Every quarter, we list the things we've shipped; nobody asks if they worked.
To fix things, allot time in schedules for user conversations whenever they are available. This is the simplest habit to miss when workload is hectic. Ensure the backlog stays as an ordered list and not categories. Always put done state in every story. Finally, ensure you write the metric in the spec.
The other failure mode is a PM doing engineering work. Accessing one particular piece of the code to read is difficult in microservices. While the team endorses engagement, they disapprove of the PM interjecting with decisions not in the PM role. Stay in the three decisions; trust the engineers.
When PM isn't the right role
The contraposition: PM isn’t the right role for everybody.
- You'd rather build than route. If you enjoy writing code more than running meetings, you'll be a frustrated PM. Consider engineering management or staying IC.
- You hate ambiguity. PM work is mostly deciding under uncertainty. If you prefer well-defined work, project management or program management may fit better.
- You don't enjoy talking to users. The job has talking to users built in. If you find that draining, it's the wrong job.
- You want control over outputs. PMs influence; they don't control. The engineers ship; the PM convinces. If you want to dictate, you'll burn out.
For those that relish ambiguity, the user contact, and the routing information role: PM is one of the few roles in software that allows you to have a large impact without people management. It is worthwhile for the appropriate fit.
Frequently asked
What does a product manager do?
Choose what to create first; decide the order of creation afterward. The four habits that facilitate making these decisions are to speak the user, weekly decide on priority, done is user, and outcome is measured. All other matters, such as PRDs, roadmaps and stakeholder management, can be categorized as downstream issues.
What's the difference between product management and project management?
Project management focuses on how something already chosen will be built. Success using project management is measured according to whether it is on-time and on-budget. Project manager pertains to scope; project and program manager refers to execution.
Do I need a PM certification to get the job?
No. Certifications such as CSPO, Pragmatic Marketing, and Reforge help practitioners understand terminology better. However, they rarely help with hiring. Most organizations care about proof and judgment shipped solutions, user-research procedure, decision-making history.
How much should a PM talk to users?
Have at least 5-10 conversations a quarter, ideally every week/2. Omitting proper design research forces the PM to make decisions from stakeholder requests plus some intuition neither of which substitutes for hearing real users.
Do PMs need to know how to code?
It is situational based on the team. When it comes to the technical product manager roles in developer tooling, APIs, infrastructure products; some technical depth is required. Consumer PMs frequently do not. In most teams, it’s more important to have engineering literacy (can you reason about trade-offs?) than coding ability.
What's the most common new-PM mistake?
Not using any of the four habits. There's a lot of time spent on managing the roadmap and stakeholders, but zero time spent to talk and measure the outcome with end-users. Block out the time in your calendar for the practices, and protect that time.
Should I use OKRs?
The fundamental idea of objectives and measurable key results is sound. Most of the proprietary mechanics (tailored software, cascade across several levels, quarterly resets) are overhead. Apply the Principle, Don’t Get Stuck in the Ceremony
How does AI change the PM role?
Artificial intelligence is currently assisting or affecting product managers’ use of specifications with faster drafts, user-research synthesis with variable quality, and analysis with mixed results. The four habits haven't changed. Project Managers successfully implementing AI use it as leverage for their support work rather than a replacement for their core decisions.
Still stuck
For effective Product Management, it is essential to cultivate four habits- Talking to users, Making priority calls, Defining done in user terms and Measuring outcomes. Most PMs who have failed have failed because they skip one or two of these.
LiteTracker is a tracker that honours the discipline of the four habits: a single ordered backlog (the order is priority), one owner per card (decisions are attributable), and story-only velocity (outcomes are user value). Unrestricted users in free plan. If you are a solo-founder executing a 2-week MVP the tool is not for you a shared doc will be faster.
Whether one opts for Scrum, Lean, or XP run with the habits for the rest of the PM job to get easier.