Notes — Tanguy Crusson on Incubating New Products, the Point A Framework, and Protecting Ugly Babies

Four questions [Adler frame]

Q1 — What is it about? A case study in zero-to-one product work inside a large company. Tanguy Crusson ran HipChat’s decline, extracted its failure modes, then used those lessons to build Jira Product Discovery — one of Atlassian’s fastest-growing products. The episode covers: what went wrong with HipChat (three interacting errors); how Atlassian institutionalised its response (Point A); how JPD actually developed (four years, 10 customers to 8,000); and the practical tactics for keeping a new bet alive inside a resource-rich, process-heavy organisation.

Q2 — How is it argued? Structurally: negative case (HipChat) → institutional response (Point A) → positive case (JPD). Tanguy draws on specific operational detail — named stages, gate formats, customer expansion bands, internal communication cadences. He also uses outside references (Christensen on disruption, Amazon six-pager, Noah Weiss’s incubate–iterate–integrate pattern) to situate Atlassian’s approach in broader practice. The argument is first-person and specific rather than abstract.

Q3 — Is it true? The HipChat diagnosis is credible — Crusson ran the team and describes the decisions from inside. The Point A framework is well-specified and has produced at least one verifiable success (JPD). The “why now” argument is structurally sound: a technically valid opportunity that lacks an urgency case will be perpetually deferred. The internal comms tactics (weekly tweet, customer snippets) are concrete and adoptable.

Q4 — What of it? Point A’s four stages offer reusable vocabulary for any company attempting to incubate within an established organisation. The Lighthouse Users Program and safety funnel are directly adoptable. The failure-first framing (deliberately communicating a 70% failure probability) is a genuine operational insight: it shapes how the rest of the organisation treats the team. The “don’t eat your own bullshit” principle is the sharpest summary of survivorship bias in product strategy.

Glossary

Point A. Atlassian’s formal new-product incubation framework. Four stages: Wonder (prove market entry is worthwhile and articulate why now), Explore (validate solutions with customers before writing code), Make (alpha → beta → GA), Impact (monitor and grow the business). Each stage has distinct success criteria; teams communicate their stage to the broader organisation using shared vocabulary.

Wonder stage. First gate in Point A. Two questions: is there a market worth entering? Why should Atlassian enter it now rather than later? The second question is harder; teams that cannot answer it often get their pitch parked indefinitely.

Explore stage. Second gate. Validate solution concepts with customers — primarily in Figma — before writing production code. The stage ends when a team has sufficient customer confirmation to justify building. Teams in Explore are not expected to have production architecture reviews.

Make stage. Third gate. Alpha (handful of known customers, success criteria explicit) → beta (wider access, explicit criteria) → generally available. Each sub-stage has a gate.

Impact stage. Fourth gate. Monitor the business: acquisition, activation, retention, expansion. Teams at Impact are integrated back into the normal product organisation.

Lighthouse Users Program. Staged customer expansion: 10 known customers (by name), expand to 100, then 1,000. Each band has explicit success criteria agreed in advance. Engineers interact directly with lighthouse customers — ‘product engineers’ in Crusson’s term.

Safety funnel. Hard cap on early users to prevent a bad first experience that is difficult to reclaim. The cost of a poor experience with a new product compounds: users form a durable negative association and are hard to re-engage.

Don’t eat your own bullshit. Crusson’s synthesis of Atlassian’s ‘no bullshit’ value and the practice of dogfooding. The warning: experience confirming your past playbook is the most dangerous form of bias because it feels like evidence. HipChat’s team assumed the Atlassian developer-adoption engine would work the same way for business users. It did not.

Competitive myopia. Reacting to a competitor’s visible features without understanding the user research and strategic decisions underneath them. The result: building yesterday’s product while the competitor has moved to the next one. HipChat fell into this after Slack gained mindshare.

Six-pager. Amazon-originated document format for major decisions. Six pages, read silently by all participants for 15 minutes before discussion begins; no slide decks. Atlassian adopted this for Point A gate reviews: founders and leadership read in silence, then question.

Incubate → iterate → integrate. Pattern for new-product development within a platform company — first isolated from organisational process, then iterated independently, then integrated into the platform once successful. From a Noah Weiss article.

HipChat: three failure modes

Three interacting errors, each independently damaging, compounding when combined.

Competitive myopia. When Slack began dominating mindshare, HipChat reacted feature by feature — implementing what was visible on Slack’s product surface without understanding the research and decisions underneath. The competitor’s current features represent the visible tip of an iceberg: 12+ months of user research and strategic choices invisible from outside. Reacting to features means permanently fighting last year’s product. HipChat abandoned depth in developer tooling integrations — the thing that actually made it distinctive — without meaningfully closing the consumer-grade experience gap that made Slack sticky.

Segment misjudgement. Atlassian’s adoption engine routed through developer users who championed products upward into IT and management. The assumption was that the same mechanism would work for messaging: developers adopt HipChat, push it into business teams. Business users had fundamentally different criteria — emoji, polish, modern UI, consumer-grade emotional design. HipChat had not invested in these. The assumption was never validated before the bet was made.

The rewrite trap. Atlassian’s engineering depth made a simultaneous platform rewrite attractive: rebuild HipChat on microservices so the chat editor could be reused across all Atlassian products. Rebuilding the plane in flight while fighting a market leader and validating a new user segment was too much load. The code did survive (70% is still in the Atlassian platform today), but for HipChat specifically the rewrite cost time it could not afford.

