Atlassian Sales

t
os
CASE: E-625
DATE: 1/26/17
rP
ATLASSIAN: SALES
Jay Simons sifted through a pile of sales candidate resumes as he sat in one of Atlassian’s glass-
walled conference rooms. As president of the company, he was leading an investigation into
whether it was time to make amendments to the company’s sales model and hire its first
yo
salesperson. For years, leaders in the software world had touted Atlassian as the company that
had perfected the ‘no touch’ sales model—where customers could try and buy Atlassian’s
business software entirely online, without needing to interact with traditional sales staff. And
now, it was considering enhancing that approach. With annual revenues from some of its largest
customers climbing into the range of millions of dollars per year, Simons wanted to ensure that
Atlassian’s biggest customers had the support they needed to continue to grow. Nevertheless,
hiring a salesperson had the potential to significantly disrupt the company’s culture and sales
op
philosophy. As he read through the resumes, Simons continued to weigh these pros and cons.
THE EARLY DAYS
Atlassian founders Mike Cannon-Brookes and Scott Farquhar met during their time at the
University of New South Wales in Australia, where they both participated in the same
tC
prestigious scholarship program. After spending time developing a close friendship, they
decided to start a company. Together they founded Atlassian in 2002, during what they would
later refer to as “the nuclear winter for tech.” At the time, technology investors were still reeling
from the dot-com crash, so the two founders found it nearly impossible to raise venture capital.
They ultimately decided to bootstrap the company, a move that had profound effects on the
products they designed and the way they sold them.
No
JIRA
The duo did not have a clear idea of the product they hoped to sell when they began the
company, but they decided early on to focus on teams developing software. As the team
experimented with various product ideas, they developed a custom bug-tracking tool to help
Matt Saucedo (MBA 2015) and Professors Kirk Bowman and James Lattin prepared this case as the basis for class
discussion rather than to illustrate either effective or ineffective handling of an administrative situation.
Do
Copyright © 2017 by the Board of Trustees of the Leland Stanford Junior University. Publicly available cases are
distributed through Harvard Business Publishing at hbsp.harvard.edu and The Case Centre at thecasecentre.org;
please contact them to order copies and request permission to reproduce materials. No part of this publication may
be reproduced, stored in a retrieval system, used in a spreadsheet, or transmitted in any form or by any means ––
electronic, mechanical, photocopying, recording, or otherwise –– without the permission of the Stanford Graduate
School of Business. Every effort has been made to respect copyright and to contact copyright holders as
appropriate. If you are a copyright holder and have concerns, please contact the Case Writing Office at
businesscases@stanford.edu or write to Case Writing Office, Stanford Graduate School of Business, Knight
Management Center, 655 Knight Way, Stanford University, Stanford, CA 94305-5015.
This document is authorized for educator review use only by Vinita Srivastava, Indian Institute of Management - Kashipur until Jul 2021. Copying or posting is an infringement of copyright.
Permissions@hbsp.harvard.edu or 617.783.7860
Atlassian: Sales E-625 p. 2
t
address issues in their code. Over time this bug tracker grew into a full-fledged issue tracker,
which eventually became JIRA—a bug-tracking, issue-tracking and project management tool for
os
development teams that leveraged agile methodology. Like all good names in the software
industry, the name JIRA started as an in-house code name. The team originally used Bugzilla, a
popular bug-tracking tool in the market at the time. The team began calling their homegrown
product JIRA after ‘Gojira’ (the Japanese name for film character Godzilla).
rP
Agile Methodology
JIRA software helped teams leverage the agile method of software development to build
technology products effectively. Agile was an iterative approach to software delivery that helped
teams develop software incrementally from the beginning of a project, instead of trying to
deliver it all at once near the end. It worked by breaking down projects into smaller pieces of
user functionality called user stories, prioritizing them, and then continuously packaging them
yo
into short, two-week cycles called iterations or sprints.
At a high level, the Agile methodology proceeded as follows:
 A developer made a list of features she would like to see in her software.
