I've been asked to launch something and I don't know what users actually need.

What to do when you must launch but don't know what users need

Mumbai, two thousand and twelve. Falguni Nayar leaves her role as Managing Director at Kotak Mahindra Bank to found Nykaa at the age of forty-nine. She has spent nearly two decades as one of India's leading investment bankers — taking other companies public, running large transaction teams, advising boards.

The market she is moving into is not one she has any operating experience of.

Her own framing of the founding, in a two thousand and twenty-two Fortune longform interview a few months after Nykaa's thirteen-billion-dollar IPO, is unsparing. I didn't know beauty. I didn't know retail. The Indian beauty consumer, she observes elsewhere in the same interview, typically uses about five products — kajal, lipstick, and a handful of others. The consumer doesn't know what a primer is. Neither does the market she is about to try to build.

The launch decision is not to wait until she understands the market better.

It is to ship into the gap and let the shipping itself teach her what the market wants. The first Nykaa iteration is heavy on content — blogs, tutorials, educational social posts — because the underlying bet is that Indian consumers will buy a wider international product range only if someone first explains to them what these products are for.

Brand authenticity, real sourcing, no counterfeit. Trust, safe, high-quality, branded. Those are the two signals that most reliably predict repeat purchase. That knowledge is the output of running the business, not the input to it. It is what the early launches teach Nayar over the months and years that follow.

Nine years later, the November two thousand and twenty-one IPO makes Nayar the first Indian woman to take a unicorn public.

When you've been asked to launch something and you don't know what users actually need, there is a temptation to do enough research first that you no longer have to say you don't know. Nayar's move was not to try. She named the gap in her own understanding publicly, and built the launch around the assumption that the company's customers would teach the company what to sell them. The market category Nykaa ended up defining did not exist, in the shape it now has, before Nykaa started selling into it. It could not have been researched. It had to be built — and the only way to build it was to accept, at the outset, that what the customers wanted would only become legible once they were shown what was available.

So let's go to the office and work through it.

First name the uncertainty you actually have

"I've been asked to launch something and I don't know what users actually need."

The feeling is uncertain.

The brief is real. The deadline is real. The team is real. And the person who can tell you what users actually need has not yet been identified, because — as far as the team can tell — the people who would tell you have not yet been asked the right question.

Two choices. Different uncertainties. Different first moves.

When you can't tell if there's demand

Choice one: you don't know if anyone wants the thing at all. The idea is early. The team is guessing. Nobody has put the proposition in front of a real person yet.

If that's the read, build a landing page with a fake sign up or buy now button and see who clicks it.

Alberto Savoia, who developed what he called pretotyping at Google, was specific about this. The point is to build the smallest possible thing that could falsify your assumption. The click-through isn't a promise to use the product; it's a cheap measurement of intent at a moment when building the product would be expensive. Most ideas don't survive their first honest contact with the people they're supposed to serve, and finding that out with a landing page costs a day and a domain name rather than six months and a team.

When demand is clear but willingness to pay isn't

Choice two: you know they want it, but you don't know if they'd pay for it. The interest is real. The willingness to pay is the part you're uncertain about. People say yes I'd definitely buy this in response to a survey and then decline to actually do it.

If that's the read, ask them to prepay. Not a deposit for the finished product. A prepayment for early access, with a refund available.

Rob Fitzpatrick, in The Mom Test, is direct about this. People tell you what you want to hear unless the cost of lying is real. Prepayment sorts genuine interest from polite enthusiasm more sharply than any other measurement in the discovery toolkit. The number of people who say yes I'd buy this and then decline to hand over fifty pounds today is the number you actually need to know.

How to build the test before you build the thing

Want, or pay. Different uncertainties. Two different first moves.

Three tools. The discipline is to build the test before you build the thing.

Keep it rough so they react to the idea

The first is

Concept Testing.

