Identifying Minimum Lovable Requirements from a PR/FAQ

Find the minimum lovable requirements for a launch: trace each one to a promise in the PR/FAQ, cut the rest, and keep the headline benefit intact.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

Minimum lovable requirements are the smallest set of things a team must build and run so that the launch delivers what the press release promised, well enough that the customer it describes would care. This skill turns an approved PR/FAQ from the Working Backwards method into that list.

The idea of working backwards to a minimum appears in an early Amazon description of the process. In 2006, Amazon CTO Werner Vogels described Working Backwards as a process in which "you start with your customer and work your way backwards until you get to the minimum set of technology requirements to satisfy what you try to achieve," with the goal of driving "simplicity through a continuous, explicit customer focus" (Vogels, Working Backwards). He framed it as making sure a service meets the needs of the customer and not more than that.

The word lovable is this skill's addition, and it is not Amazon's term. It is a reminder that the minimum has a floor. A launch that technically works but no longer delivers the headline benefit fails the press release, however small it is. Colin Bryar and Bill Carr make the same point from the other side: the best products "simply and directly address the primary customer need rather than provide a laundry list of features that may sound worthwhile" (PR/FAQ instructions). The primary need is what must survive every cut.

The PR/FAQ is what makes cutting defensible. Every requirement can be traced to a sentence in the press release or an answer in the FAQ, so the question in a scope debate stops being whether a feature is good and becomes which customer promise it serves. A requirement that serves no promise is either a missing promise, which should be added to the PR/FAQ openly, or something the launch does not need.

This skill also handles the reverse case. Sometimes the minimum is still too expensive, and the FAQ shows a large upfront investment with a risky payoff. Bryar and Carr list that as one reason a PR/FAQ is not approved, and their suggested next step is to find ways to get started with fewer resources. A clean requirements list is the tool for doing that without losing the customer benefit.

The output is a requirements list with a trace to the PR/FAQ for each item, a list of what was cut and why, and any changes to the PR/FAQ that the cuts made necessary.

How It Works

The skill starts from the promises. Read the press release and FAQ and list each commitment the document makes to the customer: the headline benefit, the claims in the solution paragraph, what getting started involves, the answers to price, support and data questions. Each promise is written as a customer outcome, such as "a freelancer can send an invoice from a phone," because outcomes can be delivered in more than one way.

Each promise then gets broken into capabilities. If the team has written customer experience stories, as in Defining the Customer Experience Before Building, the capabilities come from the steps of those stories. Include what is easy to forget: data migration, support tooling, billing, security reviews, monitoring, and the operations people will do by hand. Vogels's phrase was the minimum set of technology requirements (Vogels), and in practice the hidden infrastructure is often where the minimum turns out larger than expected.

Every capability then faces the same test: what is the simplest version that still keeps the promise? A manual process may stand in for automation at launch. A single integration may cover most customers where five were planned. A setting may be replaced by a sensible default. The test is always against the promise as written; if the simplest version would make the customer quote in the press release untrue, it is too simple.

Some capabilities cannot be simplified because they are the product's hard problem. Bryar and Carr argue that a strong press release should require the team to solve at least one complex problem with a new approach, since that is where the product's value comes from (PR/FAQ instructions). Mark that problem explicitly and protect it. Cutting it to save time usually means launching a product that is no better than the alternatives.

Cuts can change the PR/FAQ. If a promise is dropped or narrowed, the press release and FAQ must change with it, and the change should go back to the decision makers. Bryar and Carr describe the PR/FAQ as a living document that will almost certainly still be edited after approval, with changes directed by or reviewed with the leadership team (Amazon's excerpt from Working Backwards). Changing scope silently, without updating the document, breaks the link between what was approved and what ships.

The result feeds delivery planning. Bryar and Carr note that Amazon frequently used Agile to build a product once its PR/FAQ was approved, so the requirements list typically becomes the starting backlog, with each item still carrying its trace to the customer promise.

Step-by-Step Guide

Step 1: List the promises

Go through the press release and FAQ line by line and write each commitment to the customer as an outcome. Include the implicit ones, such as the price the FAQ states or the support it describes. Number the promises so requirements can reference them. Mark the headline benefit as the promise that cannot be cut.

Step 2: Break each promise into capabilities

For each promise, list what the product must do, hold or connect to, and what people must do behind the scenes. Use the customer experience stories if they exist, walking each step. Add infrastructure and operations: data, security, billing, support tools, monitoring. Record which promise each capability serves.

Step 3: Merge and find the dependencies

Combine capabilities that appear under several promises. Ask engineering and operations which capabilities depend on others and which rely on partners or third-party technology. Note the dependencies, since a small capability with a large dependency is not small. Flag capabilities that no promise needs.

Step 4: Apply the simplest-version test

For each capability, ask what the simplest version is that keeps its promise true at launch. Consider manual steps, fewer integrations, defaults instead of settings, and narrower customer segments. Write the simplified version next to the original. Check each simplification against the customer quote and headline in the press release.

Step 5: Protect the hard problem

Identify the capability that makes the product meaningfully better than the alternatives, usually the hard problem the FAQ describes. Keep it at full strength even if other things are cut. If the team cannot solve it in time, say so plainly; that is a question for the decision makers, and trimming around it will not answer it.

Step 6: Record the cuts

List everything that was cut or simplified, with the reason and what would bring it back. Include the capabilities that served no promise. Share the list with the stakeholders who wanted those items, and explain each cut in terms of the promises. A written cut list prevents the same items from creeping back one by one.

Step 7: Update the PR/FAQ and confirm

If any promise changed, rewrite the affected press release sentences and FAQ answers. Take the updated PR/FAQ and the requirements list to the decision makers, and confirm that the narrower launch is still worth doing. Then hand the list to delivery planning with each item's trace intact.

Best Practices

• Write promises as outcomes. An outcome can be delivered in several ways, which leaves room to find the simplest one.
• Trace every requirement to a numbered promise. A trace makes scope debates about the customer instead of about opinions.
• Count manual work as a real option. A process people run by hand at launch can prove demand before anyone automates it, as long as the customer experience holds.
• Look for hidden infrastructure early. Security reviews, data migration and support tooling are often missing from first lists and larger than the visible features.
• Keep the cut list visible. Stakeholders accept cuts more readily when they can see what was cut, why, and what would bring it back.
• Revisit the list when the PR/FAQ changes. A requirement list that no longer matches the document it came from has lost its purpose.

Common Mistakes

• Cutting the benefit: Trimming until the product no longer delivers the headline promise produces a small launch nobody wants. Check every cut against the press release.
• Treating technical wishes as requirements: Rebuilding a component or adopting a new framework may be worthwhile, but if no customer promise needs it, it is not a launch requirement. Plan it separately and say so.
• Forgetting operations: Lists made only from screens miss support, billing, monitoring and compliance. Walk the whole customer experience, including what happens when things go wrong.
• Changing scope without updating the PR/FAQ: A launch that quietly drops a promise surprises the people who approved it. Update the document and confirm the change.
• Treating the minimum as permanent: The launch scope is a starting point. Keep the cut list so the team can return to deferred items when evidence shows customers want them.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Working Backwards

Related Skills

• Defining the Customer Experience Before Building
• Writing an Internal Press Release for a Product Idea
• Drafting the FAQ Section of a PR/FAQ
• Iterating PR/FAQ Documents Through Feedback
• Running PR/FAQ Review Meetings
• Using Working Backwards in PM Interviews

Sources

• Werner Vogels: Working Backwards
• Working Backwards LLC: PR/FAQ Instructions and Template
• About Amazon: excerpt from Working Backwards

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.