Product management
Product management means deciding what to build, why it matters, and whether it worked.
What product management involves
Product management is the work of deciding which customer problems a product should address, how solving them supports the organization’s goals, and where to invest the team’s time. It includes helping the team deliver a useful solution and checking what happened after people began using it.
A product manager helps bring customer research, business needs, design, and engineering judgment into these decisions. The work is shared: engineers contribute what is feasible, designers investigate how people will use a solution, and customer-facing teams bring evidence from sales and support.
Roadmaps, research reports, and product requirements documents help people coordinate this work. Their usefulness depends on the decisions they support and the information they preserve.
We build Shorter Loop for product teams. This page explains the view of product management that informs our work, using six recurring decisions as a practical framework.
Good delivery still needs a reason for choosing the work
A team can release reliable software on schedule and still see little improvement for customers or the business. One possible explanation is that it chose a problem that mattered less than expected. Another is that the proposed solution did not address the reason people were struggling.
Completing interviews or maintaining a roadmap does not, by itself, resolve those uncertainties. Research needs to inform a decision. A roadmap needs to make the priorities and their reasons clear enough for people to review them.
Research can also support keeping the current plan. The important question is whether the team considered what it found, including evidence against its preferred explanation, and could have changed course.
Delivery quality remains essential. Reliable releases and small changes help teams learn safely. Product management connects that delivery work to an explicit problem, an expected result, and a reason to believe the investment is worthwhile.
Six decisions to revisit as you learn
The six decisions below cover much of the reasoning behind product work. They are a useful way to organize discussion, not a complete list of every responsibility. Decisions about pricing, distribution, technical investment, and other concerns may need additional analysis.
The decisions overlap. Investigating a solution may reveal that the team misunderstood the customer’s problem. Results after release may change which problem deserves attention next. Teams can revisit any decision when new information warrants it.
Start with the objective: what improvement matters for customers and the organization? That gives the team a basis for comparing problems and judging results.
Worked example: the sections below follow a fictional team building expense-management software. Its objective is to reduce delayed employee reimbursements. All details illustrate a possible decision process; they are not customer evidence or Shorter Loop results.
The six decisions in practice
Which problem should we address?
Choose a problem in relation to the objective and the other demands on the team.
Compare the problems you could address. Look at who experiences each one, how often it occurs, how serious it is, and how it relates to the objective. Customer statements help establish what people experience; usage records and other observations can help test the explanation. Where evidence is limited, record what is still an assumption.
In the example, the team considers missing receipts, slow approvals, and delays in payment processing. It compares support conversations with timestamps from submitted claims. Those sources suggest that approval delays deserve further investigation.A large customer request or an existing commitment can arrive as the priority before alternatives are discussed. The request may be justified, but its origin alone does not establish its importance. Ask what evidence supports it and what other work would be deferred.
Choosing a less important problem uses capacity that could have addressed something more valuable. The cost depends on the size of the commitment and the alternatives delayed; it is not automatically an entire quarter.
Whose problem are we solving?
Identify the people affected and the circumstances in which the problem occurs.
Describe relevant behavior and constraints: what people are trying to do, what gets in the way, and how they cope today. Distinguish users, buyers, and other affected people when their needs differ. A segment is useful when it helps the team choose whom to investigate and what to design for.
In the example, employees experience the late reimbursement, while managers perform the approval. Research suggests that managers approving claims across several teams struggle to identify what is waiting on them. The team needs to understand both groups.A broad customer category or an assumed persona can conceal different needs. This can happen when research access is limited or sales conversations are the main source. Check whether the description reflects observed behavior and where it may not apply.
A solution designed around the wrong user or situation can be hard to adopt. For example, an employee-facing improvement might leave the manager’s approval delay untouched.
Is the problem worth solving now?
Compare the likely benefit with the full cost of addressing it and the other uses of that investment.
Estimate the benefit to customers and the organization, then consider development, maintenance, support, and work that would be postponed. Use ranges where the inputs are uncertain. Include constraints such as cash, contractual commitments, accessibility, and risk; not every consideration has a useful monetary estimate.
In the example, the team estimates the time employees and finance staff spend chasing approvals. It compares that burden with the cost of a limited pilot and a broader workflow change. The pilot can be worthwhile if it resolves uncertainty before a larger commitment.A prioritization score can look more precise than its inputs justify. Scores are useful for comparison when assumptions are visible and teams can challenge them. Check whether plausible changes to the estimates would change the ranking.
The organization may spend more than the improvement is worth or delay more urgent work. A large commitment is harder to recover from when money or specialist capacity is limited.
Which solution should we try?
Compare plausible approaches and test the assumptions that matter most to the choice.
Identify what must be true for each approach to work. Focus testing on assumptions that combine substantial uncertainty with serious consequences if wrong. A prototype, technical investigation, or small pilot can be enough to inform the next decision. Testing every assumption is rarely practical.
In the example, the team compares reminder emails, a consolidated approval queue, and automatic approval for selected claims. It tests whether managers can find and resolve waiting claims in a prototype queue. Security and policy constraints also affect which approaches are acceptable.A solution can become an accepted commitment before the team has compared alternatives. Budget approval, sales promises, or a narrow brief can encourage this. A requirements document should explain the choice as well as specify what to build.
The team may address a real problem with a solution people cannot use, do not trust, or cannot adopt within their workflow. Learning this through a limited test can reduce the cost of revising the approach.
Should we continue, change, or stop?
Reconsider the remaining investment when results, costs, or circumstances change.
Agree what you expect to learn, when to review it, and what findings would support continuing, changing the approach, or stopping. Consider the expected benefit and cost of the remaining work. Time already spent cannot be recovered, although existing commitments and switching costs still matter.
In the example, the team pilots the approval queue with a limited group. It reviews approval time, unresolved claims, and manager feedback. If approvals are faster but reimbursements remain delayed, it investigates the next cause before expanding the same solution.Work can continue because funding and reporting reward completion of the original scope. Teams may also lack authority to change a commitment. Assign an owner for the review and a clear path for changing the plan when evidence warrants it.
Continuing without review can increase an avoidable loss. Stopping too early can also waste a promising investment. An inconclusive result may justify a better test rather than an immediate decision to abandon the work.
Did the work produce the intended result?
Check the customer and business outcomes, and assess how much the change contributed.
Define the intended result and how it will be measured before release. Adoption shows whether people use the solution; outcome measures show whether the relevant problem improved. A before-and-after comparison is useful, but other changes may explain the difference. Where practical, use an experiment or a suitable comparison group. Otherwise state the limits of the evidence.
In the example, the team measures approval time and total time to reimbursement. It also checks for incorrect approvals and extra finance work. Faster reimbursement after release is encouraging, but a simultaneous staffing change could have contributed. The team records what the evidence supports and what remains uncertain.Outcome review can be missed when ownership ends at release, data is unavailable, or the team is assigned new work immediately. Set the review date and measurement responsibilities while planning delivery, allowing enough time for the expected effect to appear.
The organization may expand an ineffective solution or miss an improvement worth extending. It also loses information that could make the next investment decision better.
What roadmaps, personas, and other artifacts should preserve
An artifact is a work product such as a roadmap, research report, or specification. Each can support several decisions. It should preserve enough context for someone else to understand what was decided, why, and what remains uncertain.
- The roadmap records priorities, their intended outcomes, and the reasons for choosing them. It can support problem selection, investment, and continuation decisions. Review it when new evidence changes those reasons.
- The persona or customer profile summarizes relevant behavior, needs, and constraints. Link it to research and mark assumptions so people can judge where the description applies.
- The prioritization model makes comparison criteria and estimates visible. Preserve the assumptions and uncertainty behind a score so the team can revisit the ranking when inputs change.
- The product requirements document (PRD) explains the problem, proposed solution, constraints, and expected result. It also specifies the behavior the team needs to build. Preserve the reasons for the choice and links to supporting research.
- The experiment record states the question, method, observations, and interpretation. Experiments can inform problem selection, solution choice, or whether to continue. An inconclusive result should remain labeled as inconclusive.
- The analytics dashboard and retrospective help the team examine results and improve its work. A dashboard reports measures; a retrospective examines what happened and what to change. Neither, on its own, proves that a release caused an outcome.
The level of documentation should match the consequences of the decision. A small, easily reversed change may need a brief note. A major investment needs enough detail to examine the alternatives, assumptions, and reasons for committing. Review the document when those reasons change.
Product integrity connects decisions as the evidence changes
A decision can be reasonable when it is made and become less reasonable later. Product work needs a way to carry new evidence back to the people and plans it affects.
In the fictional expense-software example, suppose the approval pilot reveals that reimbursements are mainly delayed after approval, while finance waits to run payments. That finding should lead the team to revisit its explanation of the problem, its proposed next investment, and the roadmap. Completing the approval feature would not resolve the newly identified delay.
Product integrity is the ability to keep product decisions connected to the evidence, assumptions, reasoning, delivery work, and outcomes that should inform them as those things change over time. Those connections help a team identify what to reconsider and decide what to do next.
Separate tools can support this work if the links, ownership, and review practices are maintained. A shared platform can make the information easier to follow, but neither arrangement guarantees sound decisions. Someone still needs to assess the evidence and act on what it changes.
Shorter Loop brings product discovery, feedback, prioritization, roadmaps, and delivery planning into a shared workspace. This is the product work our approach to product integrity is intended to support. The links below explain the concept and the platform in more detail.
Review one current decision with your team
Choose one item your team is building or considering. Bring the people who understand the customer problem, the proposed solution, and the delivery constraints. Use these questions to identify what you know and what needs attention.
- What problem are we addressing, who experiences it, and how does solving it support our objective? Find the evidence behind the choice and the alternatives we considered.
- What does the latest research support or challenge? If we kept the same plan, can we explain why the findings justified that choice?
- Which assumption would most undermine the solution if it were wrong? Consider both how uncertain it is and the consequences of being wrong. Decide whether a small test would change the next commitment.
- What result do we expect, when will we check it, and who will review the evidence? Agree what would prompt us to continue, change the approach, or stop.
Record one next action, an owner, and a review date. If the team cannot act on what it learns because of a fixed commitment or unclear authority, make that constraint explicit and involve the person who can resolve it. The review should help people improve a decision without requiring them to defend every earlier choice.
Explore product integrity and how Shorter Loop supports it
- Product integrityHow decisions stay connected to evidence, assumptions, delivery, and outcomes as information changes.
- The product failure ontologyA catalog of product decision failures, with explanations of how they arise.
- How Shorter Loop worksExplore the capabilities that support discovery, planning, collaboration, and delivery.
- Choosing a product toolCompare approaches and assess whether Shorter Loop fits your team’s work.