At a previous company, I was part of a team that launched a manual toothbrush with a refillable brush head. The refill packs had a problem that mattered to many retailers: they took up too much shelf space.
One refill pack took up the space of two regular toothbrushes, and the packs were too tall to stack. That meant, two packs took the space of four toothbrushes. On a crowded shelf, that is a hard sell.
Why it sat unsolved
No one had the bandwidth to take it on. When the team did find a moment, the ideas got bigger, not simpler: dispensers and other contraptions we could develop to make the packs work.
Each of those ideas was its own project. Solving the problem by building something felt like the serious answer.
The reframe
I got a quiet moment to think about it and came at it differently. Instead of asking how to make the pack work on the shelf, I asked how much space the shelf actually needed us to use.
The answer was in the pack itself. The two refills sat side by side. If they sat on top of each other instead, the pack would take up close to the same space as a regular toothbrush.
Same product. Same two refills. A different arrangement.
The same two refills fit in a long, skinny pack that takes one shelf spot instead of two.
What it took, and what happened
The change wasn't free. The main work was updating the packaging artwork, which is what it took to get the new design through. That was a far smaller effort than building dispensers or other fixtures.
The team was thrilled to have a solution, particularly the sales team. The new pack was adopted, and we saw a lift in distribution.
Why simple answers are hard to see
Complexity feels like progress. When a team is stretched, building something looks like the responsible response to a hard problem, while stepping back looks like a luxury. The answer here came from the opposite move: a quiet moment to question the constraint instead of engineering around it.
The same pattern shows up in early-stage companies. Problems sit because no one has time, and when someone does, the proposed fix is bigger than the problem. A few questions help:
• What is the actual constraint? Look past the symptom to what is really in the way.
• What is the smallest change that would remove it? Start there before considering anything larger.
• What would we do if we couldn't build anything new? The constraint often forces the simpler answer.
Before you build something bigger
The scarce resource in that story wasn't a better idea. It was a moment of space to think. Stretched teams rarely give themselves that, which is where an embedded partner helps: someone close enough to the work to see the problem, with enough distance to question it.
If your team is stuck on a problem that keeps getting bigger, let's talk.