These were called user stories and became the to-do list for her project.

op
She estimated the time each story would take to develop, relative to one
another (not absolute).
 The developer prioritized all of the user stories on her list.
 The development team began executing the work—starting at the top of the
list and working their way to the bottom. The team focused on building,
iterating, and receiving feedback from their customer as they go.
tC
 The team would continuously update the plan to reflect development progress
and changes to the design of the product.
The Flexibility of JIRA
JIRA allowed development teams to develop their own workflows for shipping software, or
choose an out-of-the box option. The product focused on allowing everyone on the development
No
team to stay abreast of the current issues, goals, and processes related to developing their
product. JIRA provided developers with a communication and planning platform they could
leverage across the software development lifecycle:
 Plan: Developers could create user stories and issues, plan sprints, and
distribute tasks across a team.
 Track: Teams could prioritize and discuss the group’s work in full context
with complete visibility.
Do
 Release: JIRA ensured that all relevant information was matched with the
latest released version of the software.
 Report: Teams could improve their performance using real-time data.
t
Atlassian Takes JIRA to Market
os
In April 2002, Farquhar and Cannon-Brookes released the first version of JIRA through the
Atlassian website. The team recognized early on that they would need to think about global
sales in order to succeed, as the Australian market for issue-tracking software was too small to
support a thriving business. Simons explained, “Our founders recognized that they were not
going to build a wonderful business just by selling to their compatriots. We needed to reach the
rP
rest of the world, so used the Internet to distribute our products, making it easy for customers to
try and buy online.”1
Because the team did not want price to be a friction point or barrier to entry, they sold JIRA as a
perpetual license for a one-time fee of $800. Annual maintenance and support, which provided
access to technical support, bug fixes, and upgrades with new features, cost $400 each
subsequent year—or 50 percent of the initial license cost. The product came with no limit to the
yo
number of users per license, nor was it tiered by available features. Additionally, academic
institutions received a half-price discount and non-profits and open source projects were able to
use the software for free. The decision to give JIRA away for free to the open source community
helped the company gain early traction within the developer community—as many open source
projects had many developer participants. Soon many of the leading open source projects, such
as Java and the Apache Foundation, were using JIRA as their issue tracker.
op
Simons explained how offering a free demo, low pricing, and free products to open source
projects helped amplify word of mouth sales: “There were hundreds of thousands to millions of
developers who would see JIRA being used by Java2 and Apache,3 then go back to their jobs and
say, ‘Well, our issue-tracker is terrible compared to JIRA. Why don’t we try switching?’ We got
a lot of marketing by offering the product to open source projects for free.”
tC
Organizational Effects of a Low-price, Volume-based Model
The low, one-time price of $800 for JIRA helped the company acquire large volumes of new
customers efficiently. It also forced the company to improve its ‘no touch’ online distribution
model, as building a traditional sales organization wouldn’t prove cost effective. As Simons
explained: “You’d lose money basically at every single conversion point; it wouldn’t be worth
No
it.” Nevertheless, this low price point allowed the Australian start-up to reach the rest of the
world using the Internet as a distribution and marketing platform. At the time, Google AdWords
was still in its nascence, so Atlassian could effectively target technical customers at reasonable
costs. “We were relatively adept very early on at leveraging Google AdWords and search engine
marketing to describe our product in a way that helped us anchor around what people were trying
to find,” explained Simons.
1
Interview with Jay Simons, August 17, 2016. Subsequent quotations are from the author’s interviews unless
Do
otherwise noted.
2
Java is a general-purpose computer programming language licensed under the GNU General Public License. As of
2016, Java was one of the most popular programming languages in use, particularly for client-server web
applications, with a reported 9 million developers.
3
The Apache HTTP Server, colloquially called Apache, is the world’s most used web server software. As of July
2016, Apache served an estimated 46.41 percent of all active websites and 43.18 percent of the top 1 million
websites.
t
In order to distribute the low-cost, volume-based product, Atlassian had to create a model that
os
supported customer self-service and removed as much friction as possible. There were no forms
to fill out, no custom contracts, and no hidden pricing. In order to handle the influx of new
customers, Atlassian developed a frequently asked questions (FAQ) page to help handle
incoming queries about the product. In the early days of the company, the founders would
personally respond to any questions that were not addressed in the FAQ. Over time, this
rP
responsibility transitioned to a small team of employees who also assumed the responsibility for
updating the FAQ. Soon, management began to summarize the philosophy of the sales model as:
“Our products are bought, not sold.” (See Exhibit 1 for a summary of Atlassian’s sales model.)
The model of low pricing and ‘no touch’ sales soon began to succeed, and Atlassian quickly
grew from $1 million in revenue in 2002 to $14.9 million in 2005.
yo
Atlassian Develops Its Second Product
As Atlassian continued to gain traction with JIRA, Farquhar and Cannon-Brookes began work on
their second product—Confluence. Cannon-Brookes wrote in a press release that the goal was to
design “…an application that was built to the requirements of an enterprise knowledge
management system, without losing the essential, powerful simplicity of the wiki in the
process.”4 Released in March 2004, the product was part knowledge center and part team
op
documentation tool, and allowed teams to create, share, and collaborate on projects in one central
repository. It also connected with JIRA, allowing teams to connect issues to plans, requirements,
and documentation. Atlassian introduced the product with a new pricing model that supported
user tiers—25 (team), 50 (workgroup) and unlimited (enterprise) for $1,200, $2,200 and $4,000,
respectively. Annual maintenance and support agreements remained at 50 percent of the initial
license fee. Commensurate with the Confluence release, Atlassian also changed the JIRA
tC
pricing model to align with Confluence.
Confluence bolsters the no-touch sales model