Concept Testing as a structured discipline traces through the marketing-research literature of the nineteen-sixties and nineteen-seventies, with deeper roots in the consumer-products development practice of Procter and Gamble and Unilever in the post-war period. The contemporary form — testing low-fidelity sketches and wireframes with target users — is closer to the Nielsen Norman Group's user-research practice and the IDEO design-thinking tradition.

The reason Concept Testing matters when you don't know what users need is that high-fidelity prototypes invite feedback about execution rather than about the idea. Users who see a polished-looking design will tell you what they think of the colour palette, the typography, the button placement. Users who see a rough sketch will tell you what they think of the idea, because there's nothing else to comment on.

The unique insight is that the low fidelity is the feature. A deliberately rough sketch communicates this is the idea, what do you think? in a way a polished design cannot. The polish, in early-stage testing, is doing the wrong work — it's signalling here's what we built rather than here's what we're considering.

What you get is feedback about the idea, before you have spent the money to execute it. The feedback is sometimes yes, this is what I'm trying to do, in which case you build. The feedback is sometimes that's not really my problem, in which case you save the build.

So. How to run it.

Sketch. Pen and paper, or tablet, or whiteboard. Crude on purpose. The sketches communicate the structure of the idea without committing to any execution detail.

Pick. Same target segment as the eventual product. Compensate them. Schedule them inside a week.

Show. Here's something we're considering — what would you do with this? The conversation is exploratory; the user's response is the data.

Watch. Where their attention lands tells you which parts of the idea connect. Where their attention slides off tells you which parts don't matter to them.

Aggregate. Across five users, the same parts will keep getting reactions. Or they won't. Both are diagnostic.

Write the bet down so it can be wrong

The second is

Hypothesis-Driven Development.

Hypothesis-Driven Development as a structured practice emerged through the lean-startup writing of Eric Ries and the agile-product literature of the late two-thousands and early twenty-tens, with deeper roots in the scientific-method tradition formalised across multiple fields and the experiments-not-projects discipline that has surfaced in product engineering through the twenty-tens.

The reason Hypothesis-Driven Development matters when you don't know what users need is that every feature you build is implicitly betting on something the user is going to do. Most teams don't write the bet down. They build the feature, ship it, and then argue afterwards about whether the launch worked. The argument cannot be settled because the success criterion was never defined.

The unique insight is that the hypothesis has to be specific enough to be wrong. Users will love this is not a hypothesis. More than thirty per cent of segment X will complete the core flow within their first session is a hypothesis — it can be checked against data, and the data either supports it or doesn't.

What you get when the hypothesis is written before the build is a structural test for the launch. You know, on day three, whether the bet worked. The team isn't arguing about what the data means; the test was designed to answer a specific question, and the data either supports the answer or doesn't.

So. How to use it.

Write. Before any code. We believe users in segment X will do Y when we ship Z. Specific. Falsifiable.

Define. What number, on what dashboard, will tell you whether the hypothesis held?

Set. When will you read the result? Day three after launch, against the rolling weekly metric. Pre-commit to the window so the team doesn't keep extending it until the data flatters.

Run. Build the smallest thing that lets the hypothesis be tested. Ship. Wait the time window.

Read. Held against the metric you defined before launch — not the one that looks best in retrospect.

The discipline is uncomfortable for the team — pre-committing to interpretation feels like inviting failure — and the discomfort is the price of getting an answer rather than an argument.

Let real behaviour decide between versions

The third is

A-B Testing.

A-B Testing as a structured method comes out of the controlled-experimentation tradition formalised by Ronald Fisher in agricultural research in the nineteen-twenties and the medical randomised-controlled-trial discipline that built on it. The contemporary product-engineering form was popularised by Google, Microsoft, and Amazon through the late two-thousands and early twenty-tens, with the canonical formalisation in Ron Kohavi, Diane Tang, and Ya Xu's two thousand and twenty book Trustworthy Online Controlled Experiments.

The reason A-B Testing matters when you don't know what users need is that opinions are always louder than data, and the only reliable way to prevent the loudest opinion winning is to set up the experiment before the meeting happens. A-B tests force the comparison to be specific — version A versus version B, against a defined metric, on a defined population.

