Quick answer: we drop a product idea when we cannot describe who has the problem in one sentence, when people already solve it well enough, when we cannot reach them, or when nobody will pay. We write those stop rules down before any work starts, so the decision is quick, cheap and not about how much we like the idea.
- We expect to drop more product ideas than we build, and we plan for it.
- Stop rules are written before the work starts, while we are still neutral.
- A dropped idea gets a short note, and anything reusable stays in the studio.
Unavoidable Studio builds and runs several products, which you can see in the portfolio. What you cannot see there is the longer list of ideas that never made it. People ask how we choose what to build; the more useful question is how we decide what not to build. This is how we drop a product idea, written up as part of building in public.
Why do we drop more ideas than we build?
Because a small team can only run a few products well, and every product we start takes time from the ones customers already rely on. Saying yes to an idea is really saying no to weeks of work somewhere else.
So we treat ideas as cheap and products as expensive. An idea costs a page of notes. A product costs a build, a website, support, legal pages and years of looking after it. The job of our early process is to let ideas fail while they are still cheap.
When does a product idea get dropped?
An idea gets dropped as soon as it fails one of a handful of plain tests. Most of them come from the checks in how we validate an idea before we build it:
- We cannot describe the person in one sentence. If we cannot say who has the problem, we cannot find them, talk to them or write for them.
- They already solve it well enough. A spreadsheet, a phone call or an existing tool that people are happy with is a strong competitor, even if it looks clumsy from the outside.
- We cannot reach them. If we do not know where these people spend their attention, the best product in the world will sit unused.
- Nobody will pay. Interest is easy to get. A clear sign that someone would pay for the result is much rarer, and without it the product cannot support itself.
- It does not fit how we work. Every product shares the studio’s foundations, set out in shared infrastructure across a studio. An idea that would need a completely separate set of tools or round-the-clock specialist support is a poor fit for a small team, however good it is.
Failing one test is usually enough. We do not average the scores and hope the strong points carry the weak ones.
How do we decide before we get attached?
We write the stop rules down before any work starts. At the beginning, nobody has spent time on the idea and nobody is attached to it, so it is easy to be honest about what would make us stop. A month later, after the conversations and the sketches, it is much harder.
The note is short. It says who the idea is for, what we expect to see if it is worth pursuing, and what would make us stop. Then each stage has a limit on time, so an idea cannot drift on for months because nobody wants to call it. When the time is up, we read what we found against what we wrote and make the call.
The same thinking applies after launch. The signals in product market fit for small products are how we judge whether a live product is working, and they are agreed in advance for the same reason.
What happens to an idea after we drop it?
It gets a short written note, and it goes back on the list rather than in the bin. The note says what we tested, what we found and why we stopped. That takes ten minutes and saves a lot of time later, because the same idea tends to come back in a slightly different form.
Anything reusable stays. Research about a group of customers, a piece of shared code or a page of wording can all feed the next idea. That is one of the quiet advantages of a studio over a single product: a dropped idea still leaves something useful behind. How the ideas that survive get chosen is covered in how we choose what to build next.
Is dropping an idea a failure?
No, as long as it was dropped early and cheaply. The real failure is building something for a year that the evidence warned against in the first month.
The GOV.UK Service Manual makes the same point about public services. Its guide to how the discovery phase works (last updated 21 June 2021) says: “It’s not a failure to stop at the end of the discovery phase if your research shows that’s the best thing to do.” It adds that stopping saves “time and money that could be better spent elsewhere”. We agree, and we try to run every idea that way.
FAQs
How many ideas do you drop?
More than we build. Most ideas never get past the first written description, and that is by design. We do not publish a running count, because the number matters less than how cheaply each one was stopped.
Do you ever bring a dropped idea back?
Yes, if the evidence changes. Every dropped idea has a short note saying why it stopped, so if something new turns up, such as a change in how people work or a fresh request from customers, we can pick it up again without starting from nothing.
Who makes the decision to drop an idea?
The same people who decided to look at it. We agree the stop rules before any work starts, so when the time comes the decision is mostly a matter of reading the evidence against what we wrote down.
What is the hardest part of dropping an idea?
Letting go of something you like. That is why we write the stop rules down while we are still neutral about the idea, rather than deciding afterwards when we are attached to it.
For the products that made it through, visit the portfolio, and for more from the studio, browse the blog.
Founder of Unavoidable Studio, a UK venture studio in Leeds building six software companies at once. Answers his own inbox.