Simons believed the ability to introduce a second product so early on in the company’s lifecycle
was a result of the founders not raising venture capital, as he explained:
No
I think if you go back to one of the main ingredients of the company, it’s that it
wasn’t venture backed. It’s an important characteristic of the company and the
decision we’ve made. If it were a venture-backed company, I’m convinced that
the VCs on our board would have said, “Why are you spending any time with a
second product? You just released your first product. You’re losing focus—
don’t do that. Everyone should be building a bigger JIRA.”
However, the founders and their young management team believed that releasing Confluence as
Do
a second product gave more weight to their strategy that combined low-cost Internet marketing
through AdWords with a ‘no touch’ online distribution system. Simons again commented,
“Confluence gave more weight to the ball—now we had a second product that had many of the
4
“Atlassian releases new wiki: Confluence 1.0,” TheServerSide.com, March 25, 2004,
http://www.theserverside.com/news/thread.tss?thread_id=24701 (February 17, 2017).
t
same characteristics of our first one. And our model made it much easier to introduce a second
product. Releasing Confluence reinforced our unique go-to-market approach and also helped us
os
build an early discipline as a young company around better merchandising and cross-sell/up-sell
techniques.”
KEYS TO SUCCESS: THE ADVOCACY TEAM AND CHANNEL PARTNERS
rP
Advocacy Team
By 2006, the Atlassian management team decided to institutionalize the small team of employees
who were responsible for assisting potential customers evaluating Atlassian products. In March,
the company announced the creation of the Customer Advocacy program to help customers get
the most out of every interaction with Atlassian. Cannon-Brookes explained the strategy:
yo
Most software companies try to up-sell their customers at every interaction.
Contrary to that traditional approach, the Customer Advocacy program is here to
help our customers get the most out of their software—not to pitch them to buy
more. The Customer Advocates will ensure we stay close to our customers by
providing a level of service that many companies left behind at their last
downsizing.5
op
Advocates were responsible for ensuring that it was easy for customers to understand JIRA and
Confluence—what the products could do for their organization, the total cost of ownership, how
they compared to competitors, and other factors. While advocates were meant to be as helpful as
possible, they were never allowed to qualify the opportunity or ask if the customer asking about
the product was ultimately the person in the organization who would make the decision to
purchase. As Simons explained, “An Advocate’s mission is to provide an incredible answer to a
tC
customer’s question. And then they take a step back and say, ‘If you ever need my help again,
you know I’m an email, phone call, or chat away. Other than that, I’m going to leave you to it
because the rest of the system should support you.’” The inability to offer incentives to close
deals was evident in the company’s quarterly sales figures, which showed a linear growth in
bookings throughout the quarter without the uptick in the final period that typically coincided
with salespeople attempting to hit quotas (see Exhibit 2).
No
Even as the company grew and created additional products, the customer advocacy team
remained relatively the same size and held the same responsibilities—as the volume of customer
inquiries increased, so too did improvements in customer self-service and automation to
streamline the process for new prospects. Simons explained the rationale:
In most typical sales models, you don’t want to deflect any opportunity to engage
with the customer. In fact, you want to encourage it. And so most traditional
Do
sales models will hide pricing because if you ask me how much it costs, that’s a
buy signal. Now as a salesperson I get to say, “Well it sounds like you’re
interested in this product. Let’s talk about what you want to do with it.”
5
Jon Silvers, “Introducing the Customer Advocates,” Atlassian Blogs, March 13, 2006,
http://blogs.atlassian.com/2006/03/introducing_the_1/ (February 17, 2017).
t
Our model is based on helping customers complete the entire journey themselves:
os
We put pricing front and center because we don’t want you to have to ask us how
much it costs. We feel like that’s a question our customers should be able to
answer on their own.
So the Atlassian approach focused on reducing the number of questions that potential customers
rP
had to ask. Simons and his team philosophically believed that the company should be oriented
around self-service. He argued that customers disliked the process of asking questions about a
product and then waiting for a salesperson to respond, and they would instead prefer to have the
answer provided in the simplest and quickest way possible. Simons explained:
We believe if there is a sales model where the customer would never have to ask
us a question, and we would still have the same amount of yield, then that’s the
yo
best system to have. I think so many models in enterprise software have been
built around the high-touch approach where you’re incentivized to create friction
points and speed bumps to engage your customer.
Key performance indicators

