There is a stubborn belief in the startup ecosystem: large companies are slow, bureaucratic, and have nothing to teach teams that “move fast and break things.” Move fast. Ship fast.
I have worked on both sides. AXA, ADP, Dassault Systèmes, Volkswagen on one side. Startups sprinting at full speed on the other. Over time, one thing became very clear.
Many startups confuse speed with motion.
The myth of startup velocity
When a startup says it moves fast, it often means something else: features go into development while the need is still fuzzy, metrics are incomplete, documentation is minimal, and key decisions are made on instinct or based on the latest voice heard in a meeting.
The result is an unstable roadmap, tech teams reworking the same topics, PMs stuck between leadership requests, fragile specs, and growing bug backlogs. This is mostly a problem of dispersion.
Large organizations have often paid dearly for a lack of product clarity. That explains many of their guardrails. Some went too far into process overhead. Others simply built strong habits. Those are the ones worth learning from.
Lesson 1: do not launch before clarifying
In strong organizations, a feature does not enter development without minimum framing. Nothing heavy. Just enough to answer three questions clearly: what problem are we solving, for whom, and how will we know it works?
Startups skip this step because it “takes time.” But whatever they gain in the short term, they repay many times over in rework, redesigns, and disagreements about “what we actually wanted to build.”
Framing does not slow a product down. It mostly prevents running in the wrong direction.
I once saw a six-person team spend two sprints on a feature, only to discover in demo that the CEO expected something entirely different. Two weeks lost. The initial framing probably needed two hours.
Lesson 2: decide with data, not opinions
Large organizations have a well-known flaw: they measure everything, sometimes producing unreadable dashboards. Even so, the core reflex is healthy: before major product decisions, they seek evidence in data.
By contrast, many startups launch quickly and measure late — or poorly. And when one metric is tracked, it is often flattering rather than truly useful for understanding whether the product creates value.
A/B tests, activation funnels, retention cohorts: these tools are not reserved for highly structured companies. They become useful very early, as soon as a team agrees to replace part of its intuition with observation.
The challenge is that measuring requires defining in advance what to measure. That forces thinking before acting. It is uncomfortable for teams used to constant speed.
Lesson 3: what is not documented does not exist
Here is a scene I have seen more than once: a CTO joins a Series B startup and spends the first weeks rebuilding how the product really works. Not the narrative version. The real one: architecture choices, UX decisions, integrations, constraints.
And they find almost nothing. Everything sits in the heads of two or three people who are, unsurprisingly, the busiest on the team.
Large companies document more because they learned that undocumented knowledge quickly becomes operational risk. When a key person leaves, they often take part of the decisions, context, and trade-offs with them. At Dassault Systèmes, where I spent four years leading digital transformation, product documentation was not optional. At that scale it was normal operating practice: it enabled teams across continents to build on the same platforms without colliding.
In a scaling startup, the issue accelerates. You hire fast, people rotate, teams expand. Without documentation, every onboarding is a huge time sink, every decision gets reinvented, every bug becomes an archaeological investigation.
Then AI arrived, and the excuse disappeared
Until 2022, one could argue documentation was expensive in human attention and required trade-offs between building and writing. That was a real debate. Not anymore.
The marginal cost of documentation dropped sharply. A framing meeting? Granola, Fathom, or tl;dv gives you structured notes without anyone typing. A technical integration to document? Cursor or Claude Code can generate a usable first draft from the code itself in minutes. A PRD to write? Start with three bullet points, AI structures the document, then you review and complete it. A doc base no one can search? Notion AI or Glean makes it queryable in natural language.
What used to take an hour now takes ten minutes. What required a scribe’s discipline now requires an editor’s discipline.
Documentation is product work. It is one of the conditions for growing a team without losing coherence. So when a founder or CTO says, “we do not have time to document,” I hear something else: “we do not want to spend ten minutes reviewing what AI produced.” Today, this is more an organizational choice than a true time constraint.
One caveat: AI does not decide what should be documented, how information should be prioritized, or who needs it. AI helps produce faster. Information hierarchy remains human work. That is exactly the part that creates value. Running ChatGPT on a meeting is not enough. But having no excuse left for producing documentation is already a major shift.
Lesson 4: product governance must be built before it becomes urgent
In large organizations, decision authority over product is usually treated explicitly. Circuits are not always elegant, but roles, responsibilities, and arbitration paths exist.
In startups, this question is often postponed until it turns into a crisis. While the team is small and everyone talks daily, it works. But once you reach 20, 30, 50 people — multiple product teams, multiple squads, multiple stakeholders — lack of governance becomes toxic.
I spent two years at Groupe ADP leading the Smart Airport transformation, with one non-negotiable milestone ahead: the Paris 2024 Olympic Games. When you prepare a globally watched event with dozens of stakeholders — operations, security, IT, business teams, technology partners — and a deadline that will never move, you learn something quickly. Without clear governance, no one arbitrates. And when no one arbitrates, reality decides for you — usually at the worst moment.
What we set up at ADP was not committee theater. It was a minimal but explicit framework: who decides the roadmap, who arbitrates between two use cases competing for the same resources, who can say no (and to whom), who validates that a product is ready for production in a critical environment. Once these questions were answered, teams stopped wasting energy in endless discussions and focused on delivery.
In startups, these questions arrive later — but they do arrive.
If no one can clearly answer these questions in your organization, you have a governance problem. And it grows as you scale. The good news: useful governance does not need to be heavy. It just needs to be explicit.
An important nuance
Nothing here is about turning startups into large corporations. Corporate process bloat, three-hour committees that decide nothing, cascading approvals: all of that is real — and fatal for startups.
What interests me is the original intent behind these mechanisms before they became caricatures. Frame, measure, document, govern: these habits are worth reclaiming, simplifying, and adapting to the reality of a team that is accelerating. That is how you sustain speed over time instead of burning it out in a few quarters.
The 4 habits worth reclaiming
- Frame before development: 3 questions, 1 page, 2 hours. Not a 40-page spec.
- Measure with 2 or 3 actionable metrics from launch, not 200 KPIs six months later.
- Document continuously: AI removed the time excuse. What remains is editorial discipline.
- Govern explicitly: who decides what, written down before crisis forces the question.
