Why Smart PMs Leave 20% Gaps: Using 60% Effort to Capture 80% Value

1. The Perfectionism Trap for Junior PMs

New product managers often receive a requirement and immediately start enumerating every possible scenario—normal flow, exception flow, boundary conditions, permission overlaps, data inconsistencies—leading to anxiety about uncovered cases. They then overload the PRD with countless logic branches, creating a novel‑length document that appears thorough but consumes excessive development, testing, and schedule resources.

A concrete example involves a junior PM tasked with designing multi‑unit conversion for a SaaS ERP system. After two weeks of work, the PM produced a complex logic diagram covering fixed conversion (1 box = 20 pieces), floating conversion (1 roll ≈ 5.3 m), multi‑level cascading, warehouse‑specific ratios, and automatic historical recalculation.

When asked whether the logic truly covered all cases, the PM investigated 20 typical customers. Over 80% of them only used the fixed conversion (1 box = 12 pieces) in procurement, sales, and inventory, never needing cascading or warehouse‑specific rules. The floating conversion and historical recalculation were rarely understood.

Consequently, the team delivered only the fixed‑conversion solution in two weeks. Within three months no customer complained about missing floating conversion, while the full “perfect” solution would have required two months—time that could have been spent on higher‑value features such as batch tracking and cost‑profit analysis.

2. Prioritizing ROI

A mature PM uses a simple formula: Requirement Value = (User Coverage × Problem Severity × Usage Frequency) / Implementation Cost . Most SaaS ERP usage follows a power‑law distribution: 20% of core scenarios generate 80% of value, while the remaining 80% of edge scenarios contribute only 20% of value. Investing more than 20% of resources to cover that 20% of value is a net loss.

When faced with an edge request, a seasoned PM follows three steps:

Ask for data : How many tenants have encountered the scenario? How often does it occur? Which roles are affected? If data is unavailable, assume low frequency and validate with telemetry after release.

Ask for cost : What development, testing, implementation, and documentation effort is required? Does it block higher‑priority work or introduce hidden coupling risks?

Ask for alternatives : Can configuration, manual back‑office actions, or documentation address the need? Should the feature be deferred until a threshold of complaints (e.g., five per month) is reached?

If the answers indicate high cost, low benefit, and viable alternatives, the PM places the request in a "freeze" pool instead of forcing it into the current release.

3. What Does “60% Solves 80%” Mean?

The phrase refers to delivering a lightweight solution that covers the mainstream business scenarios, thereby satisfying the majority of customers, while postponing long‑tail, low‑frequency, or high‑cost edge cases.

For example, batch importing product data can be split into:

Mainstream scenario (≈80% of customers) : Import from an Excel file, validate required fields, provide error‑line feedback and an error‑report download. Estimated effort: 5 person‑days.

Edge scenario (≈20% of customers) : Support multiple sheets, custom field mapping, automatic category creation, incremental update modes, rollback mechanisms. Estimated effort: over 20 person‑days.

The team implements the mainstream version first; after launch, 80% of customers can import successfully, and the frozen edge requests are revisited only when justified by demand.

4. How to Freeze Requirements: A Practical Guide

1. Build a Requirement Scoring Card

Score each scenario on four dimensions (1–5): user impact, problem severity, usage frequency, and implementation cost. Compute a composite score (average of the first three divided by the cost score). Scenarios with a composite score below 0.6 become freeze candidates.

2. Record Freeze Conditions in the PRD

Mark frozen scenarios in the requirement pool and explicitly note “temporarily not supported” in the PRD rules, so developers know it’s intentional, testers know what to skip, and sales can explain to customers.

3. Provide Low‑Cost Fallbacks

Clear UI prompts and help‑document links explaining the unsupported operation and suggesting a standard workflow.

Manual back‑office or support‑team intervention via a hidden operation or ticket system.

Telemetry to track how often the frozen scenario is triggered; if usage exceeds expectations, the feature can be unfrozen early.

4. Regularly Review the Freeze List

Every two to three releases, conduct a “freeze‑room cleanup” to reassess customer needs, payment willingness, and competitor changes. Scenarios once deemed low‑value may become key differentiators later.

5. Mindset Shift: From Fear of Challenge to Proactive Trade‑offs

Many PMs avoid trade‑offs because they fear being challenged by developers, managers, or sales. The underlying assumption is that a PM must be responsible for every possible case. A mature PM recognizes that SaaS products operate under resource constraints and that strategic prioritization, not exhaustive coverage, delivers real value.

When explaining a frozen decision, a PM can say:

To developers: “The edge case occurs in less than 1% of usage and would add two weeks of work. If complaints exceed expectations after launch, we’ll address it immediately.”

To the boss: “Competitors built this for large‑enterprise customizations. Our current focus is on the common pain points of SMBs, so we’ll consider it for V2.0.”

To sales: “Tell the customer our main solution solves 80% of their needs; the remaining 20% can be handled via configuration or a paid custom request.”

The key is to show that the decision is a data‑driven prioritization, not laziness.

6. When Full Design Is Still Required

Some scenarios, despite low usage, must be built completely because they touch core system architecture. The article lists four such cases, illustrated with a multi‑currency ERP example: 80% of customers use only RMB, but the remaining 20% need USD/EUR. Currency handling is a financial foundation; partial implementation would require extensive changes across procurement, inventory, accounting, and reporting later, incurring higher total cost. Therefore, the full robust design is justified.

7. Real Case: Two‑Layer Decision for Multi‑Unit Conversion

Layer 1 – Coverage Decision : Mainstream (80% of customers) need fixed conversion (1 box = 12 pieces) in procurement, sales, and inventory. Edge (20%) need floating conversion, multi‑level cascading, or warehouse‑specific ratios. The PM chooses only the fixed conversion, freezing the edge cases.

Layer 2 – Robust Design : The fixed conversion model must be extensible, precise, and immutable for historical data. The design includes a “conversion type” field (fixed/float/warehouse), high‑precision decimal rates with rounding rules, and a policy that conversion rates cannot be altered once used.

Result: After one year, 80% of customers were satisfied. When a large client later demanded floating conversion, the pre‑designed extensibility reduced the implementation from an estimated three months to three weeks.

8. Summary

Product managers evolve from feature designers to resource allocators and finally to architects of trade‑offs. They must distinguish between “feature coverage” (which can be narrowed) and “design robustness” (which must remain solid). By freezing low‑impact edge scenarios, applying a 60 % effort to capture 80 % of value, and insisting on 100 % rigor for core capabilities, PMs deliver higher‑value products without unnecessary waste.