The unique insight is the pre-registered comparison. The team agrees, before the test runs, what they will accept as evidence in either direction. The test runs. The result is what it is. The argument is structurally limited to interpretation of the metric, not to whether the metric is the right one.

What you get is a way to let real behaviour decide between versions rather than letting opinion decide. Behavioural data is harder to argue with than self-reported preference, and it's harder to argue with again when the team agreed in advance how to read it.

So. How to use it.

Design. Two versions, identical except for the variable you're testing. Headline copy A versus headline copy B. Pricing page A versus pricing page B.

Pick. What behaviour, on what page, will tell you which version performs better? The metric has to be downstream enough to matter (conversion, retention) rather than just adjacent to the change (clicks, time on page).

Run. Long enough to reach statistical significance, against your traffic volume. Most teams under-run their tests; the result is noise rather than signal.

Read. Statistical significance, not headline numbers. Version B is up twelve per cent without confidence intervals is meaningless; version B is up twelve per cent with ninety-five per cent confidence is acting evidence.

Accept. This is the discipline the framework demands and the team usually fails. No significant difference is a valid result. Most teams refuse to accept it and keep slicing the data until they find a sub-segment where one version looks better. That's not analysis; that's storytelling.

A precedent: ship the crude version and let it teach you

That's the toolkit. One more story before we close.

The Nayar story we opened with showed the discipline of shipping into a gap you can't research, on the premise that the customers themselves would teach you what to sell them. The story we close with shows the same move at a different cut — a founder who shipped the crudest manual version of an algorithmic product, on the premise that the algorithm would only know what to be once the manual version had taught it.

Cambridge, Massachusetts, early two thousand and eleven. In her second year at Harvard Business School, Katrina Lake launches a class-project startup originally named Rack Habit, later renamed Stitch Fix. The concept is a personal-styling service. Customers fill out a style profile and receive a curated box of clothes selected by a human stylist.

The specific problem Lake is trying to solve is well-identified. Online retail is overwhelming for a cohort of busy working women who don't have the time to browse. The answer, though, is not.

Lake doesn't know what those women will pay for. She doesn't know what they will keep. She doesn't know which signals in a style profile will predict which clothing choices, or whether the unit economics of hand-packing a box can ever work at scale. None of those things have been answered, by anyone, in the form Stitch Fix is testing.

Rather than try to design the system before validating it, Lake ships the crudest workable version.

She uses SurveyMonkey for the style profiles. She collects the twenty-dollar styling fee by physical cheque. She and her co-founder Erin Morrison Flynn buy the initial inventory on Lake's credit card from Boston boutiques, and pack the first boxes themselves, from Lake's Cambridge apartment, shipping to friends and family.

Every part of the system is manual. Every part is expensive. Every part is unscalable.

And every part generates the data that will later be used to decide which parts to automate.

Eric Colson, formerly Vice President of Data Science at Netflix, joins the company in early two thousand and twelve as Chief Algorithms Officer. The algorithms are built on top of the manual process, not in place of it. Stitch Fix goes public on the seventeenth of November two thousand and seventeen.

So.

Nayar at Nykaa shipped into a market she didn't know, on the premise that customers would teach the company what to sell them. Lake at Stitch Fix shipped a manual process at near-zero scale, on the premise that the manual process would teach the company what to automate. Two different cuts at the same move — ship into the gap, and let the shipping teach you what users need, at very different scales of business and category.

When you have been asked to launch something and you don't know what users actually need, the instinct is to research more before you build. Sometimes that's right. Often it isn't. Some markets — the ones that are genuinely new in the shape they will take — cannot be researched ahead of being built. They have to be built, slowly enough for the customers to show you what they want, and the build itself is the research.

You don't find out what users need by guessing better. You find out by shipping the smallest thing that lets them show you.

So. Your Next Move from this playbook.

What success metric have you written down before running the next test — and would you actually accept a no significant difference result, or would you keep slicing the data until something looked good?