Atlassian’s management team made the decision to measure the customer advocacy team by
op
response time to customers’ questions and NPS (customer satisfaction score), versus relying on
conversion rate or bookings. Simons argued that measuring the team by any metric that was
typically associated with inside sales would result in employees making markedly different
decisions, such as catering to higher potential revenue customers first. Simons commented:
Philosophically, if we believe that most of the virtues of the self-service model

tC
will work, then we really want our customer advocates to be hyper-focused on

providing an incredible answer to everybody. We don’t want them to be
selective, so they can’t be measured on topline. Also, because our products
targeted teams, even the largest customer would often begin with a small ‘team’
license, where the cost of sale in a traditional sales approach would easily exceed
the return.
No
Putting the self-service model to the test

Atlassian frequently experimented with providing new opportunities for customer advocates to
interact with potential customers throughout the conversion funnel. In particular, Simons and his
team were curious if providing interaction opportunities to certain customer segments or at
certain parts of the sales funnel would lead to better outcomes. So the company ran a split test to
see whether the self-service model could compete with a more hands-on approach. The
company had 500 potential customers follow the standard Atlassian process—providing them
with a comprehensive website and FAQ, along with the opportunity to reach out to a customer
Do
advocate should they have any additional questions. The company approached another 500
potential customers using higher touch tactics. The experiment showed that while a higher touch
approach led to a marginally higher conversion rate, it did not lead to a meaningful inflection in
lifetime value, especially one that made it worthy of the additional required investment. Simons
reflected on these findings: “These tests have always proved to us that even though we might be
leaving near-term money on the table with a lighter touch approach compared to high-touch
t
sales, our strategy has led to a more profitable and predictable outcome for our business in the
long term.”
os
Channel Partners
In addition to selling products directly to customers through the company’s website, Atlassian
also worked with channel partners to provide in-person and localized sales (both in the United
rP
States and globally), as well as to help customize products for customers. These channel
partners were given a 25 percent discount on Atlassian products as margin for their sales efforts.
The channel partners’ primary focus and business opportunity was in customization and
development services to install, configure, and customize Atlassian products.
In-person demonstrations and global sales

