The most useful thing a product manager can do before writing a single MVP requirement is to run discovery techniques that produce data on which problems matter most to users, because that data separates features that belong in the initial release from features that belong on a roadmap. Prototypes and concierge tests generate this data at the lowest cost, and an MVP built on their evidence gives the team a defensible position when internal voices push to add pet features during development. The stance is simple: we made these decisions based on this supporting data.
How Can I Use Discovery Techniques to Define Which Features Belong in an MVP?
Imagine a restaurant group that wants to add a new signature dish to forty locations. The first approach is the debate room, where the head chef, a regional vice president, and the marketing lead argue about what the dish should be based on opinion and seniority, and whatever wins gets printed on all forty menus. The second is the test kitchen, where one chef prepares the dish by hand for a small set of real diners, which is a concierge version in which a human does the manual work to simulate what a scaled kitchen process would eventually do. The chef watches what diners actually order, what they finish versus send back, and what they say unprompted to the server, which is data no conference-room debate can produce. Prototyping and concierge testing are the product equivalent of that test kitchen: doing the unscalable, manual version first because the data it produces is worth more than the effort.
A prototype is a tangible, simplified version of a product experience put in front of real users to test whether an idea has value before the team invests in building it. Marty Cagan, in Inspired, frames discovery as the fastest, cheapest way to test ideas, meaning a prototype exists to answer questions rather than impress stakeholders (Cagan, Inspired). He identifies four risks that discovery must address: whether the customer will buy or use the product, whether the user can figure out how to use it, whether the engineering team can build it, and whether the solution works for the business. A prototype tackles the first two risks at a fraction of the cost of a production build, which is why Cagan notes that discovery aims to ensure asking engineers to build a production-quality product is not wasted effort (Cagan, Inspired). Nielsen Norman Group echoes this, describing an MVP as the simplest version of a product or feature that enables a team to assess whether users will derive meaningful value, and calling it a structured experiment rather than a stripped-down launch (NN/g, “Minimum Viable Product: Definition”).
A concierge test takes the logic of a prototype one step further by replacing the software with a person. The product manager delivers the service manually to a small set of real users, performing the work that automated software would eventually handle and putting the team in direct contact with the people it is building for. Cagan describes the concierge test as a technique in which the product manager performs the customer’s job, which reveals the challenges the customer faces firsthand (Cagan, Inspired). The Learning Loop, maintained by Tristan Kromer, defines a concierge MVP as a manual, high-touch prototype in which you personally deliver the service to early users to validate demand before building automation (Learning Loop, “Concierge MVP Experiment”). A concierge test does not scale. But that is the point: it is a temporary way to learn before committing to code. Paul Graham’s maxim captures the principle: do things that don’t scale (Graham, “Do Things That Don’t Scale”).
For instance, Rent the Runway tested its dress-rental business by offering an in-person service to female college students who could try a dress on before renting it, validating the hypothesis that women would rent dresses and pay for the service (Learning Loop, “Concierge MVP Experiment”). Food on the Table, a meal-planning service, started when its chief executive sold the service for ten dollars a month in person to grocery shoppers, generated recipes and grocery lists by hand, and walked customers through the store, which produced firsthand knowledge of the effort required to deliver the product (Learning Loop, “Concierge MVP Experiment”). In both cases, the founders did the unscalable manual work first, collected data on what users valued, and used it to decide what to automate, which is the same decision a product manager faces when separating MVP features from roadmap features.
Eric Ries, who popularized the term minimum viable product in The Lean Startup, defines it as the version of a new product that lets a team collect the most validated learning about customers with the least effort (Ries, “What is an MVP?”). He points out that the definition is decidedly not formulaic, so it requires judgment to determine what MVP makes sense in a given context. When a product manager can point to observed user behavior from a prototype or a concierge run, the conversation about what goes into the MVP shifts from opinion to evidence. Nielsen Norman Group notes that an MVP will not eliminate uncertainty. However, it will replace opinion-driven debates with evidence the whole team can evaluate (NN/g, “Minimum Viable Product: Definition”). That shift protects cross-functional alignment once the MVP is in development.
The alignment problem is real and persistent. Once an MVP enters development, stakeholders who were quiet during discovery often surface to advocate for features they believe the product cannot launch without, which is the dynamic that turns a focused initial release into a bloated one. A product manager who has run prototypes and concierge tests, however, can respond with the data those techniques produced, which reframes the conversation. Nielsen Norman Group points out that stakeholders are more likely to support MVPs when framed as learning tools rather than rushed launches, and that a one-page summary stating the hypotheses, what will be measured, and the decision criteria gives stakeholders confidence that the experiment is well structured (NN/g, “Minimum Viable Product: Definition”). The supporting data becomes the reference point for every trade-off during development, keeping the product coherent and reducing the need to relitigate decisions the team already made.
The practical takeaway is to treat prototypes and concierge tests as the input to MVP definition rather than optional discovery activities. Run a prototype to test whether users see value in the core proposition, run a concierge test to learn what users do when the service is delivered by hand, and use the data from both to separate features that produce the most value in the initial release from features that belong on a roadmap. Then document the hypotheses, the evidence, and the decision criteria in a format the whole team can reference during development. Next, ask every stakeholder who advocates for a new MVP feature to point to the discovery data that supports it. If the data doesn’t exist, the feature goes on the roadmap, where future improvements belong.
REFERENCES
Eric Ries, “What is an MVP?” https://leanstartup.co/resources/articles/what-is-an-mvp. Referenced for the canonical definition of the minimum viable product as the version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort, and for the observation that the definition is decidedly not formulaic and requires judgment.
Nielsen Norman Group, Sara Paul, “Minimum Viable Product (MVP): Definition.” https://www.nngroup.com/articles/mvp-definition. Referenced for the framing of an MVP as the simplest version of a product or feature that enables a team to assess whether users will derive meaningful value, the characterization of an MVP as a structured experiment rather than a stripped-down product launch, the observation that an MVP replaces opinion-driven debates with evidence the whole team can evaluate, and the guidance that stakeholders are more likely to support MVPs when framed as learning tools.
Marty Cagan, “Inspired: How to Create Tech Products Customers Love.” Summary via Product Bookshelf, Olaf Kowalik, “Product Discovery Techniques.” https://www.productbookshelf.com/2021/01/product-discovery-techniques. Referenced for the framing of product discovery as the fastest, cheapest way to test ideas, the four risks discovery must address (value, usability, feasibility, viability), the concierge test definition, and the statement that the purpose of product discovery is to ensure engineers are not building a production-quality product as a wasted effort.
Learning Loop, Tristan Kromer, “Concierge MVP Experiment (Concierge Test).” https://learningloop.io/plays/concierge. Referenced for the definition of a concierge MVP as a manual, high-touch prototype in which you personally deliver the service to early users to validate demand before building automation, the Rent the Runway and Food on the Table examples, and the principle that conducting everything by hand gives firsthand knowledge of the effort needed to deliver the final product.
Paul Graham, “Do Things That Don’t Scale.” https://paulgraham.com/ds.html. Referenced for the maxim that founders should do things that don’t scale, which underpins the concierge testing approach.