Zero-to-One Inside an Enterprise Is Its Own Sport

5 MINS

I've done zero-to-one in startups (ZipGo, Health & Glow's eCommerce build) and zero-to-one inside large enterprises (Indeed Flex's first client-facing API, the messaging vision I drove for 12 months). They look similar from the outside. They are very different sports. Anyone moving between the two needs to rewire their default moves, or they'll lose the launch.

In a startup, you ship to discover. In an enterprise, you align to ship.

The startup zero-to-one rhythm is: spike a build, put it in a few users' hands, see what survives, kill what doesn't. Discovery happens through shipping. Speed is the strategy.

In an enterprise, that rhythm is dangerous. A scrappy spike can accidentally collide with five existing teams, two compliance frameworks, and a customer SLA. So the rhythm flips: you align first, then ship a smaller-than-you'd-like first version that respects all the surrounding constraints.

The mistake I made early at Indeed Flex was importing startup pace into an enterprise context. The team built fast. The launch stalled because three groups I hadn't talked to had legitimate concerns, and they were right.

The fix wasn't to slow down the build. It was to front-load the alignment so the build, when it happened, was uncontroversial.

The "seven yes" rule

For any enterprise zero-to-one, I now keep a quiet running list: who are the seven people whose 'yes' I need before launch day? Not approvals — actual yeses, where they nod along in the room.

Typical list at Indeed Flex:

The legal/compliance lead.

The data privacy reviewer.

The platform engineering manager whose API I'm extending.

The customer success lead for the affected segment.

The security architect.

The relevant client's account manager (yes, externally too).

The exec sponsor whose name will be on the launch comms. If any of those seven are still a "maybe" the week before launch, the launch will slip. Not might. Will.

What I learned shipping the Worker Status API

When we built the first client-facing API for Stord, the technical work was the easy half. The hard half was figuring out what the *contract* was — both literally (the API contract) and politically (the org contract about who owns the API after launch).

The lessons that transferred from startup-land:

Ship the smallest viable surface. One endpoint, one client, one clean use case. Don't generalise on day one.

Instrument before you optimise. Logging, error tracking, and rate-limiting from v0, even if nobody is hitting the API hard yet. The lessons unique to enterprise:

Name the owner publicly. The team that builds an API and the team that runs it forever can be different. Be explicit about who that is, on the launch doc.

Document the deprecation path. Sounds insane on day one. Save you twelve months later when a v2 conversation starts.

The mindset shift

The single biggest mindset shift between startup zero-to-one and enterprise zero-to-one is the role of *speed*. In a startup, speed is leverage. In an enterprise, speed without alignment is just risk in disguise.

That doesn't mean enterprises have to be slow. The fast enterprise teams I've worked with are obsessive about parallelising the alignment work — running compliance review, design review, and engineering scoping concurrently rather than sequentially. They look slow because they're talking a lot. They're actually faster because nothing blocks at the end.

I took that lesson into Health & Glow when I joined as the sole eCommerce PM, and again into Indeed Flex. The teams that move fast and ship clean are the ones that did the unglamorous alignment work in the first two weeks. They just don't talk about that part.

RAG Is a Product Design Problem, Not an Engineering Problem

Palak skipped presentations and built real AI products.

Palak Jain was part of the March 2026 cohort at Curious PM, alongside 17 other talented participants.