From the company’s beginning, Atlassian fielded requests from potential customers for in-person
yo
product demonstrations. Atlassian’s focus on high volume through lower price points meant
these investments were impractical and not cost effective. Atlassian focused instead on creating
self-service demos and product walk-throughs prospects could investigate at their own pace. In
addition, local channel partners provided such product demonstrations in exchange for a
commission on each sale. Simons explained the rationale behind this strategy:
If a customer comes to us and asks for an in-person demo, we can say, “We don’t
op
do that, but I can introduce you to somebody locally who absolutely knows our
products inside and out. And, by the way, they can help support you post-sale
with any questions you may have.” If it weren’t for channel partners, we
wouldn’t be able to reach our customers in this way. If the customer responds, “I
insist that you come, not a partner,” then we’re not going to win everything. So
we’ll happily say, “Well, we’re probably not the right company for you then.”
tC
We’ll walk away.
Channel partners also helped Atlassian more effectively engage customers in international
markets like Germany, France, and Japan, where language barriers made the no-touch model
slightly less tenable. Channel partners in these countries proved they could help introduce
potential customers to Atlassian’s products using the local language in ways that the website
No
could not. This approach proved effective—channel partners’ contribution to sales generally
came to 50 percent in Germany and around 70 percent in Japan. In the United Kingdom,
however, channel sales typically contributed around 20 percent.
The benefits of a self-service sales model combined with channel sales

Atlassian frequently relied on channel partners to fill the gaps in the self-service sales model, and
Simons prided the company on its success as a channel-friendly business, as he explained: “A
direct, higher touch sales approach often competes with an indirect channel for business, and
Do
often creates ‘channel conflict’ as the two approaches clash to win business from the same
customers. Our self-service online model is the perfect complement to the higher touch
approach our channel partners provide in the field.” In addition to providing in-person
demonstrations and highly targeted sales in the local language, channel partners could help
implement changes, customize Atlassian products, and onboard new customers, helping ensure
more longer-term customer success for large and complex deployments.
t
By 2016, Atlassian’s channel partners accounted for a quarter of all booked revenue. And
os
globally there were more than 300 individual partners building Atlassian practices and
representing the products in market.
SHIFTS IN PRICING AND SALES MODEL
rP
By 2006, Atlassian has shifted its pricing model from the simple single price of $800 to a
broader set of user tiers that began at 10 users and expanded to a 100+ user license for $8,000.
When the global financial crisis struck in 2008, the Atlassian management team began
examining whether the company’s pricing model should be adjusted to reflect the changing
economic environment. The company had not modified the pricing of JIRA or Confluence up to
that point, but Simons and his team noticed that usage of Atlassian products in teams of up to 10
people was flat-lining at a time when every other cohort continued to grow. Concerned that the
yo
company was missing out on massive amounts of sales volume, the team decided to create a 10-
user SKU for $10 and donate the revenue to charity. Simons explained, “Even at the expense of
a couple million dollars in topline revenue bookings, we decided to significantly reduce the price
for the entry-level 10-user team, which massively inflected our top-of-funnel demand and sales
volume. Despite wiping this revenue off the topline, this experiment totally made up for it in
terms of the different segment of the market that we tapped into.”
op
At the same time that Atlassian lowered the price to allow smaller teams to try the product, they
also added user tiers to capture more value from large customers. Simons and his team did this
by expanding the ceiling on the number of users allowed at each level. So where customers paid
$8,000 for a 100+ user license, Atlassian eventually created several higher tiers above the 100-
user level, all the way up to a 10,000+/- user tier priced at $36,000. Companies could select the
tC
tier that matched their actual user counts, so the large number of customers with fewer than 100
users wouldn’t see a price change.
With every subsequent shift in pricing, Simons explained the guiding principle: “We always
favor the customer in the value exchange and seek to optimize pricing over the long term by
making it easier for small companies and small teams to get started—and capturing more value
from larger customers as we become more successful.”
No
Data Center Product
In 2014, Atlassian released a new product line to support the large-scale deployments of its
biggest customers. The Data Center editions of JIRA and Confluence allowed customers to
deploy Atlassian products in their own data centers across a number of physical machines, where
previously these products could only be deployed on a single server. This new design created a
host of enterprise-oriented benefits that helped companies operate at scale:
Do
 High availability: Customers could eliminate single points of failure by having the