Crusson distils the lesson as: don’t eat your own bullshit. The most dangerous assumption is that the playbook that made you successful before will make you successful again, because you have direct experience confirming it.

Point A: the framework

Atlassian built Point A as a formal institutional response to HipChat’s failure — an attempt to rebuild the new-product muscle. Three things it provides:

Psychological safety. Teams borrow people from other departments; no one’s job is at risk if the bet fails. Point A decouples personal risk from product risk.

Company resources. Research capability, corporate development, analyst relationships, design standards — a small team can access infrastructure a startup could not afford.

Shared vocabulary. Wonder/Explore/Make/Impact are known across the organisation. A team that says “we’re in Explore” communicates their stage without negotiating what that means each time. The rest of the organisation knows not to expect production architecture reviews or full marketing support.

The gate from Explore to Make uses a six-pager reviewed in silence. Founders and product leadership sit in the room; participants read for 15 minutes before anyone speaks. This prevents the slide-deck problem: no one can charm their way through a reading exercise.

Of roughly 100 pitches in the first cohort, three products made it through all four stages. JPD was one.

Jira Product Discovery: the journey

Four years from Crusson’s solo research to general availability. The timeline:

Research phase: Crusson identified that PMs had no native tool for managing what to build. Discovery work lived in Confluence, Trello, sticky notes. Atlassian had everything except the tool for the decision itself.
Wonder gate: Crusson pitched a market entry case. An earlier pitch (Jira for IT operations) was enthusiastically received but parked — the team could not articulate why Atlassian had to enter that market now. The JPD pitch had a why-now.
Explore stage: Ran almost entirely in Figma. Concepts were validated with potential customers before a line of production code was written.
Alpha: First lighthouse user at five months. Stayed in alpha for six months iterating with roughly 10 known customers.
Beta: Close to a year. Expanded to ~100 customers.
Make to GA gate: A founder (Mike Cannon-Brookes) rejected the GA push — the product was functional but visually below Atlassian’s design standards. Two to three months of design work followed. Then GA.
GA outcome: 8,000 customers, strong CSAT, one of the fastest-growing products in Atlassian history.

The Lighthouse Users Program

Crusson’s staged expansion model for early customers:

Band 1 — 10 customers. Known by name. The team knows them individually. Success criteria defined in advance (what does a successful alpha experience look like?). Engineers attend customer calls — this is how engineers become ‘product engineers’, developing intuition for user problems rather than just implementation.

Band 2 — 100 customers. Criteria agreed before expansion. Failure to meet Band 1 criteria means no expansion.

Band 3 — 1,000 customers. Pre-beta scale. At this point the product is learning from a genuinely diverse user base.

The safety funnel operates throughout: a hard cap on total users. The cost of a bad first experience compounds — users form a durable negative association with a new product, and reclaiming their attention is substantially harder than acquiring a new user. Better to have 10 delighted customers than 100 neutral ones.

Protecting the ugly baby: internal comms as shield

A new product in a large company is under continuous pressure from organisational processes designed for mature products: architecture reviews, legal review, marketing alignment, security review. Each is individually reasonable; collectively they kill new bets.

Crusson’s tactics for insulation:

Weekly Atlas updates. Atlassian’s internal project tool (Atlas) allowed weekly tweet-sized updates. Crusson published every week. Hundreds of people subscribed. The effect: the product became legible to the organisation without requiring anyone to read a research report.

Customer video snippets. Three-minute clips of customers discussing their problems and early reactions to the product, shared on Slack. No one reads a 30-page research report. Everyone watches a three-minute video of a real person describing a real frustration.

Demo cadence. During the alpha phase, a weekly product demo — sometimes saving a feature specifically to ensure a constant forward motion visible to the organisation.

The high-speed train frame. Crusson’s internal narrative: this thing is moving. No one wants to step in front of a fast-moving train. The effect is that the cost of opposing the bet rises relative to the cost of ignoring it or supporting it.

Failure framing. Deliberately communicate that the bet has perhaps a 70% chance of not existing in six months. This is not defeatism — it is a firebreak. Once a product is framed as possibly temporary, the organisation stops imposing permanent-product processes on it.

Why now is the hardest question

Many technically valid opportunities sit on shelves indefinitely because the urgency case is never made. Atlassian’s IT operations opportunity was enthusiastically received — the analysis was good, the market was real — but parked for a year because no one could articulate why Atlassian had to enter now rather than next year.

Crusson’s test: a strong pitch can answer the question “what happens if we don’t do this in the next 12 months?” A weak pitch cannot.

The why-now case requires identifying a specific window: a technology inflection, a competitive opening, a regulatory change, an adjacent product’s maturity creating a natural expansion. Without it, the correct decision from the approver’s perspective is always to defer.

Environmental fit

Crusson’s closing observation is deliberately un-heroic: some environments are not safe for this kind of work, and recognising that is not failure.

At Atlassian he found a company that rewarded rule-breaking within the right channels, tolerated ambiguity for long enough to let bets develop, and did not conflate headcount stability with job security. He had worked in banks and regulated industries where none of these conditions held and where pushing would have gone badly.

The advice: surround yourself with environments that bring out the best in you. Cynical environments permeate. He was cynical in a cynical place and decided deliberately not to be. Changing the environment was easier than sustaining a counter-culture against it.