Product Management Context: Diagnose the Work Before Choosing the Method

Two product managers can share a title and have almost no important work in common.

One must learn whether a problem is real before money runs out. Another must change a mature service without breaking contractual workflows. A third must align two sides of a marketplace that cannot create value independently.

The difference is not personality, seniority, or allegiance to a product method. It is context.

Context diagnosis asks a practical question: what kind of product judgement does this situation require now?

The answer should change the evidence, cadence, planning horizon, collaborators, controls, and decisions the product manager uses. If it changes only the vocabulary, the diagnosis has done no work.

Write the context brief before choosing the method

Create a one-page brief for the product area, not for the person holding the role.

Decision horizon
Primary uncertainty
Product phase and current transition
Value and business model
Material risks and reversibility
Decision rights and escalation boundaries
Critical dependencies
Evidence available now
Condition that would change this brief

Write claims, not labels.

“Early stage” is a label. “We have repeated evidence of the workflow problem, but do not know whether teams will replace the current manual review” describes the uncertainty that should shape work.

“Enterprise” is a label. “The user cannot purchase, the buyer does not operate the product, and security approval precedes implementation” describes an adoption system.

The brief is not a product strategy. Product Strategy makes the choices about challenge, arena, advantage, capabilities, economics, and refusal.

The context brief identifies how those choices can be made and executed responsibly in the current conditions.

Axis one: locate the uncertainty

Uncertainty is not one confidence score.

Name the claim that controls the next consequential commitment:

• problem: whether the situation exists, matters, and deserves change;

• behaviour: whether people will adopt a different action or workflow;

• solution: whether the product can create the intended change in real use;

• route: whether the relevant actors can discover, evaluate, approve, and implement it;

• economics: whether value can be created and captured under a viable exchange;

• operations: whether the organisation can deliver, govern, and support the promise;

• environment: whether regulation, technology, competition, or dependencies will remain stable enough for the choice.

Several may be uncertain. Select the one that makes the next commitment irresponsible if left unresolved.

Duncan studied 22 decision groups in three manufacturing and three research-and-development organisations.[1]

The study separated environmental complexity from dynamism and reported the greatest perceived uncertainty in dynamic, complex settings.

It is a 1972 study of organisational decision units, not software product teams. Its measures and settings do not validate this context brief.

Its useful warning is that the number of relevant factors and the rate at which they change are different problems.

A complex but stable domain may reward deep modelling and reliable interfaces. A simpler but fast-changing market may demand shorter evidence cycles and more reopenable decisions.

Axis two: name the product phase without assuming a ladder

Phase describes the current decision problem, not the age of the company.

A mature organisation can be searching inside a new domain. A young company can operate a stable, regulated service. One product can be scaling while a legacy component is retiring.

Use five working states:

• search: the problem, mechanism, or route remains materially uncertain;

• establish: a valuable pattern exists, but repeatability and operating boundaries are unresolved;

• scale: variance, capacity, coordination, and economics now constrain growth;

• renew: a working system must change while old commitments remain active;

• retire: value has moved elsewhere, but migration, records, contracts, and customer obligations still require ownership.

These states are an editorial device, not a universal lifecycle model.

Anderson and Tushman analysed technological change across the cement, glass, and minicomputer industries over long historical periods.[2]

Their model describes eras of variation after discontinuities, selection around a dominant design, and later incremental progress.

The research concerns industry-level technology cycles in three manufacturing-oriented settings. It does not say that a digital product follows one sequence or prescribe PM practice.

It does show why phase deserves attention. The valuable decision during variation differs from the valuable decision after a design and operating pattern have stabilised.

Product Lifecycle Decisions covers the deeper diagnosis of trajectory, evidence, and transition. Here, phase is one input into the kind of product work required.

Axis three: expose the value and business model

The same interface can sit inside very different systems of value.

For a direct subscription, the team may need to connect user value, buyer willingness, retention, support cost, and renewal.

For usage pricing, metering, predictability, customer control, and marginal cost become product concerns.

For an internal product, adoption can be mandated while value remains unproven. The PM must separate compliance from useful use and make the service obligation explicit.

For a public service, entitlement, accessibility, policy intent, and accountability may matter more than commercial acquisition.

For a platform, one group may receive value only when another participates. Product work must consider rules, incentives, access, and value across sides rather than optimise one funnel in isolation.

Rochet and Tirole’s 2003 paper builds an economic model of competition in two-sided markets and examines price allocation under different governance structures.[3]

It is theory, not a study of product teams or evidence that every marketplace should subsidise one side.

Its bounded contribution is structural: when participation on one side affects value on another, pricing and adoption decisions cannot be read as a single-customer exchange.

Business Model Design covers how value creation, delivery, and capture fit together. The context brief records which model currently constrains PM work.

Axis four: make risk change the operating method

Risk is not a line added after the product plan.

Describe it across five properties:

• severity if the decision is wrong;

• population and duration of exposure;

• reversibility of the product and customer consequence;

• ability to detect harm before it spreads;

• ability to recover people, data, money, access, or trust.

A low-severity, reversible preference can use broad delegation and rapid exposure.

A decision affecting employment, credit, health, safety, legal status, privacy, or essential access may require qualified expertise, stronger evidence, constrained rollout, auditability, and accountable risk acceptance.