applications run on multiple servers within the data center, thus allowing for continued
use in the event of a single server failure.
t
Performance at scale: Distributing the application across an entire data center created
additional capacity and provided greater resilience in the event of spikes in usage.
os
 Instant scalability: The new design allowed data center administrators to quickly and
easily add capacity as usage within the company grew.
Does a new pricing model require a new sales model?
rP
Atlassian saw the Data Center offering as an opportunity to shift the pricing model from one
based on perpetual licenses (one-time fees for an unlimited amount of use) to an annual
subscription plan. Under this new pricing structure, Atlassian charged customers $24,000 per
year for every 1,000 users for the Data Center deployment option for JIRA and Confluence, up
from roughly $2,400 for the cloud and standard on-premises server deployment options.
Data Center stood apart from Atlassian’s other products for several reasons. First, the product
yo
was only intended for Atlassian’s largest customers, since many of its features focused on
helping JIRA and Confluence run on a massive scale within a big organization. Second, because
Data Center was designed only for these large customers, the target market for Data Center was
comparatively small and the price points relatively high: This approach differed from Atlassian’s
low-price, volume-based sales approach.
op
Simons and his team began debating whether or not it was time to enhance the model with a
higher touch approach. He explained:
When we introduced Data Center, we believed that it was probably going to

require a different level of conversation with our customers. We needed to
explain the product, and they were going to want to understand what was so
tC
significantly different about it, why they should consider it, and why they should
go from paying for a perpetual license to a subscription. We believed at the time
that it was a little bit difficult to introduce a product that could cost hundreds of
thousands of dollars with a simple marketing webpage and an explanation of why
high availability and fault tolerance mattered. We felt that there needed to be a
little bit more of an established relationship with these customers to make this
work.
No
So Simons created a new group called Enterprise Advocates—a team of 10 employees who were
charged with reaching out to 500 of Atlassian’s largest customers to act as points of contact for
the company and help expand them to the Data Center offerings. This was the first time that
customers who were spending anywhere between $50,000 to $1,000,000 on Atlassian products
per year could put a single name and face to a contact at Atlassian, since all prior purchases went
through the company’s website regardless of sale amount. Simons elaborated on the new sales
strategy:
Do
We introduced a more traditional, higher touch approach, but we were very

thoughtful about how the Enterprise Advocate team was structured and oriented.
In order to maintain our sales philosophy, we chose to go with a team commission
structure instead of individual commissions. We also focused the team on
t
complementing the linearity of our existing business and model—they cannot
discount, nor can they negotiate terms and conditions.
os
When Atlassian originally introduced the Data Center products, customers could purchase these
only through Enterprise Advocates and channel partners. Only after proving product/market fit
with Advocates and channel partners did Atlassian offer Data Center products through the self-
service website.
rP
Continuing to Consider New Sales Approaches
Two years after releasing the Data Center product line, Atlassian was earning up to $1 million in
annual revenue from its largest clients. This growth in sales came from a blend of both attracting
larger companies to Atlassian products, as well as scaling subscription revenues—which were
growing over the years—from longtime customers (see Exhibit 3).
yo
By this time, the Data Center offerings had significantly increased the annual spend of large
customers and provided an opportunity for more traditional Enterprise Licensing Agreements
(ELA) to flourish. An ELA was an agreement to license the entire customer’s workforce to use a
particular piece of software for a specified period of time at a specific price. It typically
provided the customer with the following benefits:
op
 Potential for substantial cost savings through volume discounts
 Sales that were concluded through a single procurement transaction
 Consistent pricing for the entire period of the ELA
 A predetermined pricing discount for new purchases
