Move fast and break things was written for a specific kind of product, and most complex products aren't that kind. But the fix isn't to build slowly. It's to understand the whole system and then deliberately build a small part of it.
Move fast and break things is good advice in a narrow set of conditions. A consumer product with low switching costs. One broadly similar kind of user. And failure modes you can recover from by shipping again next week.
Under those conditions the math is obvious. What you learn from shipping is worth more than what you lose from being wrong, because being wrong is cheap and temporary.
Most people building complex products aren't working under those conditions, and the advice doesn't transfer.
Why it doesn't transfer
When a product serves several kinds of user, there's no such thing as a local mistake. A decision that makes one group's work easier can quietly make another group's work harder, and you'll usually hear about it from the group with the least power to complain.
When workflows depend on each other, errors move. A choice that looks fine at the level of a single feature can be wrong at the level of the process that feature sits inside, and the wrongness only becomes visible further downstream.
And when the product touches regulation, some mistakes aren't recoverable by iteration at all. A compliance gap isn't a bug you fix in the next release. It's an exposure that exists for as long as it exists.
The debt doesn't add up. It multiplies.
This is the part that surprises people.
A simple product with one kind of user accumulates design debt in a straight line. Each wrong call costs you a fixed amount of rework, and the bill arrives roughly when you'd expect.
A product with several user types and interlocking workflows accumulates it differently. A wrong decision at the level of how the groups relate produces wrong decisions about workflows, which produce wrong decisions about individual features. By the time anyone can see the problem, it isn't in one place. It's distributed across everything built since.
The failure shows up late, and that's the trap
CB Insights analyzed 431 venture-backed companies that shut down between 2023 and 2026. Running out of capital appears in seventy percent of them, but they're explicit that this is the final cause of death rather than the root problem. The telling causes underneath are poor product-market fit at forty-three percent, bad timing at twenty-nine, and unsustainable unit economics at nineteen.
The detail worth sitting with isn't the headline number. Two-thirds of the product-market-fit failures were early-stage companies that never found a market at all. But twenty of them were Series B or later. Those companies had raised on early traction that never widened into a real market.
That's the shape of the problem. An understanding gap doesn't announce itself when you make it. It announces itself one or two funding rounds later, when the product meets the users who weren't in the original brief. The median company in that dataset died twenty-two months after its last raise.
Three groups who needed different things
Before I started A Stronger Idea Design, I was Head of Design at Kiru, and one of the first ten people there. We were building a payroll platform for Latin America, across Costa Rica and Colombia, and it had the full set of conditions I've been describing.
Three groups depended on it and none of them wanted the same thing. Employees wanted to understand their own pay. Employers and managers wanted compliance to stop being frightening. Utility providers wanted to actually get paid on time. The business model only worked if all three got something real, because the discount employees received was funded by the reliability providers gained, and both ran through the employer's payroll.
None of that is visible from inside a single feature. All of it determines what the features have to be.
What the mapping actually surfaced
We ran research in quarterly cycles for two years. Interviews in Spanish and English, in person and remote, in both markets. Surveys. Behavioral analytics. Not a discovery phase that ended, but a habit.
Three things came out of it that we wouldn't have guessed.
Employees didn't distrust payroll in the abstract. They distrusted it specifically, because of unclear deductions and overtime they couldn't verify, and many of them checked their pay stubs repeatedly against past experience of being shortchanged. That turned transparency from a nice quality into a structural requirement. Every calculation had to be inspectable.
Compliance wasn't an employer inconvenience. It was the thing keeping them from switching. Around seventy percent of the business owners we spoke to struggled with tax codes, and most of the accountants named automatic government submission as their main pain point. That moved compliance from a feature we'd get to into a reason the product could exist.
And localization wasn't a translation task. Labor law, social security, tax thresholds and cultural expectation all differed between the two countries we were already in. Which meant the architecture had to be modular from the first decision, not adapted later. We got that one right, and it's the single decision I'm most glad we made early.
The work landed. Zero to more than nine thousand users and four hundred corporate clients in under two years, with an NPS of eighty.
The mistake I made anyway
Here's what I'd do differently, and it's the reason I'm telling this story rather than a tidier one.
We mapped the entire ecosystem, and then we built the entire ecosystem. Three products at once. An employee app, a manager app, and a dashboard for employers and accountants. It produced something genuinely coherent, and it stretched us badly. It also meant that if we'd been wrong about the business model, we'd have discovered it with everything already built.
For a long time I read that as an argument against mapping so much. It isn't. The mapping is what made the localization call correct, and that call is the reason we could enter a second country at all.
What I actually got wrong was treating the map as a build order.
Understanding isn't scope
These are two separate decisions and it's very easy to run them together.
Map wide. You need to know who depends on this, where their work crosses, what each of them is accountable for, and which constraints are real. That knowledge is cheap relative to what it prevents, and it doesn't commit you to anything.
Build narrow. Pick the smallest piece that proves the model works, and build that one properly. The map tells you which piece that is, and it tells you what not to foreclose while you build it.
A team that maps wide and builds wide has bought coherence at the price of optionality. A team that maps narrow and builds narrow moves quickly toward something that may not hold. The combination worth having is the one that gets the architecture right and the commitment small.
That isn't a compromise between speed and rigor. It's what makes the speed safe to use.
The question worth asking before the first sprint
If you're about to start building something with several kinds of user, or interlocking workflows, or regulatory exposure, the question isn't whether you've done enough research.
It's this: have you mapped the whole ecosystem, or have you mapped the part of it you already understand?
Most teams have mapped the part they already understand. That isn't a failure of effort. It's what happens by default, because the users you know best are the ones who are easiest to talk to, and the constraints you've met before are the ones you remember to ask about.
If the answer is the second one, the cost of that isn't zero and it isn't immediate. It arrives later, in the form of decisions that turn out to have been made on an incomplete picture, embedded in everything built on top of them.
What it's actually worth
Kiru closed. The single investor funding it exited over political and economic conditions in the markets we were expanding into, and the decision was made to shut down rather than pivot or sell. The product was working. That wasn't enough.
I've thought about that a great deal, and the lesson I take from it isn't about mapping. It's that design excellence doesn't guarantee business success, and that anyone leading design on an early-stage product should be asking about unit economics and regulatory risk and funding concentration far earlier than feels natural.
But the mapping still paid. It's why the product worked for three groups at once, why the second market was possible, and why the thing we built held together well enough that its ending had nothing to do with its quality.
Understand the whole system. Then choose, deliberately and narrowly, what to build first.
References
CB Insights, The top 9 reasons startups fail (March 2026), an analysis of 431 venture-backed companies that shut down since 2023. https://www.cbinsights.com/research/report/startup-failure-reasons-top/
Kiru: designing a connected payroll ecosystem for LATAM's workforce. https://erictomlinson.com/work/portfolio-kiru-latam-fintech-ux