Higher control does not mean slower ceremony by default. It means the evidence and authority must match the consequence.

Do not call a decision reversible because code can be rolled back. A changed customer action, disclosed record, denied entitlement, or lost trust may persist after the software returns to its previous state.

Axis five: state the real decision rights

Autonomy is not a cultural adjective. It is authority over named decisions within stated boundaries.

For the product area, separate:

• who frames and recommends;

• who can commit product scope or policy;

• who allocates people or budget;

• who accepts operational, legal, security, or ethical risk;

• who can stop release or reverse the decision;

• who owns the consequence after launch.

GOV.UK’s governance guidance says service teams should know that they have decision authority, understand its boundaries, and know who is accountable outside them.[4]

This is public-service practitioner guidance, not comparative research showing that its governance model improves product outcomes.

Its useful standard is legibility. Telling a team to “own the outcome” while retaining every material decision elsewhere changes the PM’s job into negotiation and escalation.

Product Org Design addresses the wider system of ownership and dependencies. A context brief does not redesign that system; it makes the local authority condition impossible to ignore.

Translate context into a way of working

Do not end with five axis labels. Convert them into operating consequences.

Context question	Consequence for product work
What is most uncertain?	Evidence to collect and commitment to delay
Which phase is active?	Planning horizon, cadence, and definition of progress
How is value exchanged?	Actors, economics, obligations, and metrics to connect
What harm is possible?	Expertise, safeguards, rollout, and risk authority
Who can decide?	Forum, recommendation, escalation, and ownership after release

Then specify:

Evidence cadence

Search may require frequent contact with users and short decision cycles. Scale may require cohort, reliability, capacity, and evidence about unit economics over longer periods.

Renewal may need both: fast learning about the replacement and slow evidence about migration risk.

Planning horizon

Use the shortest horizon that still captures the consequence.

A reversible interface test may be governed by the next evidence point. A contract migration needs a horizon long enough to include notice, implementation, support, and rollback obligations.

Product artefacts

Use artefacts that carry the decision.

A problem frame, prototype, service blueprint, pricing contract, risk case, migration ledger, or operating policy can each be useful. None is mandatory because a job description says so.

Collaboration pattern

Bring in the people who hold evidence, authority, expertise, or consequences for the active decision.

Do not make every function a standing approver. Do not exclude a specialist because the team wants to appear autonomous.

Definition of progress

In search, progress may be a claim narrowed enough to reject a direction. In scale, it may be reduced variance without damaged customer outcomes.

In retirement, progress may be obligations closed and customers moved safely. Shipping volume cannot represent all three.

One capability, two hypothetical contexts

Consider an invented capability that automatically matches supplier invoices with purchase records. No company, result, or customer outcome is implied.

Context A: a new self-serve product

The target user and workflow are plausible, but repeated use is unproven. The product is in search, uses a direct subscription, and exposes a small set of volunteer test accounts.

The team can decide product behaviour within agreed data rules. Matching suggestions are reversible because a person must confirm them before any accounting action.

The PM work concentrates on observing the workflow, testing whether suggestions reduce a real decision burden, defining trustworthy explanations, and learning whether useful use persists.

Context B: a mature enterprise service

The same capability enters an established system used during financial close. Buyers, operators, auditors, and administrators are different actors.

Contracts define retention and support. A wrong match can enter an approval chain, and model or rule changes require accountable review. Release authority is shared with finance operations and security.

The PM work concentrates on authority boundaries, representative test cases, audit records, exception handling, migration, service readiness, and evidence across customer cohorts.

The interface may look similar. The required product management is not.

The example does not prove that either operating model succeeds. It demonstrates how the axes change the work without assigning a personality type to the PM.

Review the brief when the context moves

A context brief expires. Set triggers rather than a ceremonial annual refresh.

Review it when:

• the primary uncertainty receives credible evidence;

• the product moves from search to repeatable operation or from scale to renewal;

• the buyer, user, payer, beneficiary, or route changes;

• exposure grows to a new population or consequence;

• regulation, technology, or a critical dependency changes;

• decision authority moves without the accountability moving with it;

• the current method keeps producing work that cannot be used.

Do not ask whether the PM has become a “growth PM”, “platform PM”, or “execution PM”. Those labels can describe experience, but they often hide the decisions and constraints that matter now.

Ask which judgement the context requires, which evidence can support it, and which authority can turn it into action.

Sources

1. Duncan: Characteristics of Organizational Environments and Perceived Environmental Uncertainty (1972 study of 22 decision groups in three manufacturing and three R&D organisations; based on perceived uncertainty and not a product-team context model)

2. Anderson and Tushman: Technological Discontinuities and Dominant Designs (longitudinal analysis of three industrial technology histories; not a universal digital-product lifecycle or PM method)

3. Rochet and Tirole: Platform Competition in Two-Sided Markets (theoretical economic model of two-sided platform competition; not an empirical product-management playbook)

4. GOV.UK: Governance Principles for Agile Service Delivery (official UK public-service guidance on authority and governance; not comparative evidence of product outcomes)

Read next

• Product Strategy: Build a Coherent Choice System

• Product Org Design: Build the Decision System, Not the Chart

• Product Lifecycle Decisions: Diagnose the Trajectory Before Choosing the Strategy

• The Strategic Power of Business Model Design