Identifying Minimum Lovable Requirements by Working Backwards from Launch
This skill teaches you how to decompose a finished press release's customer promises into the smallest possible set of technology, infrastructure, and features needed to deliver on those promises at launch, giving your product manager roadmap clarity and defensibility.
Start from your press release's promised customer experience and trace each benefit back to the features and infrastructure required to deliver it. Score each requirement against the customer promise, remove anything that does not directly enable a stated benefit, and you will have the minimum set of requirements for a viable launch.
Outcome: You produce a prioritized, traceable requirements list where every item links directly to a customer benefit stated in the press release, with all non-essential scope explicitly removed and documented.
Prerequisites
- A completed or near-final internal press release (PR/FAQ) for the product concept
- Familiarity with the Working Backwards framework and PR/FAQ structure
- Basic understanding of system architecture or access to an engineering partner who can estimate technical feasibility
- Stakeholder alignment on the target customer and their core problem
Overview
Every product team faces the same gravitational pull: scope creep. Features get added because they seem clever, because a stakeholder requested them, or because a competitor shipped something similar. The result is a bloated product manager roadmap that delays launch, dilutes focus, and confuses customers. Identifying minimum lovable requirements is the discipline of resisting that pull by anchoring every requirement to a specific customer promise you have already articulated in writing.
Inside the Working Backwards framework, this skill sits at the transition between narrative and execution. You have written an internal press release that describes the finished customer experience. You have drafted the FAQ section that pressure-tests feasibility and business viability. Now you need to convert that narrative into a concrete list of things to build. The operative word is "minimum." You are not building a feature list by brainstorming what could exist. You are tracing backwards from each sentence in your press release and asking: what is the smallest set of capabilities that makes this sentence true for a real customer on launch day?
The artifact this skill produces is a requirements traceability matrix: a table where each row is a requirement, each requirement maps to one or more press release promises, and each requirement carries a verdict of "must have for launch," "improves but not essential," or "post-launch." This matrix becomes the backbone of your product manager roadmap. It gives engineers clarity on what to build first, gives designers clarity on which flows to polish, and gives leadership confidence that scope decisions are anchored to customer outcomes rather than opinion. When stakeholders propose additions, you point to the matrix and ask a simple question: which press release promise does this enable? If the answer is none, the feature waits.
Done well, this skill collapses months of scope negotiation into a few focused sessions. Done poorly, it produces a list that looks minimal on paper but smuggles in hidden complexity through vague requirements like "seamless onboarding" or "fast performance." The steps below teach you how to be precise enough to avoid that trap.
How It Works
The core insight behind this skill is that a well-written press release is already a specification, just written in customer language instead of engineering language. Every benefit sentence in the press release implies a technical capability. "Customers can see their delivery status in real time" implies a tracking system, a data pipeline with low latency, and a user interface that surfaces that data. The skill works by systematically extracting those implications, making them explicit, and then challenging each one: is this the simplest way to deliver the promise, or are we gold-plating?
The mental model is a dependency tree rooted in customer outcomes. At the top sit the 3-5 customer benefits from your press release. Each benefit branches into the capabilities needed to deliver it. Each capability branches into the technical components required. You prune the tree from the leaves upward. If a technical component supports only capabilities that are not required for launch-day promises, you cut it. If two capabilities could be delivered by one simpler component, you merge them. The goal is the smallest tree that still connects every root benefit to at least one viable implementation path.
This approach works because it externalizes trade-off decisions. Without the tree, scope debates become political: the loudest voice or the most senior person wins. With the tree, the debate becomes structural. You can see that removing a component disconnects a benefit, or that adding a component connects to nothing. The press release acts as a constitution: you can amend it through the PR/FAQ iteration process, but you cannot silently ignore it.
The approach breaks down in two predictable ways. First, when the press release is vague. "Customers love using it" does not decompose into requirements. If you find yourself unable to extract concrete capabilities, your press release needs another revision, not more requirements brainstorming. Second, when teams conflate "minimum" with "minimal viable." Minimum lovable means the experience is genuinely good for the narrow set of things it does. It does not mean shipping a half-broken prototype. Every requirement that makes the cut should be built well. The discipline is in choosing fewer things, not in doing each thing cheaply.
Finally, understand that the requirements list is a living document. As you move through defining the customer experience and running PR/FAQ review sessions, new information will surface. The traceability matrix gives you a structured way to absorb that information: add a row, trace it to a promise, score it, and decide. Without the matrix, new information becomes new scope with no anchor.
Step-by-Step
Step 1: Extract Customer Promises from the Press Release
Open your finalized internal press release and highlight every sentence that describes a benefit the customer will experience. Ignore sentences about market size, company strategy, or internal goals. Focus exclusively on what the customer sees, feels, or achieves. Write each highlighted sentence on a separate row in a spreadsheet or document, numbering them sequentially.
Aim for 4-8 distinct promises. If you have more than 10, your press release is likely trying to do too much, and you should revisit it before continuing. If you have fewer than 3, the press release may be too abstract to decompose.
Tip: Read each promise aloud and ask: could a customer verify this on launch day? 'Saves time' is not verifiable. 'Reduces report creation from 2 hours to 10 minutes' is verifiable. Rewrite vague promises before proceeding.
Step 2: Decompose Each Promise into Required Capabilities
For each customer promise, brainstorm the capabilities the product must have to make that promise true. A capability is a thing the system does, not a thing it is. 'Full-text search across documents' is a capability. 'Modern architecture' is not.
Work through each promise independently, and do not worry about duplication across promises yet. ' Involve an engineering partner at this stage. Product managers often underestimate infrastructure requirements and overestimate feature requirements. An engineer will surface needs like authentication, data migration, and API rate limits that are invisible from the customer's perspective but essential to delivering the promise.
Tip: Ask your engineering partner: 'If I handed you this promise and nothing else, what would you need to build?' Their answer often reveals 2-3 foundational capabilities the product side overlooks.
Step 3: Consolidate and De-duplicate Capabilities
Review all capabilities across all promises and merge duplicates. Many promises share underlying capabilities. For example, 'displays delivery status' and 'sends status notifications' both require a status tracking system. Create a consolidated list where each capability appears once, with a column noting which promises it supports.
This is the beginning of your traceability matrix. Capabilities that support multiple promises are usually higher priority, because removing them breaks more of the customer experience. Flag these as foundational. Capabilities that support only one promise are candidates for closer scrutiny in the next step.
Tip: If a single capability supports all of your promises, it is almost certainly a platform-level concern like authentication, data storage, or the core data model. Treat these as non-negotiable infrastructure.
Step 4: Challenge Each Capability with the 'Simplest Version' Test
For every capability on your consolidated list, ask: what is the absolute simplest version of this that would still make the customer promise true? Write the simplified version next to the original. ' The simplified version is your launch candidate. The original becomes a post-launch enhancement.
Be ruthless here. The goal is not to plan the best possible product. The goal is to plan the smallest product that delivers on your press release promises. If a simplified capability still makes the promise true, use the simplified version.
Tip: Apply the 'launch day demo' test: if you were showing the product to a customer on launch day, would the simplified version embarrass you? If yes, you have cut too deep. If no, ship the simplified version.
Step 5: Identify Hidden Dependencies and Infrastructure
Review your simplified capabilities list with engineering and identify non-obvious dependencies. Every user-facing capability depends on infrastructure: hosting, CI/CD, monitoring, logging, security, data backup, compliance requirements. These are not features customers see, but removing them makes the product unsafe or unreliable. List infrastructure requirements separately and trace each one to the capabilities it enables.
Do not skip this step. Teams that scope only user-facing features routinely underestimate launch timelines by 30-50% because they discover infrastructure needs mid-build. Common hidden dependencies include: third-party API integrations, payment processing setup, GDPR or SOC2 compliance work, load testing, and data migration from beta or legacy systems.
Tip: Ask engineering: 'What would keep you up at night if we launched without it?' This question surfaces the infrastructure items that engineers consider non-negotiable but product managers might classify as 'nice to have.'
Step 6: Score and Classify Every Requirement
Assign each requirement, both capabilities and infrastructure, to one of three categories. 'Must have for launch' means the product cannot deliver its press release promises without this item. 'Improves but not essential' means the customer experience would be better with it, but the core promise still holds without it. 'Post-launch' means this is valuable but not tied to any launch-day promise.
Score independently first: have each team member classify requirements on their own before discussing as a group. This prevents anchoring, where a senior person's opinion dominates. Then discuss disagreements. When people disagree, return to the press release text.
Read the relevant promise aloud and ask: does removing this requirement make that sentence false? If yes, it is a must-have. If the answer is 'it makes it worse but not false,' it is an improves-not-essential.
Tip: Limit 'must have for launch' to no more than 60% of your total requirements. If everything is a must-have, you have not actually prioritized. Force yourself to cut.
Step 7: Validate the 'Must Have' List Against Timeline and Resources
Take your must-have list to engineering for a rough effort estimate. You are not asking for a detailed project plan. You are asking: given our team size and target launch date, can we build these must-haves? If the answer is yes with reasonable confidence, you have a viable scope.
If the answer is no, you need to return to Step 4 and simplify further, or return to the press release and reduce the number of promises. This is the moment where the Working Backwards process reveals its power. You are not cutting features arbitrarily. You are making a deliberate decision about which customer promises to keep and which to defer, with full visibility into the trade-offs.
Document what you cut and why, because this becomes input for your post-launch product manager roadmap.
Tip: If engineering says the must-have list is 'tight but possible,' treat that as a no. Teams consistently underestimate by 20-40%. Either simplify capabilities further or extend the timeline.
Step 8: Document the Requirements Traceability Matrix
Compile your final artifact: a matrix with columns for requirement ID, requirement description, simplified version, customer promise(s) supported, classification (must-have, improves, post-launch), estimated effort, and any open questions. Share this matrix with all stakeholders. It replaces the ambiguous 'feature list' with a traceable, defensible scope document. Every future scope discussion should reference this matrix.
When someone proposes a new feature, add a row, trace it to a promise, classify it, and decide. The matrix also feeds directly into sprint planning, design briefs, and technical architecture documents.
Tip: Store the matrix in a shared, version-controlled location, not a slide deck. You will update it frequently, and you need a clear history of what changed and why.
Examples
Example: B2B SaaS Expense Reporting Tool (Small Team, 4 Engineers)
A startup team of 4 engineers and 1 PM is building an expense reporting tool for small businesses. Their press release promises three things: employees can submit expenses from their phone in under 60 seconds, managers can approve expenses with one tap, and finance teams get a monthly summary report automatically. The team has 10 weeks to launch an MVP. They are tempted to also build integrations with QuickBooks and Xero, receipt OCR, and a multi-currency converter.
The PM extracts the three promises and decomposes each. 'Submit in under 60 seconds' requires a mobile-responsive form, photo upload for receipts, and category selection. 'Approve with one tap' requires a manager dashboard, push notifications, and an approval workflow. 'Monthly summary report' requires a reporting engine, date-range filtering, and PDF or CSV export.
Consolidation reveals that both submission and approval share user authentication and a core expense data model. The PM then applies the simplest-version test: receipt OCR is replaced with manual entry plus photo attachment, multi-currency is deferred since all initial customers use USD, and the monthly report starts as a CSV export rather than a designed PDF. QuickBooks and Xero integrations are classified as post-launch because they do not appear in any press release promise. The final must-have list contains 11 items.
Engineering estimates 8 weeks, leaving 2 weeks of buffer. The PM documents QuickBooks integration, OCR, and multi-currency as the first three items on the post-launch product manager roadmap, each traced to a future promise that could be added to a v2 press release.
Example: Consumer Fitness App (Growth-Stage, 12 Engineers)
A growth-stage company with 12 engineers is launching a new feature: AI-generated personalized workout plans. The press release promises that users receive a customized weekly plan based on their fitness level and equipment, can swap exercises they dislike, and see progress tracking over time. The CEO also wants a social sharing feature and integration with Apple Health. Launch target is 6 weeks.
The PM extracts three promises and decomposes. 'Customized weekly plan' requires a fitness assessment questionnaire, an exercise database tagged by muscle group and equipment, and an algorithm that assembles plans. 'Swap exercises' requires alternative exercise recommendations and UI for swapping within a plan. 'Progress tracking' requires workout logging and a simple chart showing completed workouts over time.
The simplest-version test simplifies the algorithm from a complex ML model to a rule-based engine with 4 fitness levels and 3 equipment categories, producing 12 plan templates that cover the matrix. Swap recommendations come from the exercise database's tags rather than a recommendation engine. Progress tracking starts as a weekly completion percentage rather than a detailed analytics dashboard. Social sharing and Apple Health integration are classified as post-launch because neither appears in the press release promises.
Engineering estimates 5 weeks for the simplified scope. The PM documents the ML-based personalization upgrade as a v2 initiative, with the rule-based engine designed to be replaceable once user data validates demand.
Example: B2B Marketplace Platform (Large Team, Cross-Functional)
A large team across product, engineering, design, and data science is building a marketplace connecting manufacturers with distributors. The press release promises: distributors can discover manufacturers filtered by product category, location, and minimum order quantity; manufacturers can list their catalog with pricing in under 30 minutes; and both sides get a secure messaging channel to negotiate terms. The project has a 16-week timeline with 20 engineers.
The PM extracts three promises and runs decomposition workshops with engineering, design, and data science leads. 'Discover manufacturers' requires a search index, filter UI, manufacturer profile pages, and a data ingestion pipeline for manufacturer listings. 'List catalog in 30 minutes' requires a self-serve onboarding flow, a bulk CSV upload for products, and a pricing entry form. 'Secure messaging' requires a real-time messaging system, notification delivery, and content moderation for spam.
Consolidation reveals shared needs: user authentication, manufacturer and distributor account models, and an admin dashboard for the operations team. The simplest-version test challenges several gold-plated capabilities. Real-time messaging simplifies to near-real-time (30-second polling instead of WebSockets), which cuts 3 weeks of infrastructure work. The search index uses a managed service instead of a custom-built solution.
Bulk CSV upload supports a single template format rather than flexible schema detection. Content moderation starts as manual review by the ops team rather than automated ML filtering. The team initially proposed AI-powered manufacturer recommendations, advanced analytics dashboards for both sides, and a payment escrow system. All three are deferred because no press release promise requires them.
The final must-have list contains 24 items. Engineering estimates 14 weeks, leaving 2 weeks of buffer. The PM publishes the traceability matrix in Confluence and schedules weekly 15-minute reviews to absorb new information from the ongoing PR/FAQ review sessions.
Example: Internal Tool Rebuild (Enterprise, Tight Deadline)
An enterprise company needs to rebuild an aging internal CRM tool used by 200 sales reps. The press release (written for the internal customer: sales reps) promises: reps can log a customer interaction in under 15 seconds, reps see a unified timeline of all interactions with a customer, and managers get a weekly pipeline summary. The legacy system has 47 features accumulated over 8 years. The rebuild has a 12-week window before the legacy system's hosting contract expires.
The PM resists the urge to replicate all 47 features and instead anchors to the three promises. 'Log interaction in 15 seconds' requires a streamlined input form with pre-populated customer data, interaction type dropdown, and free-text notes. 'Unified timeline' requires a data model that aggregates interactions across channels (email, phone, in-person) and a chronological view. 'Weekly pipeline summary' requires a deal-stage tracking field on each customer record and an automated email report.
The simplest-version test reveals that 31 of the legacy system's 47 features do not map to any of the three promises. Features like territory mapping, commission calculation, and custom report building are classified as post-launch. The PM interviews 10 sales reps and confirms that the three promises match their top pain points. Data migration from the legacy system is flagged as critical infrastructure: only customer records and interaction history need to migrate for launch, not the full legacy schema.
The final must-have list contains 15 items versus the legacy system's 47 features. Engineering confirms 10 weeks of build time. The PM creates a phased product manager roadmap showing which of the remaining 31 legacy features will be re-evaluated in quarters 2 and 3, with each feature requiring a fresh justification tied to a customer promise before being approved.
Best Practices
Always decompose promises with an engineering partner present. Product managers tend to undercount infrastructure and overcount UI features. An engineer will surface authentication, data pipelines, and compliance requirements that are invisible from the customer side but constitute 30-40% of actual build effort. Skipping this produces a scope estimate that is dangerously optimistic.
Score requirements independently before group discussion. When team members share their classifications aloud, the first speaker anchors the room. Silent independent scoring produces honest disagreement, and disagreement is where the best scope decisions happen. If everyone agrees on everything, someone is not thinking critically.
Treat the press release as constitutional text during scoping sessions. When debates arise about whether a feature is essential, read the relevant press release sentence aloud. This shifts the conversation from opinion to evidence. If the press release does not mention the capability, the burden of proof is on the person advocating for it.
Limit your launch promises to 3-5. Products that try to deliver on 8-10 promises inevitably ship late or ship poorly. Fewer promises mean fewer requirements, faster development, and a more coherent customer experience. You can always add promises in subsequent releases.
Document every deferred requirement with its rationale and the promise it would support. This deferred list becomes the first draft of your post-launch product manager roadmap. Without documentation, deferred items either get forgotten or resurface months later without context, forcing you to re-evaluate from scratch.
Revisit the matrix after every PR/FAQ review session. New feedback from reviewers often changes the priority or feasibility of requirements. A matrix that is not updated after reviews becomes stale within a week. Assign one person to own matrix updates so changes do not fall through cracks.
Use the 'launch day demo' heuristic as a smell test. After completing the matrix, imagine walking a real customer through the product on launch day using only the must-have items. If the demo feels embarrassing, you have cut too deep. If the demo feels complete and coherent, you have scoped correctly. This gut check catches issues that the matrix alone might miss.
Common Mistakes
Starting requirements gathering before the press release is stable
Correction
If your press release is still changing significantly between reviews, any requirements you derive will also change. This creates rework and erodes team trust in the process. Wait until the press release has been through at least two review cycles with stakeholders and the core promises are stable. You can spot instability by checking whether the first paragraph and customer quotes have changed in the last revision.
If they have, the narrative is still shifting.
Writing requirements as solutions instead of capabilities
Correction
A requirement like 'build a Redis caching layer' prescribes a solution. The actual requirement is 'return search results within 200ms for the median query.' Solution-level requirements lock engineering into implementation choices before they have evaluated alternatives, and they obscure the connection to customer promises. When you catch yourself writing a technology name in a requirement, rewrite it as the capability the technology would provide. Let engineering choose the how.
Classifying everything as 'must have' because it all seems important
Correction
This happens when teams do not distinguish between 'the product would be better with this' and 'the product cannot deliver its promise without this.' The result is a must-have list so large it cannot ship on time. The diagnostic signal is a must-have list that exceeds 60% of total requirements. When you see this, return to the classification step and apply the deletion test more rigorously: remove the requirement, re-read the promise, and honestly assess whether the promise is still deliverable. If it is, the requirement is not a must-have.
Ignoring infrastructure and treating scope as purely feature-driven
Correction
Feature-only scoping causes teams to discover mid-sprint that they need authentication, monitoring, CI/CD, or compliance work they did not plan for. This is the most common source of timeline slippage in product launches. The fix is Step 5: explicitly surface infrastructure dependencies with engineering before finalizing scope. If your requirements matrix has zero infrastructure items, you have almost certainly missed something critical.
Using the matrix once and never updating it
Correction
The matrix loses value the moment it becomes a static snapshot. New information arrives continuously through customer research, technical spikes, and stakeholder feedback. Teams that treat the matrix as a living document make better scope decisions because they absorb new information structurally rather than reactively. Set a weekly 15-minute check-in to review whether any requirements have changed classification, and update the matrix before each sprint planning session.
Other Skills in This Method
Iterating PR/FAQ Documents Through Multiple Feedback Cycles
How to revise and strengthen a PR/FAQ document through successive rounds of leadership and cross-functional feedback, knowing when the document is ready to greenlight development.
Drafting the FAQ Section of a PR/FAQ Document
How to write both external (customer-facing) and internal (stakeholder-facing) FAQs that stress-test assumptions, address risks, and surface hard questions early in the product process.
Running PR/FAQ Review and Critique Sessions
How to facilitate Amazon-style narrative review meetings where stakeholders silently read the PR/FAQ document and then provide rigorous, structured feedback to sharpen the product concept.
Using Working Backwards Thinking in Product Manager Interviews
How to apply customer-obsessed, Working Backwards reasoning to answer product sense, strategy, and prioritization questions in product manager interviews.
Writing Internal Press Releases for Product Concepts
How to craft a compelling, customer-centric internal press release that articulates the product vision, target customer, problem, and solution before any development begins.
Defining the Desired Customer Experience Before Building
How to start from the ideal end-state customer experience and systematically work backwards to identify the features, services, and technology required to deliver it.
Frequently Asked Questions
How do I handle stakeholders who insist a feature is critical but it does not trace to any press release promise?
Ask the stakeholder which customer promise the feature enables. If they cannot point to one, offer two paths: either add a new promise to the press release and take it through a review cycle, or classify the feature as post-launch. This reframes the conversation from 'I want this feature' to 'should we expand our launch promises?' Most stakeholders will defer the feature when they see the implication for timeline and scope. Document the request and the decision so it does not resurface without context.
Should I identify minimum requirements before or after the FAQ section of the PR/FAQ is complete?
After. The [FAQ section](/skills/drafting-frequently-asked-questions-documents) pressure-tests feasibility, cost, and customer concerns. Requirements identified before the FAQ is done often need rework because the FAQ surfaces constraints, objections, or technical realities that change what is viable. Complete the FAQ, run at least one [review session](/skills/running-pr-faq-review-meetings), and then begin requirements decomposition with a stable narrative.
How long should the requirements identification process take for a typical product launch?
Plan for 2-4 hours for the initial decomposition session with your engineering partner, then 1-2 hours for classification scoring with the broader team. Allow another 1-2 hours for the feasibility validation step. In total, expect 4-8 hours of focused work spread over 2-3 days. Rushing it into a single marathon session produces lower-quality classifications because fatigue degrades judgment on the later requirements.
How do I identify minimum requirements when the product is a platform with multiple user types?
Write separate customer promises for each user type in your press release. Then decompose requirements per user type before consolidating. This prevents a common failure mode where requirements for one user type are assumed to satisfy another. A marketplace, for example, needs distinct promises for buyers and sellers. After decomposing separately, you will often find shared infrastructure, like authentication and notifications, that serves both. Consolidate those, but keep user-type-specific capabilities separate.
Why does my requirements list keep growing even after I complete the matrix?
Scope growth after matrix completion usually has one of three causes. First, your press release promises are vague enough that new requirements can be justified under broad wording. Tighten the promises. Second, you are not enforcing the traceability test on new additions. Every proposed requirement must map to a promise before it can be classified. Third, the team is adding 'improves but not essential' items to the must-have column without re-running the classification step. Schedule a brief weekly review to catch drift and re-anchor to the matrix.
Can I use this process for incremental feature releases, not just new product launches?
Yes. Write a mini press release, even a single paragraph, describing the customer experience after the feature ships. Then follow the same decomposition steps. For smaller features, you may have only 1-2 promises and 5-10 requirements, but the discipline of tracing each requirement to a promise and applying the simplest-version test still prevents scope creep. Teams that adopt this for quarterly releases report 20-30% less scope change during sprints.
How does this skill fit into building a product manager roadmap?
The requirements traceability matrix is the foundation of your product manager roadmap. Must-have items define your launch milestone. 'Improves but not essential' items populate the next 1-2 quarters. Post-launch items become candidates for future planning cycles, each requiring its own mini press release and decomposition before being committed. This gives your roadmap a clear rationale: every item traces to a customer promise rather than an internal request or competitive reaction.