Imagine a sales team has promised a large customer a custom export by month end. The product manager is asked whether to honor the promise. Before answering, separate three things. An **outcome** is an observable change in a user's task or in product performance, such as less time spent preparing a report. An **output** is what the team builds, such as an export button. An **activity** is work performed, such as writing a specification or holding a meeting. A team can complete the activity and ship the output without achieving the outcome. The customer may need dependable sharing permissions rather than another file. That is why a product decision cannot start and end with a request list.
In this program, product management means coordinating decisions about the problem, value, priority and learning within authority delegated by the organization. It does not give one person license to dictate the interface to a designer, the architecture to an engineer, or a commercial commitment to sales. In a Scrum team, the Scrum Guide makes the Product Owner accountable for maximizing product value and managing the Product Backlog. It does not prescribe every decision right in every organization. If a team does not use Scrum, do not transfer that job title automatically. Ask instead who chooses the desired outcome, who chooses the solution approach, and who approves contractual, financial, security or legal exposure.
Example
Use a four-part decision record. First, state the **problem and evidence**: what job the user is trying to complete, what has actually been observed, and what is only a request or an interpretation. Second, list **options**: repair an existing flow, change guidance or policy, build a feature, or take no immediate action. Third, mark **decision boundaries**: what the product role may approve and what requires another accountable owner. Fourth, name the **next signal** that would cause the team to continue or change course. This record stops a priority label from silently becoming a promise about a solution or date.
Consider the sales promise. The product serves 800 active organizations. This customer accounts for 12% of annual revenue, but only three of 30 interviewed users requested file export, and all three work for that organization. Support records show 18 organizations having difficulty sharing reports; 13 of them use the existing share link, but recipients sometimes see an old version. Export may be the customer's suggested solution to a wider problem: reliable access to the latest report. The sample does not prove that all 18 organizations need export, and the customer's commercial importance is not irrelevant. Set up two lines of inquiry: interview users across organizations about the sharing task, and diagnose why the current link displays an old version. Repairing a stale cache might help many users at lower cost. If the customer also has a documented need for a downloadable internal archive, export remains a separate option with security and operational consequences.
The worked decision is neither an instant rejection nor an instant feature commitment. The product manager gives sales a precise response: we will investigate the sharing task this week and return with an option and a time range after the team estimates it; we cannot confirm the feature today. Engineering diagnoses the old-version defect and estimates export. Design tests whether people understand the distinction between a live link and a static file. The earlier commercial promise is escalated to the contract or account owner because it may require customer relationship repair. The product manager can recommend product priority within delegated authority, but cannot unilaterally rewrite a contract.
What would make this a sound decision? Review three layers: was the problem expressed as the user's task, were observations kept separate from hypotheses, and does each party know what they will decide and when? The deliverable one week later is not a meeting count. It is a short record of the link defect, evidence from varied users, options with consequences and risks, and either a justified decision or a specific unknown blocking it. If fixing the link reduces “old version” support tickets but does not improve report sharing, reopen the access hypothesis instead of declaring product success because tickets closed.
Accountability for a decision is different from doing everyone else's work. Ask engineering for the consequences of export, not only a number of days: could the file include data a recipient should not see, can access be revoked after download, and who maintains the capability? Ask design to examine the user's task and the confusion between a live link and a static copy, rather than prescribing a button color. Each discipline contributes its expertise to a shared decision. When evidence conflicts, record the disagreement and the experiment or escalation that can resolve it; job titles are not a substitute for evidence.
Priority can change while the original user problem stays the same. Suppose engineering finds that the share link might expose one organization's data to another. Containing that risk becomes an urgent security and operations response, outside ordinary feature ranking. If instead the defect merely shows a copy five minutes old in a noncritical workflow, its repair can be compared with other work using user impact and effort. These are not fixed severity grades. The point is that the nature of a risk can change both the accountable decision maker and the order of action. A useful decision record captures why the course changed so the team can later explain why the first promise was not fulfilled literally.
Exercise
An appointment app receives an executive request for a new screen listing every appointment. Support sees 40 monthly tickets about late reminders. Engineering reports that the message service fails on 8% of attempts. Draft a four-part initial decision and distinguish what you can decide from what you must escalate.
Check your answer The observed problem is late or missing reminders; the new screen is a solution hypothesis. Options include repairing send failures, improving retries, or adding a monitoring view if evidence shows users need manual oversight. The team first needs a definition of “late,” total appointment volume, and failures by channel. The product manager can prioritize diagnosis with the team and recommend repair. Contractual promises about message arrival and privacy implications of an all-appointments screen go to their accountable owners. The next deliverable is a report on send success, delivery time and support tickets after the change, not a count of screens shipped.
