How to Identify Conflicting Assumptions Across a Product Portfolio

What Makes Product Assumptions Conflict?

Product assumptions conflict when two plans depend on beliefs that cannot both hold for the same customer, workflow, conditions, and period. To identify the conflict, make each belief explicit, compare its scope and supporting evidence, and name the decision that would change if it were wrong.

Across a product portfolio, teams may use similar words while planning around different realities. One assumes headquarters approves every replenishment change. Another assumes store managers can make those same changes without approval. If both plans target the same account and workflow, that difference needs investigation before either becomes a commitment.

Different beliefs can also be justified. Centralized retail chains and independent store groups may have different decision rights. The review must establish whether the context matches before treating the difference as a contradiction.

Put the Assumptions in Comparable Terms

Start with the products affected by an upcoming commitment: a shared launch, a combined offer, a major integration, or an investment review. Collect the beliefs those plans depend on. You do not need to compare every assumption in every product.

An assumption register can supply the original statements, owners, evidence, and review history. Where the belief exists only in a roadmap or discussion, ask the team to state what must be true for its plan to work.

Preserve the original wording, then clarify:

• Who: the user, buyer, approver, and customer segment.
• What: the behavior, authority, willingness to pay, or technical condition being assumed.
• Where and when: the account, workflow, environment, and relevant period.
• Dependency: which product decision relies on the belief.

“Managers want more control” is too broad to compare. “Store managers in the proposed pilot can change replenishment quantities without headquarters approval” identifies something the team can investigate.

Strategyzer’s guidance on formulating strong hypotheses recommends statements that are testable, precise, and discrete. The review steps below are our recommended way to apply that discipline across products.

Split statements containing several claims. A team might believe users can approve a change, want to approve it, and will pay for the ability. Those claims need different evidence. Agreement about authority does not establish demand or willingness to pay.

Check Whether the Evidence Travels Across Products

Once the statements are comparable, examine the evidence behind them. A well-supported belief in one context can become a weak assumption when carried into another.

For each source, check the customer segment, research question, observation date, and conditions. Ask whether the evidence concerns the same behavior as the claim. A buyer requesting centralized reporting does not establish who can authorize an operational change.

Separate what was observed from the team's interpretation. “A store manager submitted a change request” leaves several possibilities: the manager could approve it, could recommend it, or needed someone else's permission. Keep those possibilities open until the source resolves them.

Also trace evidence back to its origin. A sales presentation, research summary, and strategy document may all cite the same customer conversation. They provide three references to one observation, not three independent confirmations.

Record contrary findings and gaps alongside supporting material. When customer policies or workflows have changed, explain why an older observation still applies or mark that applicability as uncertain.

Bring the affected teams into the review while their evidence can still change the plan. The working practices in this guide to shared context and product-team decisions help make that discussion concrete. Include only material the reviewers are authorized to access; portfolio oversight does not automatically provide access to every team's research.

Classify the Difference Before Acting

Use a provisional classification to choose the next action. A disagreement does not always require an experiment, and an overlap does not always require consolidation.

Overlapping propositions deserve particular care. Two products serving the same buyer may form a useful combined offer. But if both revenue plans assume customers will replace the same existing tool with a separate full-price purchase, the combined business case needs closer examination. Shared customers alone do not establish either synergy or cannibalization.

Prioritize differences by their consequences and the evidence available. Assumption mapping can help select important beliefs with weak support for further investigation. A minor wording difference can wait; an unresolved belief behind a costly commitment may need attention now.

Worked Example: Who Can Change a Store's Order?

The following example is fictional.

Two teams are preparing a combined pilot for a regional retail chain:

• Inventory Analytics assumes headquarters must approve every change to a store's replenishment quantities.
• Store Planning assumes store managers can apply those changes immediately, without headquarters approval.

Inventory Analytics cites interviews with centralized chains. Store Planning cites pilots with autonomous store groups. Both teams have relevant experience, but neither source establishes the authority model at the proposed shared customer.

At portfolio level, the initial finding is a difference between customer contexts. At the shared-pilot level, the planned workflows are incompatible: one requires an approval step that the other omits. Neither team's existing evidence resolves which workflow the new customer needs.

The consequence is specific. The combined pilot could promise immediate changes while the customer's operating process requires approval. That could alter the user flow, integration scope, and pilot commitment.

The teams agree to check the disputed condition with both headquarters and store users. They will walk through a recent replenishment change, identify who requested and approved it, and inspect the approval policy where available. They will also check exceptions: authority may differ for routine adjustments, large changes, or particular stores.

The possible findings lead to different plans:

• If headquarters approval is required, revise the immediate-change workflow and review the pilot scope.
• If managers have delegated authority, narrow the headquarters assumption to the cases where it applies.
• If authority varies by threshold or store, represent those conditions explicitly before agreeing to a common workflow.

Until the check is complete, the pilot owner keeps the approval-dependent promise open. Work that does not depend on that promise can continue.

Give the Review an Owner and a Decision

Assign someone to investigate the evidence and someone with authority to resolve the affected commitment. Those may be different people. The researcher or product manager can clarify customer behavior; the person accountable for the combined pilot must decide what the organization can promise.

When the evidence remains weak, choose an action that reflects the exposure. You might limit a pilot, defer a dependent feature, test one workflow, or continue with a documented assumption and a review trigger. Consider limiting the affected commitment before pausing an entire product. Portfolio visibility in Prodstack can keep each affected product’s stage and risks in one view while the review runs.

Document the evidence that would change the decision before collecting it. In the retail example, confirming approval requirements and exceptions would change the proposed workflow. Another general conversation about whether managers like autonomy would leave the central question unanswered.

If the teams cannot agree on the next action, escalate the concrete tradeoff: the commitment at risk, the cost of waiting, and the uncertainty being accepted. Do not resolve a factual disagreement by counting votes.

A Record for the Next Cross-Product Review

Copy this record and replace the example entries. Link back to each team's original assumption so the portfolio review supplements the source records instead of silently rewriting them.

After the decision, update the affected assumptions and commitments in their original locations. Keep the earlier rationale available and record what changed. Reopen the comparison when a new segment, policy, or workflow makes the old conclusion uncertain again.