Big problems rarely need big solutions

The most valuable thing I shipped at elyps was a button that said "Do it later".

That is not false modesty. It was a small change on one screen, it took days, and it moved the number more than anything else we tried that quarter.

The instinct runs the other way. A big problem shows up, so you reach for a big response: the full redesign, the platform migration, the feature that finally changes everything. The size of the project gets matched to the size of the problem, because that feels like taking it seriously.

In my experience the correlation is close to zero.

Two examples that should have been bigger

elyps. Weeks after launch, roughly eight in ten new sign-ups were abandoning onboarding, and almost all of it was happening at one screen: the one right before KYC verification. This is a regulated neobank, so removing the verification was never on the table. The obvious project was rebuilding onboarding end to end.

We added a "Do it later" option on that screen, plus a reminder in the evening. Drop-off at that step went from about 80% to about 60%, and activation conversion rose 30% across the engagement. The full story is in the case study, including why the timing mattered more than the compliance requirement did.

UX Pilot. We wanted free-to-paid conversion to go up. The obvious projects were a new pricing tier or a lifecycle email programme, both of which are a quarter of work minimum.

Instead I went through the product analytics first. Users who triggered a higher-fidelity generation mode called Deep Design in their first seven days converted at 12.3%. Users who did not converted at 1.3%. So we turned it on by default for every user's first generation and tested it properly: 120,000 users over 11 days, Bayesian A/B test. Free-to-paid conversion rose 44.7%, with a 96.2% win probability, and it went to everyone. That one is written up here.

Neither of those was a quarter of work. Both were days.

Why the big version is so attractive anyway

Three reasons, and only one of them is about the product.

It is legible. A three-month project is easy to put on a roadmap, easy to staff, and easy to describe to a board. "We added a button" is a harder slide.

It feels proportional. A large number in a dashboard seems to demand a large response. Eight in ten people leaving looks like a broken flow, so rebuilding the flow feels like the honest answer.

It postpones being wrong. Nobody can tell you the redesign has failed until the redesign ships. A two-week change is exposed in two weeks. That is not a bug in the small version, it is the entire point, and it is also why people avoid it.

How to find the small version

It is a fairly mechanical process once you stop starting from solutions.

1. Find the exact step. Not "onboarding is bad". The screen. The field. The tap where the session ends. If your analytics cannot tell you that, fixing the analytics is the smaller, higher-value project.

2. Find out what they were trying to do when they stopped. Talk to some of the people who left. What you are looking for is the reason they stopped, which is almost never the same as a missing feature.

3. Ask what would let them keep going right now, without removing the constraint. At elyps the constraint was legal and permanent. The question was not "how do we drop KYC" but "does it have to be now".

4. Ship the smallest thing that removes the reason to stop, and decide before you ship what number has to move and by how much. We set a success bar of +10% on the UX Pilot test and got +45%, which is only a meaningful sentence because the bar existed first. That discipline is the whole of designing an experiment properly.

Do that a few times and it stops being a special initiative. It becomes how the team decides things.

When the rebuild really is the answer

Sometimes it is, and pretending otherwise is its own failure mode. The distinction I use is local friction versus structural constraint.

If you have shipped three small changes at the same step, each moved the number a little, and then the movement stopped, the constraint is probably structural. Now the big project has evidence behind it, a known ceiling to beat, and a much better chance of being scoped correctly.

If you have never shipped one, you do not know yet. You have a hypothesis about your architecture, dressed up as a roadmap item.

There is also a useful tell in the attempt itself: if the small change turns out to be impossible without a rewrite, that is real information about your system, and it is worth a week to discover rather than a quarter to assume.

The question to take into your next planning session

Look at the largest item on the roadmap. The one everybody has agreed is necessary and nobody has costed honestly. Ask the room: is there a "Do it later" button hiding in here somewhere?

Often there is, and finding it buys you back a quarter. When the answer is genuinely no, at least you now know why, which is more than most teams can say about their biggest bet. If you are trying to decide which of five big items deserves the room at all, that is a different problem, and prioritisation is where it gets solved.

Finding the small version is a discovery skill rather than a delivery one, and it is most of what we practise in the Product Discovery Workshop: locating the real friction, then sizing the intervention to it instead of to the calendar.