Hard-won lessons building 0 to 1 inside Atlassian | Tanguy Crusson (Head of Jira Product Discovery)
Executive Summary
Tanguy Crusson describes audience assumptions, early demand tests, customer focus, platform scope and honest communication of learning. Selected third-party transcript coverage excludes acquisitions, financial figures, hiring, health language, forecasts and sponsor reads. Company examples are his retrospective accounts, unverified here. Untimed editorial topics are not video chapters.
Key Takeaways
Check whether distribution reaches the right users
Crusson says a large installed customer base does not automatically mean a new product serves the same people or needs. His HipChat account includes an assumption about expanding from technical to business teams. Test the audience fit rather than treating existing distribution as proof of demand.
Test an assumption before building around it
In his Jira Product Discovery account, the team tested interest with a newsletter message and a website before building the product. The point was to learn whether interested users could be reached. Interest is a useful early signal, not proof that a finished product will succeed.
Do not let competitors replace customer research
Crusson describes reacting to competitor features as a way the team lost focus on serving some users well. He notes that a shipped feature is only the visible result of another team's research and thinking. Copying that surface does not reproduce the understanding behind it.
Bring customer needs back into the discussion
He recommends separating the creative and research process from constant competitor reaction. When an announcement draws attention, the team can return to the problems its own users describe. This is a focus discipline, not a claim that competitors should never be observed.
Solve the problem before building a reusable platform
Crusson reflects that trying to rebuild a product and create reusable platform pieces at the same time added complexity. His alternative is to test and iterate with customers, then make successful parts reusable later. The account illustrates a scope trade-off rather than a universal rule against platform work.
Judge a new bet differently from an established product
He explains that early-stage work can have small user numbers while the team is still learning what should be built. Applying the same success measures as a mature product can conceal that stage difference. State what the current work is trying to learn before judging it by scale alone.
Communicate learning without inflating progress
Crusson describes weekly communication grounded in what the team was testing, data and customer stories. He says to be honest about where the work stands rather than make it appear more successful. A progress report can show motion while preserving the uncertainty that still matters.
The Conversation Breakdown
Check whether distribution reaches the right users
⏱ Untimed topicCrusson says a large installed customer base does not automatically mean a new product serves the same people or needs. His HipChat account includes an assumption about expanding from technical to business teams. Test the audience fit rather than treating existing distribution as proof of demand.
Test an assumption before building around it
⏱ Untimed topicIn his Jira Product Discovery account, the team tested interest with a newsletter message and a website before building the product. The point was to learn whether interested users could be reached. Interest is a useful early signal, not proof that a finished product will succeed.
Do not let competitors replace customer research
⏱ Untimed topicCrusson describes reacting to competitor features as a way the team lost focus on serving some users well. He notes that a shipped feature is only the visible result of another team's research and thinking. Copying that surface does not reproduce the understanding behind it.
Bring customer needs back into the discussion
⏱ Untimed topicHe recommends separating the creative and research process from constant competitor reaction. When an announcement draws attention, the team can return to the problems its own users describe. This is a focus discipline, not a claim that competitors should never be observed.
Solve the problem before building a reusable platform
⏱ Untimed topicCrusson reflects that trying to rebuild a product and create reusable platform pieces at the same time added complexity. His alternative is to test and iterate with customers, then make successful parts reusable later. The account illustrates a scope trade-off rather than a universal rule against platform work.
Judge a new bet differently from an established product
⏱ Untimed topicHe explains that early-stage work can have small user numbers while the team is still learning what should be built. Applying the same success measures as a mature product can conceal that stage difference. State what the current work is trying to learn before judging it by scale alone.
Communicate learning without inflating progress
⏱ Untimed topicCrusson describes weekly communication grounded in what the team was testing, data and customer stories. He says to be honest about where the work stands rather than make it appear more successful. A progress report can show motion while preserving the uncertainty that still matters.
Core Frameworks & Ideas
Audience-assumption check
Ask whether existing distribution reaches the people and problems a new product is meant to serve.
Problem before platform
Test and iterate on the user problem before adding the work of making the solution broadly reusable.
Learning-centered update
Report the question being tested, the evidence so far and what remains uncertain, using data and customer stories.
Actionable Next Steps
- ✓Name the audience assumption behind a new product.
- ✓Design an early demand check without claiming it proves success.
- ✓Compare a competitor reaction with an actual customer problem.
- ✓Write a progress update that separates learning from proven outcomes.
Notable Quotes
“We need to make sure that people have a problem, we solve this problem.”
“Being super honest every step of the way, not try to make shit up and try to make it bigger than it is, more successful than it is.”
“Doing that with data, doing that with personal customer stories because we all can constantly relate to the heart and to the mind.”
The One Thing to Remember
Make clear what the team is testing and learning instead of presenting early activity as proven success.