All posts

May 3, 2026

You Have One Sentence. Here's How to Design the Whole Product.

Every product starts as an idea you can state in one sentence. Getting from that sentence to a complete, screenworthy design isn't about prompting harder — it's about unpacking what the idea actually implies.

"Airbnb for boat storage." "Duolingo for financial literacy." "Notion for legal teams." The one-sentence product idea is a real category — it communicates something meaningful about what a product is and who it's for, and it's usually the form in which products are first described, pitched, and greenlit.

The sentence is also nowhere near enough information to design from. Not because it's bad — a sharp one-liner is actually valuable, as a positioning statement and as a forcing function for clarity. But because between "Airbnb for boat storage" and a designed product, there are dozens of questions that haven't been asked yet, let alone answered.

What the sentence doesn't contain

Take "Airbnb for boat storage." It implies a two-sided marketplace — boat owners looking for storage, and people with space willing to rent it. That's a starting point. But it says nothing about the screens.

What does the host's listing creation flow look like? How many steps? What does the empty state look like when a host has just signed up and has no listings yet — does it prompt them to create their first one, or does it just show a blank screen?

What does a renter's search result look like? What information is shown on the card — price, location, size, availability? What happens when there are no results for their search area?

What does a booking confirmation screen show? Who sees what — the renter gets one view, the host gets another. What's the pending state while the host decides whether to approve?

What does the cancellation flow look like? What screens does a renter see when they cancel? What does the host see when a booking they accepted gets cancelled?

The design of the onboarding flow for each side is different too. A new host arriving to an empty dashboard needs a different first screen from a renter arriving to search. The empty state when no listings exist yet is a product decision that affects whether hosts trust the platform enough to keep going.

None of these are edge cases. They're the product. The one-sentence idea contains none of them, and a prompt doesn't surface them — it just generates a screen that assumes the answers without asking.

The questionnaire as a structured unpacking

The point of Mowgli's questionnaire isn't to make you think harder before you're allowed to design. It's to surface the questions the sentence doesn't answer — quickly, in a structured way, so the generation that follows is based on a real product model rather than an extrapolation from a one-liner.

The questionnaire asks about user types (in a marketplace, that's both sides — host and guest, seller and buyer, provider and consumer), their core flows, the edge cases and empty states that matter, and the scope and constraint boundaries. For "Airbnb for boat storage," this means the questionnaire would draw out: what the listing creation flow needs to capture, what the search and booking experience looks like for renters, what the host dashboard needs to show, and what the first-time empty states look like before any listings or bookings exist.

This takes around 10 minutes. The output is a spec — a structured product document that captures what the product is, who it's for, and how it behaves. That spec is then what the design is generated from.

The difference in output is significant. A design generated from a one-sentence prompt produces a plausible set of screens that roughly resembles the concept. A design generated from a full spec produces a product: complete flows for both user types, appropriate empty states, a booking and messaging flow that reflects the decisions made in the questionnaire, a host dashboard that shows the right information, and an onboarding sequence that accounts for the fact that a new host has no listings and a new renter has no booking history.

Two-sided products and multi-role apps

The "Airbnb for X" formulation is a specific case of a broader pattern: products where different users have fundamentally different experiences. Marketplaces, platforms, tools with admin and member roles, products where creators and consumers interact — all of these have the same structural challenge. The design isn't one product. It's two or three user experiences that share infrastructure and need to be coherent with each other.

Generic AI design tools generate one product. They don't model the relationship between a host's listing management flow and a renter's search-and-book flow, because they don't have a model of the product at all. They generate screens. Whether those screens add up to a coherent multi-sided product is a question they're not designed to ask.

A spec-driven approach can hold multiple user types simultaneously, because the spec is the model of the whole product. The host onboarding and the renter onboarding are both in the spec. The host dashboard and the renter booking confirmation are both expressions of the same product, generated from the same source. Changes to the spec — adding a cancellation policy, changing how availability works — propagate to both sides because both sides derive from the same model.

When the product changes, the spec understands what to update

Products built from a single sentence don't stay that sentence for long. Scope shifts. Features get cut. A premium tier gets added and then removed. A flow that started simple turns out to touch six other screens in ways that weren't anticipated when the first design was done.

This is where the spec earns its value beyond the initial generation.

Take a concrete example: a marketplace product that launched with a premium verification badge for hosts. That badge appeared in the search results screen, the host profile, the booking confirmation, the host dashboard, the renter's receipt, and the trust and safety onboarding step. Six distinct surfaces, each showing the feature in a slightly different context. When the decision is made to remove the premium badge — whether because of pricing feedback, legal complications, or a product pivot — the question becomes: where does it live?

In a product designed from individual prompts, the answer is: everywhere you remember to look. Each screen was generated separately, each lives in its own Figma frame or code file, and tracking down every instance of the badge is a manual audit. Screens get missed. Engineers implement from designs that still show the badge. QA finds it in production.

In a product designed from a spec, Mowgli knows where the badge lives because the spec knows it exists. The feature is defined at the product model level, not scattered across disconnected screens. When you tell Mowgli to remove the premium verification feature, it understands what it is, finds every screen it touches, and updates them all — because it's reasoning from the spec, not searching through independent frames.

The same logic applies to any cross-cutting change: adding a new user role that needs to be reflected across navigation, permissions, empty states, and onboarding; changing the cancellation policy in a way that affects the booking flow, the host dashboard, the renter receipt, and the help text in settings; adding a new pricing tier that changes what certain features show or hide. Each of these changes is scattered across a real product. The spec is what makes it possible to find and update all of them consistently, rather than by memory.

From sentence to spec to screens

The practical arc for a founder with a one-sentence idea:

The sentence is the starting point for the questionnaire, not a prompt for a generation. Ten minutes of structured thinking — user types, flows, edge cases, constraints — turns the sentence into a spec. The spec is what the generation is built from. The result is a complete set of screens for a real product, not a rendering of a concept.

The difference matters when you're trying to show the product to investors, validate with early users, or hand it off to engineers. A concept rendered from a one-liner leaves significant product decisions undefined — decisions that will get made later, inconsistently, under time pressure. A design derived from a spec has those decisions made upfront, visible in the screens, and available to be revised explicitly rather than discovered accidentally.

The sentence doesn't have to get more complicated. The questionnaire does the unpacking. What comes out the other side is a product that was designed from the beginning, not assembled from a prompt.

Sources