Starving on Purpose: What Atlassian Learned About Building New Products Inside a Giant

Crusson has spent about ten years in product management at Atlassian, mostly bootstrapping new things, including the cloud developer ecosystem, HipChat and Stride, work on IT operations, and most recently Jira Product Discovery. He describes his record as 50/50 at best, with Jira Product Discovery the first big success. Talking to product managers across industries later convinced him that 50/50 isn't bad.

On paper the opportunity is huge. Atlassian has some 300,000 customers from startups to large enterprises, a relatively flat decision-making culture despite a deep hierarchy, and in-house research and corporate development teams. For Jira Product Discovery he did not need to hunt for product managers, because they were already using Jira. A call in an addressable community group could produce hundreds of volunteers overnight.

The catch is the bar. At Atlassian, he says, a product with 100 customers looks cute, and a $100 million business is merely a good start, while elsewhere it would be a home run. For years every product was judged by the same metrics, such as monthly active users, even though an internal startup should show low usage until it is ready for the customers it wants. Without metrics and processes that give breathing space, bets struggle, and that is the gap the later incubator addressed.

HipChat was an acquisition of about twenty people that Crusson describes as Slack before Slack, popular with startups and a new way to collaborate. When Slack's growth became dizzying, Atlassian went from leaving the team alone to a large push, "HipChat Go Big," with many new developers, product managers and designers. The platform wasn't ready for that many people changing it, so they decided to rewrite. His advice now is blunt: never do a rewrite.

The rewrite produced Stride, a good product, but Slack was far ahead by the time it was ready, and Microsoft Teams then arrived with a bundling advantage. Atlassian sold HipChat and Stride to Slack and left enterprise communications. Crusson says failure "really sucks": after years of obsessing over every detail, the work stopped mattering overnight, and the team went through a few months of something like the seven stages of grief.

Crusson's main lesson is "don't eat your own bullshit," which combines Atlassian's "open company, no bullshit" value with its habit of dogfooding. Teams assume that what worked before will keep working. Atlassian's playbook was that developers and IT adopt the tools, recommend them to the business, and adoption spreads bottom-up before the company standardizes. The HipChat bet assumed the same path would work in chat, but, he says, the team never validated that early enough.

Customers were already saying IT used HipChat while the business preferred Slack. In his reading, both companies went after users, Atlassian in tech teams and Slack in business teams. Slack gamified onboarding and invested in look and feel, while HipChat's team built integrations that produced activity streams in the chat. Emojis and polish, which the team had seen as trivial, were not trivial.

On the next product he tried to test assumptions much earlier. Before writing any code for Jira Product Discovery, the team ran an ad in a Jira newsletter and a simple site inviting product managers to join, and gathered more than 3,000 waitlist signups in roughly two weeks. That showed both demand and a channel to reach those users.

Crusson's second HipChat lesson is competitive myopia. As Slack gained mindshare, the team kept thinking it needed just one more feature and ended up reacting to whatever the competitor shipped. He compares a competitor to an iceberg: shipped features show only the surface of research and customer understanding, and reflect what they were thinking perhaps a year earlier. Fast-following made HipChat lose what had made it successful, which was serving some users very well.

Today he checks competitors only every few months and tries to keep the creative and research process separate. When a rival's AI announcement lands in Slack channels, his teams rewatch their last few weeks of user interviews to remember who they are building for. He adds that a company playing the long game doesn't always need to be first.

The third lesson is that "startups have the benefit of starving." HipChat's rewrite was coupled with a move to a new microservices platform whose components, such as the editor, could be reused across products. That is powerful once the platform exists but a heavy load when built at the same time. He would win the problem space first and platformize later, though he notes that about 70% of the HipChat code is still in the Atlassian platform.

Statuspage is a success story that, for Crusson, felt like a personal loss. He had researched whether Atlassian could do for IT operations what Jira did for software, and he watched teams in incidents running around like headless chickens. Statuspage offered something simple: a page where customers can subscribe to updates, which cuts support load and builds trust. Atlassian ran a week-long hackathon with several companies, then bought Statuspage, and he ran its integration.

The hardest part was culture shock. A 20 or 30 person startup that controlled its own destiny joined a company with portfolio-fit decisions, different functional organizations, performance reviews, engineering allocation, OKRs and long-term roadmaps. Asked about three-year plans, the Statuspage team said essentially that they would survive. He was told early that integrations are mostly about people, and he agrees, warning that a business will slow down before it speeds up again.

Next time he would treat an acquisition like hiring and aim for something small: a company with a great product whose product is shut down and rebuilt on Atlassian's platform, effectively an acqui-hire that speeds up the roadmap. He distinguishes this from the HipChat rewrite. Rebuilding for existing customers is like rebuilding a plane in flight, while this approach is like delaying takeoff and switching planes.

Crusson then describes a business case to go bigger in IT operations with a new Jira-centered product, built before Atlassian had an incubator. He pitched it at every level, including business leaders, the CTO and the CEOs. No one said no and no one said yes. After months in limbo he asked his boss when to stop, was told to stop when he lost the passion, and eventually gave up.

