Hard-won lessons building zero to one inside Atlassian

Executive overview

Large companies have distribution, resources, and customers — yet new products still fail. The same advantages that make a big company powerful create drag: over-investment, process overhead, and assumptions that what worked before will work again.

Tanguy Crusson spent 10 years at Atlassian working on HipChat, StatusPage, and Jira Product Discovery. His 50/50 track record produced one major insight: the job of a zero-to-one team is to emulate a starving startup inside a company that isn't hungry.

Atlassian's internal incubator, Point A, gave structured cover to do that — but much of the real progress came from deliberate rule-breaking, radical customer proximity, and obsessive internal communication.

Why zero to one fails in large companies

• The bar for success is set by established products; a $100M business looks "cute" at Atlassian scale.
• Success metrics designed for mature products (monthly active users) destroy early-stage bets.
• Teams over-invest before validating core assumptions — the playbook that made the company successful gets applied to new markets without testing.
• Acquisitions slow down before they accelerate: culture shock, fragmented ownership, and process friction hit founders hard.
• Good ideas stall without a clear "why now" — urgency is not the same as opportunity size.

Lessons from HipChat

• Atlassian assumed its bottom-up playbook (win developers, spread to business) would work for chat. It didn't — Slack owned the business-user segment by focusing on delight, not function.
• Rewriting a live product while competing is almost always a mistake; the new product arrived too late, and Slack was miles ahead.
• Competitive myopia kills: reacting feature-for-feature to a competitor means you're copying decisions made a year ago, based on research you don't have.
• Every three months, watch what competitors shipped. The rest of the time, focus on user interviews.
• Don't build platform and product simultaneously at the zero-to-one stage. Prove the problem first, platformize later.

Lessons from StatusPage

• Acquisitions are mostly a people integration problem, not a technology problem.
• Acquired teams lose decision-making autonomy fast; every craft function now has a separate owner above them.
• The acquirer says "keep doing what you're doing" while dozens of teams interrupt to enforce process. Factor this slowdown into integration plans.
• Preferred next approach: acquire small, shut the product down, rebuild on the platform — treat it like a team hire that accelerates the roadmap by a year.

Building Jira Product Discovery: what worked

• Point A, Atlassian's internal incubator, created four named stages — wonder, explore, make, impact — with explicit success criteria at each gate. Everyone in the org knew the vocabulary, which set expectations and reduced interference.
• Frame the bet as likely to fail. This is not team psychology — it's a defensive tactic. It signals to other teams: don't invest in this yet, don't pull it into your roadmap, don't apply your standards to it.
• Create scarcity deliberately: a seven-person team should not drag the rest of the company in. Small team, contractors, based in Europe — the distance itself protected the team from interference.
• Operating from France meant Atlassian teams in Sydney didn't bother pushing back on decisions. Geographical separation bought autonomy.
• Break rules without breaking trust: spend accumulated social capital, be explicit about what you're doing and why, and maintain leadership support throughout.

The Lighthouse users program

• Work with exactly 10 named customers before exposing the product widely. Know their context, their problems, their names.
• Stages: 10 → 100 → 1,000, with different success criteria at each. Stakeholders understand where you are and what to expect.
• Expose engineers directly to those 10 customers. Engineers who know a user's specific problem become product engineers — they push back in planning meetings with user context, not just technical concerns.
• Qualitative evidence (video snippets, customer conversations) moves people more than CSAT or NPS. Share three-minute clips, not 30-minute research reports.
• Safety funnel: hard-cap exposure to early adopters until the product is ready. Churned users from a bad first experience are very hard to win back.

Protecting the bet internally

• Communicate weekly, every week. Use bite-sized updates: a demo, a metric, a customer story. Don't go silent for months and then show a summary.
• Save features to show at a consistent weekly cadence; manufacture visible momentum.
• "No one wants to fight a high-speed train" — consistent velocity deters interference more than any argument.
• When stakeholders push back, show user interview snippets. Data defends against process; empathy defends against cancellation.
• The ugly baby phase ends not with a single moment but with the accumulation of consistent evidence over months.

When to push and when to leave

• Autonomous leaders who push for change need a company that is ready to welcome it. Without that, the environment will change you, not the other way around.
• Cynicism in bad environments is not a personal failing — it's contagion. Recognize it and act.
• Keep it about the work: whenever imposter syndrome or political noise rises, return to what needs to be built.