The job is navigation, not acquisition
People own more clothes than any generation before them and still stand in front of a full wardrobe with nothing to wear. Every funded product in this category has read that as a cataloguing problem and built a database the user has to feed by hand.
The wardrobe is not under-stocked. It is unnavigable. That distinction is the whole product, and it is also the reason the incumbents keep losing people at week three: a database nobody maintains returns nothing, so the app that asked for the effort is the app that gets deleted.
Who this is for, and who it is not
Primary. 18–30, style-aware, time-poor, decision-fatigued. Owns more than they wear. Would dress better if they could find what they already have.
Secondary. The same person six months later, now using the wardrobe to decide what not to buy. This is where the affiliate model earns and where retention actually lives.
Explicitly not for, in v1: resellers, stylists managing other people's wardrobes, and anyone whose primary need is inventory for insurance or resale. Each would pull the data model toward completeness, and completeness is the thing that kills the category.
User stories, P0 only
Written as the user, not as the feature. Anything that could not be phrased this way was cut before it reached this list.
In, out, and the line between them
The case study describes three features. This document ships one and a half of them, because the outfit engine is worthless without a populated wardrobe and the shop is worthless without a working engine. Sequencing is the decision, not the feature list.
P0 · v1 ships without these and there is no product
- Garment capture by photo, with automatic category, colour and basic attribute recognition
- Manual correction of any recognised attribute, in one tap
- Outfit generation from wardrobe contents against an occasion input
- Accept / reject with a single-reason tap
- Wardrobe browse and search
P1 · valuable, and it waits
- The shop and affiliate layer needs an engine users already trust
- Wear-frequency insights needs a month of real usage to say anything
- Weather and calendar inputs adds accuracy to a system not yet proven to be wanted
Out · not in this product
- Social feeds, sharing, following this is the engagement incentive we exist to avoid
- Trend content and “what you should want next” the opposite of the positioning
- Resale and listing tools pulls the data model toward completeness
What P0 actually has to do
| ID | Requirement | Why it is this number |
|---|---|---|
| R-01 | Capture to catalogued garment in under 10 seconds, including correction. | Longer than a photo plus a glance and the user is doing data entry, which is the behaviour that loses this category. |
| R-02 | Recognition correct on category and colour without correction for the clear majority of garments. | A threshold is set after the first 500 real garments, not before. Guessing a percentage here would be inventing the one number the build should produce. |
| R-03 | Any wrong attribute correctable in one tap, never a form. | Correction is the recovery path for R-02. If it costs more than the error, users stop correcting and the catalogue silently rots. |
| R-04 | Outfit returned in under 3 seconds from a cold open. | The competing behaviour is opening the wardrobe door. Anything slower loses to the door. |
| R-05 | Every outfit built only from owned garments. No aspirational items, ever. | One suggested item the user does not own breaks the promise the whole product rests on. |
| R-06 | Rejection reason captured in one tap from a fixed, short list. | Free text will not be written at 7am. A short list is the only feedback that will actually arrive. |
| R-07 | Wardrobe usable at 15 garments, not 100. | Time-to-value decides week-one retention. A product that needs a full wardrobe before it works is a product nobody finishes setting up. |
R-02 has no number in it on purpose. The threshold is an output of the first build, and a target invented before the data exists is the kind of number this portfolio does not print.
How we would know, and what would kill it
Three of these targets are carried from the GTM brief in the case study. The fourth is the only one that tests the hypothesis rather than the launch.
| Metric | Target | What it tells us |
|---|---|---|
| Outfit acceptance rate | 65%+ by day 30 | The one that matters. Below this the AI is guessing at taste rather than reflecting it, and the product is a worse version of the incumbents. |
| Downloads, first 30 days | 10,000 | Whether the positioning travels. A launch number, not a product one. |
| Pre-launch waitlist | 5,000 | Whether the problem is recognised before the product is seen. |
| Affiliate click-through | 8%+ within 60 days of shop launch | Whether a purchase recommendation made from a real gap converts better than a feed. This is the business model's only test. |
| Time to 15th garment | Under one session | R-07 in the field. If setup spans sessions, most users never return to finish it. |
The kill criterion. If acceptance rate sits below 50% at day 30 with a populated wardrobe, the hypothesis is wrong and no amount of UI fixes it. The product would be recommending, not reflecting, and the category already has five of those.
What breaks this, in order of likelihood
- Recognition quality is the product
- Every error lands in the catalogue and the engine inherits it. Accuracy stops being the user's chore and becomes our risk. Mitigation: one-tap correction (R-03), and recognition confidence surfaced rather than hidden, so a low-confidence guess asks instead of asserting.
- The engine has no taste signal on day one
- A new user has zero rejections, so the first outfits are the weakest the product will ever produce, at the exact moment it is being judged. Mitigation: onboarding asks for three owned outfits the user already likes, which is a taste sample disguised as setup.
- The affiliate model earns too slowly to fund the build
- Revenue only arrives once the user has genuinely been served, which is the point, and also a harder story than a usage graph. Mitigation: none at the product level. This is a funding decision, and it is the trade-off the positioning was chosen with eyes open.
- An incumbent copies the capture flow
- It is the most visible part and the least defensible. Mitigation: the defensibility is the incentive model, not the feature. A competitor earning on engagement cannot copy a product that earns on restraint without breaking their own revenue.
Three phases, each with a reason to stop
- Phase 1 · ClosedP0 scope, invite only, target 200 wardrobes. The only question being asked: does recognition work well enough that people keep adding garments after the first session? Stop here if it does not.
- Phase 2 · WaitlistSame scope, opened to the waitlist. The question becomes acceptance rate against a real spread of taste. The 65% target is measured here, before any spend.
- Phase 3 · Launch and shopPublic, with the affiliate layer switched on. The shop ships last because a recommendation is only trusted from a product that has already proved it understands the wardrobe.
What this document does not answer
Listed because a PRD that pretends to be complete is the least useful kind.
- Whether recognition should run on-device or server-side. It is a cost, latency and privacy trade-off, and R-04 is the constraint it has to satisfy.
- What the engine does with a wardrobe of 300 garments. Every assumption here is written for 15 to 60.
- Whether “occasion” is the right input. It is the one the case study assumes; mood and weather are the alternatives and no user has been asked.