The company went into the area about a year later, and he concluded that he had misread the urgency. Atlassian has many opportunities sitting on shelves, and what was missing was a strong trigger for why now rather than in a year or two. The next team did a much better job of explaining it. Lenny likens this to making the opportunity perishable, and Crusson adds that product managers biased toward action should recognize when waiting is pointless and step back.

Atlassian's founders recognized that the company was innovating in its big products mainly by acquisition and needed to build new products again, treating innovation as a muscle. The result was Point A, an internal incubator. Jira Product Discovery was one of roughly 100 pitches, and three products went through all stages. Crusson worked on it full time, with allocated budget and a team of people borrowed from other departments who could return if the bet ended, which removed fear of losing their jobs.

The team could also tap internal research and corporate development, and talk to about 20 companies in product management. The project started with research four years ago and had its first line of code three years before general availability, so it was dogfooded for three years. After launching a year earlier, it had about 8,000 customers and was one of Atlassian's fastest-growing products.

The hard part was reminding everyone that failure is the most likely outcome. He used a figure of around a 70% chance that the project wouldn't exist in six months, which he says was pulled from thin air. When other teams offered help, he answered that this was a bet of seven people and the company shouldn't be dragged into it, because help comes with conditions and slows things down. That freed the team to build things that don't scale or follow design guidelines in order to test with customers.

Asked why this framing works, he says the aim is to emulate a startup in an environment that is not hungry, which requires creating scarcity and urgency for the team. It also keeps the rest of the company away so the team can test things without negotiating with platform services for six months. He adds that it respects Atlassian's money: he doesn't want to commit a team of 50 until there is evidence.

Point A had four stages: Wonder, Explore, Make and Impact. Wonder proves a problem area and why Atlassian should move there now. Explore validates solutions, which for Jira Product Discovery meant new UX and workflows tested with customers over dozens of Zoom calls. Make goes from alpha to beta to launch, and Impact tracks business results. Using the stage names with other teams set expectations and helped shield the team from opinions about architecture before customers had validated anything.

To move between stages, the team wrote a six-pager read in a meeting with Point A stakeholders and Atlassian's founders, who decide on the spot. The team was once sent back when it asked to go from alpha to beta. Some bets were killed and others, such as the whiteboards feature, were rolled into Confluence.

Crusson says bets must break established rules without breaking trust, and he treated his accumulated trust as chips he was willing to go all in on. He hired only principal-level engineers who could commit to any repo, used contractors, and acted as both product and engineering leader, which kept internal engineering rules like a reliability time quota from applying. Being in France, far from Sydney, also meant fewer people engaged to stop the team. He says he wouldn't recommend this in many environments, and that the approach was later institutionalized in Point A.

Crusson says he is most passionate about how to work with customers on early bets without hurting an established base. Jira has about 120,000 customers, so the team couldn't experiment freely inside it. He cites an article by Noah Weiss on incubate, iterate and integrate, with Instagram's popular tab turning into the explore tab and then the main feed. For Jira Product Discovery the team built an experience detached from Jira's UI, because product managers wanted something visual and snappy rather than strict workflows owned by IT. They are now integrating it.

He pairs this with what a Reforge piece calls a safety funnel: work with a small number of customers until it's right, then expose it to more. Measuring monthly active users would have pushed them to expose it widely too soon. If they had caused an incident for millions of Jira users, he says, by the third time they would have been asked to pack up.

To define success he formalized the Lighthouse Users Program. The first stage works with 10 customers and explains why they represent later customers. From 10 to 100 the team tests variations in scenarios and security needs, and from 100 to 1,000 it removes the need for hand-holding so the product can be self-service. Each stage has its own questions, starting with video snippets of users and avoiding early targets like monthly active users.

Crusson argues that as products grow, teams hide behind formal research and CSAT. He recruits about ten customers who work with the whole team, not just the product manager, over months on Zoom and Slack. He compares it to climate change: reports don't change people, but personal stories do. Engineers who know customers' problems may push back in planning and propose a different priority, and he believes anyone can be a product engineer given the right user context.

To protect the project from the ugly-baby phase, he treated internal communication as part of the job. He posted tweet-sized weekly updates in Atlassian's Atlas product, gave weekly demos, and shared three-minute customer snippets on Slack rather than long reports. He even held back features to have something to show during vacations. Showing velocity, he says, keeps people from standing in front of a high-speed train.

The timeline was that the team had something dogfooding within two months, reached its first lighthouse user at five months, stayed in alpha for about six months, and spent close to a year in beta. At first people judged the team more than the outcome, which he links to founder-market fit. When the team thought it was ready for general availability, one of the founders, Mike, said it was too ugly, so they spent two or three months bringing it up to Atlassian's design standards.

Asked about the struggle, Crusson says many processes were unresolved because Point A was just starting, and teams outside kept wanting input for the time the product might succeed. Nothing was solved once and for all, but he thinks the team got out of it gracefully and may have inspired others to bend rules. He hopes people in suffocating companies are encouraged to try.

His closing caution is to look after yourself. Having worked in heavily regulated banks and with close to 50 companies, he says Atlassian was the first place where he felt at home from day one. He believes in autonomous leaders at every level, but in an environment that is unsafe it is fine to leave, because surrounding yourself with cynical people can make you cynical. In the lightning round he recommends *Who: A Method for Hiring* and shares an interview question: ask candidates what a former colleague would say about them.