tC
Simons began mulling over the possibility of hiring a traditional salesperson to help negotiate
ELAs with the company’s largest customers. Since Enterprise Advocates functioned similarly to
Product Advocates—in that they were not allowed to negotiate contracts—he worried that they
did not have the proper experience to negotiate ELAs. Additionally, he felt that negotiating
terms would run counter to the team’s mission to move units and help the customer try out more
of Atlassian’s products. He explained, “The goal would be to hand the largest deals to a new
salesperson who would be focused on the strategic, multimillion dollar and multiyear deals.”
No
This new salesperson would partake in many of the activities that Atlassian had avoided up to
this point—including traveling to customer sites for in-person demonstrations, negotiating terms,
and offering trade-offs as part of the agreement.
The potential for stronger partnerships and increased revenues from Atlassian’s biggest
customers loomed large over Simons’s decision. At the same time, he was also concerned about
the potential to derail Atlassian’s self-service model, as he explained: “I don’t want a salesperson
to mess around with the model. What if this person comes in and says, “Look, you’ve handed
Do
me a bunch of clients that have said they’re interested, but I don’t think they’re the right ones. I
want to go into these large corporations that all have small footprints with us and spend my time
trying to grow these partnerships.”
t
The Decision
os
Back in the conference room, Simons took a break from sifting through the resumes to reflect on
the evolution of Atlassian—from its early days of offering free downloadable demos, to the
current and continual process of evolving the model, diversifying pricing tiers, and augmenting
the sales strategy with a higher touch approach to better accommodate larger organizations. He
knew that Atlassian would not be the business it was today if the founders had taken a traditional
rP
sales approach at the beginning of the company, but he also wondered how he could best balance
each of Atlassian’s current sales strategies.
yo
op
tC
No
Do
t
Exhibit 1: Atlassian’s Sales Philosophy
os
rP
yo
op
tC
No
Source: Atlassian.
Do
t
Exhibit 2: Quarterly Sales Data
os
rP
yo
op
Source: Atlassian.
tC
No
Do
t
os
rP
p. 14
yo
Exhibit 3: Data on Atlassian
op Source: Table compiled by Matt Saucedo, using data from Atlassian.com.

tC
No
Do Atlassian: Sales E-625

Atlassian Sales

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Atlassian Sales

Uploaded by

Copyright:

Available Formats

t

THE EARLY DAYS

At a high level, the Agile methodology proceeded as follows:

The Flexibility of JIRA

Organizational Effects of a Low-price, Volume-based Model

pricing model to align with Confluence.

Confluence bolsters the no-touch sales model

KEYS TO SUCCESS: THE ADVOCACY TEAM AND CHANNEL PARTNERS

Key performance indicators

Philosophically, if we believe that most of the virtues of the self-service model

will work, then we really want our customer advocates to be hyper-focused on

Putting the self-service model to the test

In-person demonstrations and global sales

We’ll walk away.

The benefits of a self-service sales model combined with channel sales

SHIFTS IN PRICING AND SALES MODEL

Data Center Product

Does a new pricing model require a new sales model?

When we introduced Data Center, we believed that it was probably going to

We introduced a more traditional, higher touch approach, but we were very

op Source: Table compiled by Matt Saucedo, using data from Atlassian.com.

You might also like