By playing, you agree to uListen's Terms and Privacy Policy and YouTube's Terms of Service.

Lenny's Podcast

Hard-won lessons building 0 to 1 inside Atlassian | Tanguy Crusson (Head of Jira Product Discovery)

Tanguy Crusson is the product lead for Jira Product Discovery at Atlassian. In his more than 10 years at the company, he has been instrumental in taking several new products from zero to one, including HipChat, Statuspage, and Jira Product…

Tanguy CrussonguestLenny Rachitskyhost

Jun 16, 20241h 54mWatch on YouTube ↗

Summaries, chapters, transcripts, and FAQs on this page are made by uListen, not YouTube.

CHAPTERS

Jump to publisher timestamps

Chapter summaries

Tanguy’s decade at Atlassian: repeated zero-to-one swings (and a 50/50 record)
Tanguy lays out his 10-year journey inside Atlassian building new bets: marketplace ecosystem work, HipChat/Stride, IT ops exploration, Statuspage integration, and ultimately Jira Product Discovery. He frames the episode as candid “therapy” about what actually makes internal innovation hard, even with strong distribution and resources.
- •Worked across multiple internal bets: HipChat/Stride, Statuspage integration, Jira Product Discovery
- •Started Atlassian’s cloud developer ecosystem/marketplace angle
- •Admits a mixed track record and normalizes failure rates for internal innovation
- •Sets expectation: real talk about what went wrong/right building 0→1 in a big company
Why zero-to-one is uniquely hard in big companies (despite huge advantages)
They contrast Atlassian’s structural advantages—massive customer base, resources, research access—with the realities that slow or kill new bets. Tanguy explains how high expectations, mismatched metrics, and premature scaling pressure suffocate early-stage products.
- •Large companies have breadth, customers, and support functions that startups dream of
- •The success bar is extremely high (e.g., $100M is “a good start”)
- •Early bets get judged with mature-product metrics (e.g., MAU) that don’t fit
- •You need processes/metrics that create breathing room for incubation
HipChat’s rise: early market lead, then “Go Big” growth pressure
HipChat began as a beloved, early chat product acquired by Atlassian, with strong startup traction before Slack emerged. As Slack’s momentum surged, Atlassian tried to scale HipChat aggressively, growing the team rapidly and forcing changes onto a product and platform not ready for that pace.
- •HipChat was acquired with strong early traction and product love
- •Slack’s rapid growth changed the competitive context overnight
- •“HipChat Go Big/Next Gen” expanded headcount and scope dramatically
- •Scaling the team exposed platform limits and tech debt
The rewrite trap and losing the timing window (Stride, Teams, and exit)
The team decided to rewrite HipChat to address tech debt and build a reusable platform—ultimately producing Stride. By the time the rewrite landed, Slack was far ahead and Microsoft Teams entered with distribution advantages, leading Atlassian to exit the market and sell HipChat/Stride to Slack.
- •Decision to rewrite (and platformize) created major delay and risk
- •Stride emerged from “HipChat Next Gen,” but market moved faster
- •Microsoft Teams’ bundling/distribution changed the game further
- •Atlassian ultimately sold HipChat/Stride to Slack and exited the space
Hard lessons from HipChat: assumptions, segment mismatch, and competitive myopia
Tanguy breaks down the strategic mistakes: over-believing Atlassian’s existing playbook would transfer, and not validating cross-segment adoption dynamics. He warns against feature-chasing competitors and emphasizes anchoring on user research rather than reacting to competitor releases.
- •“Don’t eat your own bullshit”: past success playbooks can mislead future bets
- •Segment mismatch: developers vs. business users drove divergent adoption
- •Slack’s UX/onboarding and “consumerization” wave mattered more than expected
- •Competitive myopia: feature-reaction is shallow compared to competitor’s deeper research
Scarcity beats abundance: why big-company over-investment can slow you down
A core insight is that startups benefit from being “starving,” while large companies over-invest and over-optimize too early. HipChat’s rewrite paired product goals with platformization goals, which created drag; the better approach is to win the problem space first, then platformize later.
- •Startups move fast because scarcity forces focus and speed
- •Big companies can slow bets by pulling them into platform/standards too early
- •Doing product rewrite + platform build simultaneously is often too much
- •Hack/validate first; platformize after value is proven
Statuspage and the IT-ops opportunity: discovering a collaboration wedge
Tanguy shares the IT operations context—cloud migration and DevOps—and how incidents create chaos across teams. Statuspage’s simple promise (transparent customer communication during outages) aligned with Atlassian’s strength in collaboration around work and incidents.
- •DevOps shift: developers owning production/on-call increased incident pressure
- •Incidents create cross-functional chaos (support, sales, leadership, customers)
- •Statuspage reduces load by communicating proactively and building trust
- •Atlassian explored where it could play in IT ops alongside vendors like PagerDuty/Opsgenie
Acquisition integration reality: culture shock, process drag, and “Frankenstack” risk
The Statuspage story becomes a lesson in acquisition integration: technology is often easier than people and process. Startups lose autonomy, face long-range planning expectations, and get pulled into functional org structures; without care, acquisitions create disconnected product stacks customers dislike.
- •Integration is mostly about people/culture, not just product or tech
- •Startups face roadmap/time-horizon mismatch (3 months vs 3 years)
- •Org structure introduces silos and new rituals (OKRs, forecasts, performance cycles)
- •“Frankenstack” danger: mismatched identity/stack creates patchwork experiences
Build vs. buy vs. partner—and when to treat acquisition like hiring
They explore how Atlassian decides between building, buying, or partnering, and how acquisition intent changes integration strategy. Tanguy argues smaller tuck-ins often work best when treated like hiring (acqui-hire), rebuilding on the platform to accelerate roadmap without rebuilding “mid-flight.”
- •Different acquisition modes: keep product running vs rebuild on platform
- •Treat small tuck-ins like hiring to set expectations and support integration
- •Rebuild after acquisition can be fine when you’re “delaying takeoff,” not changing a flying plane
- •Clear rationale: buying speed (entering a market a year earlier can pay back)
The ‘why now’ missing ingredient: great work stuck in limbo
Tanguy recounts pitching an IT-ops expansion business case that got enthusiasm but no decision—months of ‘no yes, no no.’ The post-mortem: in opportunity-rich companies, ideas sit on shelves unless someone clearly articulates the urgency trigger—why this must happen now versus later.
- •Big-company limbo: encouragement without commitment is common
- •Opportunity abundance means many valid ideas still won’t be prioritized
- •You must articulate a strong ‘why now’ trigger in the business case
- •Recognize when you’re idle and step back instead of endlessly pushing
Jira Product Discovery’s origin: Point A incubator and the long-game commitment
Jira Product Discovery became possible through Atlassian’s Point A incubator, created to rebuild the ‘innovation muscle.’ Point A provided budget, psychological safety, access to internal resources, and a long time horizon—JPD spent years in alpha/beta before GA.
- •Point A emerged from founder push to build (not only acquire) new products
- •Incubator benefits: dedicated time, protected staffing model, access to research/corp dev/analysts
- •3-year pre-GA incubation (alpha/dogfooding/beta) with organizational support
- •Early demand validation tactics (e.g., waitlist-style signups) inform confidence
Operating principles for incubation: assume failure, create scarcity, protect autonomy
Tanguy insists ‘failure is the most likely outcome’ should be the framing to prevent premature over-investment and interference. Scarcity and autonomy enable teams to hack, learn quickly, and avoid getting pulled into slow platform negotiations before the concept is validated.
- •Explicitly frame new bets as likely to fail to avoid over-investment
- •Create scarcity to emulate startup urgency inside a well-resourced org
- •Keep the rest of the org from slowing you with conditions and process
- •Hack/iterate quickly (even if it doesn’t scale or meet standards yet)
Point A’s execution model: Wonder → Explore → Make → Impact, with real gates
Tanguy explains Point A’s four stages and how shared vocabulary sets expectations across the company. Progression is gated via written six-pagers and review meetings with Point A stakeholders and founders; bets can advance, get extended, get rolled into existing products, or be killed.
- •Wonder: validate problem/market, Atlassian fit, and ‘why now’
- •Explore: validate solutions via prototypes and user playback (often pre-code)
- •Make: staged build with alpha → beta; Impact: GA readiness and business monitoring
- •Gating uses a six-pager + founder/stakeholder Q&A; outcomes include extend/kill/roll-in
Breaking rules without breaking trust: ‘pirate’ execution to move fast
To go fast, the team had to bend Atlassian norms—staffing senior/principal engineers, using contractors, and even operating from Europe to reduce organizational pull. The key is spending accumulated trust (‘chips’) carefully so that rule-breaking serves speed and learning, not ego or recklessness.
- •Early bets often require rule-breaking because mature-product rules don’t fit
- •Spend ‘trust chips’ deliberately; aim to break rules without eroding credibility
- •Tactics: senior autonomous engineers, contractors, unusual leadership structure
- •Physical/organizational separation helped preserve speed and reduce interference
Customer strategy that avoids collateral damage: incubate/iterate/integrate + safety funnel + lighthouse users
JPD needed to innovate inside Jira without disrupting millions of existing users, so they created a separate experimental ‘pocket’ and limited exposure. They used the ‘safety funnel’ approach and formalized success metrics around a Lighthouse Users program (10 → 100 → 1,000) with qualitative evidence and tight feedback loops.
- •Use ‘incubate → iterate → integrate’ to innovate safely inside a mature product
- •Safety funnel: cap early exposure to limit bad experiences and churn
- •Lighthouse Users program: define staged success (10/100/1,000) instead of MAU pressure
- •Deep customer intimacy turns engineers into ‘product engineers’ via empathy and shared context
Protecting the ‘ugly baby’: internal comms, momentum, and visible learning velocity
To keep the bet alive through long uncertainty, Tanguy treated internal communication as a core job. Weekly bite-sized updates, demos, and short customer video snippets created a perception of speed and learning, making it harder for stakeholders to prematurely kill or constrain the work.
- •Internal comms as a defensive moat: clarity, honesty, and frequent updates
- •Show velocity with weekly demos and consumable customer snippets
- •Balance qualitative stories with data to engage both ‘heart and mind’
- •Timeline markers: dogfood in ~2 months; first lighthouse user ~5 months; alpha ~6 months; beta ~1 year
Closing advice: choose environments that let you innovate—and protect your well-being
Tanguy closes by warning that pushing for change is only sustainable in environments that allow it; otherwise cynicism and self-doubt creep in. He advocates seeking teams and cultures that bring out your best, and remembering you only get one work life.
- •Innovation requires psychological and organizational safety; not all workplaces have it
- •Don’t become the ‘only sane person in the room’—the environment changes you
- •Balance pushing for change with self-protection and realistic constraints
- •Transition to lightning round and personal reflections on meaning, work, and life

Publisher timestamps

Get more out of YouTube videos.

Read along on your phone, search it beside the video, or ask your favorite AI app what was said.