Planning Atlassian Apps for Real-World Scale by John Paz

Planningfor 
Real-WorldScale
JOHN PAZ | SR. CONTENT DESIGNER | ATLASSIAN | @TECHWRITERNINJA
Hello and good evening everyone, my name is John Paz, and, yes, I am fully aware that I am all that stands between you and Happy Hour.

So, I’ll try not to linger. Let’s get started.

[NEXT SLIDE]

FormerAdmin
ReformedJiraandConfluence
administratorforaprevious
employer.
JohnPaz
LongtimeFanBoy
Enthusiasticcontributoron
Community/Answers,and
drinkerof“theKool-Aid.”
Sr.ContentDesigner
Nearly4yearsworkingat
AtlassianasaSeniorContent
Designer,onBitbucket.
I work for Atlassian as a Senior Content Designer on Bitbucket.

I originally began working for Atlassian out of the Sydney office on the product formally known as Stash.

In a prior life, I was an Atlassian administrator for a former employer.

And I’m extremely grateful for that experience because it prepared me to apply for a job at Atlassian with confidence. And working as an admin gave me a wealth of
empathy for our users that I bring to the product teams every day.

Even before I worked as an admin I was an Atlassian user and fan-boy.

I loved to contribute to Atlassian’s Community forums I was drinking the Atlassian Kool-Aid I became a sort of non-official advocate for Atlassian products, a “drinker of
the Kool-Aid,” shall we say.

[NEXT SLIDE]

OCNBS
In the spirit of my favorite Atlassian company value, I want to start by brieﬂy going over what I will go over in my presentation.

I feel like this is important, for the spirit of transparency Atlassian promotes, and because I suspect some of you may be here for the wrong reason.

Actually, I counted on it.

[NEXT SLIDE]

PlanningYourAppsfor 
Real-WorldScale
The name of my talk is titled “Planning Your Apps for Real-World Scale.” But it looked nicer on a slide this way once I dropped the word “Apps,” and this way I also think
this presentation might be useful for people who not be making apps for the Atlassian ecosystem.

[NEXT SLIDE]

Planningfor 
Real-WorldScale
I wanted to be upfront with you all right away, if you’ve arrived here looking for guidance about conﬁguring load balancers, creating a disaster recovery strategy, or
ﬁguring out how many nodes for a Bitbucket Data Center instance, you’re at the right place, as in at Atlas Camp, but probably not the right talk. Or at least not the talk
you think you wanted to hear.

[NEXT SLIDE]

Code, andbeyond
This also seems like a good time to remind everyone that you all are currently in the thick of the CODE, AND, BEYOND track… so, you have been forewarned.

[NEXT SLIDE]

Planningfor 
Real-WorldScale
I feel like this is important because when rehearsing this presentation, a few of my colleagues gave me some feedback saying the expected to hear more technical
guidance in my talk …

There will be very little of that in my talk.

[NEXT SLIDE]

Doyoureallyknowwhatyour
usersaredoing?
Really?
In my defense, you’ll have to forgive the click-bait-y title, because they passed on this talk the ﬁrst time around, when it was titled “Do you really know what your users
are doing? [CLICK] Really?”

[NEXT SLIDE]

Planningfor 
Real-WorldScale
So while my talk is deﬁnitely about scale, I take a diﬀerent approach in planning for growth. After my proposal for this presentation was accepted, I looked at the
wonderful agenda of talented professionals speaking at Atlas Camp. And I don’t think I could provide better guidance about how approach the challenges you all face as
Atlassian ecosystem vendors than them.

Instead, I hope to share some fun stories and interesting things to think about the next time your team is looking for their next opportunity for growth. After my talk, I think
you’ll agree that the Atlassian ecosystem already has some untapped potential in its existing user base.

[NEXT SLIDE]

Letstalk
aboutscales
Actually, it’s that confusion about my use of the word “Scale” I was counting on, and that probably lead most of you to be sitting here right now.

And you bet that I most deﬁnitely relied on that confusion to trick the committee into accepting my pitch to give this talk in the ﬁrst place.

But it bears repeating…

[NEXT SLIDE]

REAL-WORLD SCALE ≠ SCALING
You’rethinking
aboutthewrong
kindof“scale”
I’m a words guy, and you see the English language can be tricky. The word “scale” has a few deﬁnitions.

The conventional deﬁnition of scale, at least for this crowd, typically describes size.

[NEXT SLIDE]

THE REAL-WORLD SCALE
…describestherangeof
users’experiences, 
challenges,&
expectations.
noun
…describesthesizeor
extentofsomething,or
planningforgrowth.
SCALE/SCALING
verb
But in the term “Real-World Scale,” what I’m talking about is describing the full range of diﬀerent experiences, challenges, and expectations customers experience with
our products and services.

To help you remember, just remember that scaling is something you do, while a scale is something you create.

[NEXT SLIDE]

Identify&measure
actualusers,whattheydo, 
&theirexpectations
@TechWriterNinjaAtlas Camp 2018
It’s the notion of capturing and describing user requirements as comprehensively as possible, and using that information to make deliberate decisions to improve user
experience.

I think of using a Real-World Scale when the number of licenses you sell or accounts you close are no longer informative enough to help you make decisions about the
direction of your product. It’s how you get known for “doing the little” things and “putting the customer ﬁrst.”

[NEXT SLIDE]

Measure
yourempathy 
foryourusers
What I hope you can gain from this approach, aside from your hearing a few entertaining stories, is a greater appreciation for understanding your users.

This is one of those things I think Atlassian does really well.

At Atlassian, we strive to understand our users better in so many ways. We’re challenged by the executive teams to ask more and harder questions about the data we
collect, and the questions we ask.

• The kinds of things we study most are:

• how can we better support our existing users?

• did our product work for you?

• Did you get your work done? What did you expect to happen? Did we help? What can we do better?

I understand that not all of us have resources to conduct extensive user research, it will pay dividends to be aware of, and actually measure, how well you know your
users.

The distinction is important. It’s ok if you can’t do user research, but you should be talking to your users and measuring ways you can improve their experience. And
sometimes that doesn’t require you to write a single line of code.

…describestherangeof
users’experiences, 
challenges,&
expectations
…eventhe 
edgecases.
REAL-WORLD SCALE
But really, none of this is new. And I know this crowd cares about its users. That’s evident by just being here. But, do we really care about our customers?

Really?
All of them? Are you sure? [CLICK]

EVEN THE EDGE CASES???

Even if you already do this in your planning and design, I bet I at least gave you cause to pause when the word “edge cases” came up, right?

[NEXT SLIDE]

#RealTalk
PLANNING FOR REAL-WORLD SCALE
[SLOW ANIMATION]

Let’s get honest for a moment? We’ve all done it, right? Labeled a requirement as an “edge case” and then “Closed; Won’t Fix” that issue into oblivion.

It’s a tough call, usually. It tends to be a user with an old format or a weird requirement. Or it’s a user base that’s not your target demographic, perhaps in an industry that
Atlassian is not well-designed to work in.

When you’re building products, there comes a time where you have to draw a line about what you can do, what you will do, and just as importantly, what you will not do. I
pass no judgement on those of us that have had to ignore a worthy edge case.

[NEXT SLIDE]

“Edgecase” 
shouldnot 
beadirtyword
When it comes down to it, all I’m saying is that “edge case” doesn’t have to be a dirty word. In fact I’m arguing that it shouldn’t be.

I could totally make the argument for a righteous and moral justiﬁcation for caring for all users. Because by not doing so you are heartless.

But I’m not after the pathos vote with this talk. Nay, I think everyone in this room should care about edge cases, and that’s because they’re important to Atlassian’s
ecosystem, and how together we’ll unleash the potential of every team.

[NEXT SLIDE]

Edgecases 
areespecially
importanttothe
Atlassian
ecosystem
Rapidadoption
Our self-service sales model and
componentized platform can create high
stakes and inconsistent experiences.
Increasinglydiverse
Consider the real-world scale of ecosystems
their familiar with to provide the most value.
Versatileproducts
Atlassian products’ flexibility can lend itself to
creating lots of edge cases.
I’m not just sayin’ that though, I think there are some specific reasons why we should cast a wide net when learning about our users and how they use our products.

The first is the easiest in my mind to get behind, and that’s the inherent versatility of our products naturally creates some edge cases.

It’s undeniable this flexibility is a selling point, but at the same time it also creates some tough challenges to design for.

Do you want users to do things a certain way? Or do you plan for them to do things how they prefer?

[NEXT SLIDE]

Ultimate
versatility
CUSTOMER STORY
We’ve come to the first of three stories I’ll tell today, all of which demonstrate some sort of edge case using an Atlassian product that we didn’t plan for when we drew it up.
The versatility of Atlassian tools is genuinely a strong selling point. There’s no denying that. But as app developers, that versatility can create some difficult challenges
when designing and building apps.
They’re designed to be highly configurable, extensible, and easy to integrate with just about anything. The versatility of Atlassian products means you need to consider the
entire scale of potential solutions to user challenges.
This customer is a great demonstration of the ultimate versatility of our products, and the perfect example of a product being used in an unexpected way.
[NEXT SLIDE]

Entrepreneur, certified Jira
Admin, and author of the Jira
Strategy Admin Workbook.
Works from the road… as in,
working from home except her
home on wheels!.
Use Jira and Confluence to
run her business and her
personal life.
RachelWright
www.jirastrategy.com
This is Rachel Wright. Rachel is an entrepreneur, Certiﬁed JIRA Administrator, and author of the JIRA Strategy Admin Workbook.

Rachel pushes the idea of working from home to the extreme, as she works from the road out of a travel trailer after selling nearly everything 3 years ago. All the while
Rachel has been criss-crossing the United States of America she’s been working as a Jira and Conﬂuence admin remotely, while also using the tools to help run her
business. So meta.

[NEXT SLIDE]

Working  
from the road 
with Jira &
Confluence
Uses Jira & Confluence
to coordinate her
consulting practice,
volunteer work, and
personal life.
But when I tell you that Rachel takes working from home to the extreme I mean it.
I learned about Rachel after she’d posted an article in Atlassian’s Community, the online discussion forum. It was there she shared her story, and I learned a new term in
the process.
You see Rachel doesn’t just work from the road, no, that’s not enough of a challenge for her. Rachel and her partner do what is referred to as
[NEXT SLIDE]

Boondocking
· camping, but without hookups to
city power, water, and sewer
systems.
RachelWright
www.jirastrategy.com
Has anyone heard this term before? I am so curious because this is a European audience. I hadn’t heard it before, at least not in this context. Luckily Rachel explains…
[CLICK]

Boondocking is camping without hookups to city power, water, and sewer systems. I know, she’s a badass.

When Rachel and her partner first started out they were paying campgrounds to supply their utilities. But that was too easy, so they decided to do it all on their own. This
way there’s no limit to where they can go, so long as there’s cell service, which is just how they like it.

She uses Jira to track where they go, and Confluence to record details about each location.

Details concerning things we typically take for granted when your living on the road. Like, they have to bring their own water, and store it – before and after they use it.
And like every single one of us modern humans, they have to keep their devices charged, so generating power is a major concern for Boondockers… if that’s what they
call themselves.

I’ll have to asked Rachel… you’ll be able to find her somewhere around here. Wherever there’s an Atlassian event, you can be sure it’s probably on her radar. Be sure to
say hello if you see her.

[NEXT SLIDE]

Whatareusersdoing 
withyourstuff
thatyoudidn’tplanfor?
The point of telling you Rachel’s story is that hers is the ultimate edge case. That by making a product ultra-accessible you get stories like hers that can really push the
imagination of many others.

Marketers dream of stories like those to tell, and ours are eager to share theirs.

So, challenge yourself. [CLICK]

Find out what users are doing with your stuﬀ. Ask them.

Or ask your support team. It may not be as unconventional as Rachel’s, but ﬁnding out is part of every team’s journey.

[NEXT SLIDE]

Iftheydoitwrong,
buttheystillpayyou,
aretheyactuallywrong?
Now I know there are naysayers out there… I can feel you. I can feel your doubt.

“Why should we care about these users? There aren’t many of them, and they certainly won’t have the highest profit margins. They’re hard to plan for. They’re
requirements change too much, they’ll just want something different next time…”

“That’s not what we designed Jira for…”

No matter your argument against customers using your stuff in ways you didn’t intend… [CLICK]

[NEXT SLIDE]

Empathydebt: 
don’tknowyouruserswell 
orwhattheywant
What makes them tick? What common problems do they face? What can you do to lighten their load?

Not knowing these answers is what’s called “Empathy debt.” It’s the lack of deep understanding of your users. All of your users. Let’s move on.

[NEXT SLIDE]

Edgecases 
areespecially
importanttothe
Atlassian
ecosystem
Rapidadoption
Our self-service sales model and
componentized platform can create high
stakes and inconsistent experiences.
Increasinglydiverse
their familiar with to provide the most value.
Versatileproducts
Let’s get to something a bit more typical of the biggest customers on the Atlassian platform. [CLICK]

I want to talk about the often rapid adoption of our products and all the weird edge cases that come from Atlassian’s trademark guerrilla adoption strategy.

[NEXT SLIDE]

Complex
adoption
CUSTOMER STORY
From the fresh vanilla install of the latest version, to the old tired instance dependent on poorly supported apps. From the dedicated IT team to the moonlighting admin.
How do you determine what level of support to provide customers when they’re just starting out? How often do you revisit that user journey?

What about when two separate departments discover your product in two completely different ways, and have configured their instances in different ways, too? Most of
us have workarounds for those edge cases for smaller customers, but for the enterprise-level customers, those kinds of solutions won’t do.

I’ve heard people say that our products spread through organizations like a disease. Starting in a single department and within no time infecting every one of them until
everyone has their own Atlassian login credentials…

I’ve seen some things, man…

Some people wonder, where does it start? But not me, because, I know… I know where it adoption of Atlassian starts…

[NEXT SLIDE]

Freeprivaterepos
BITBUCKET 4 LIFE
Atlas Camp 2018
@TechWriterNinja
It’s always starts with… Bitbucket. [CLICK]

What? I’m serious. Come on. Look, I love Jira as much as anyone, and Conﬂuence is my boo, but Atlassian’s backdoor into every single organization in the world is
through IT or software department, ok? And that’s how it starts…

[NEXT SLIDE]

ONE CUSTOMER, MANY “JIRAS”
Organic adoption of Atlassian tools starts in a single department, like software development for example. [CLICK]
The start using Jira Software and Confluence in Server flavor. I mean, name a better duo, right? Easy sell. Then [CLICK]
Suddenly the finance team is onboard with a little Jira Service Desk action, and turns out they have a need for Jira Software as well. But they don’t have time for installing
and upgrading software, so they go with Cloud versions. [CLICK]
You get where I’m going with this right? It’s not hard to imagine that now the Support and Implementation teams are doing it too. Apparently there’s a very liberal CFO at
this office and this company likes to give teams autonomy over how they conduct business.
This is ok for a while, but as organizations grow and mature their needs start to change. They’ll hire a new CFO, one that’s a bit more strict, and that new CFO is going to
ask for some reports about how these teams are doing. Each report will look different and probably measure success in a different way. This makes it hard to predict how
the business will do, and doesn’t help improve decision making with inconsistent reporting.
So, now we consolidate, so that everyone can get on the same page, which helps with maintenance, reporting, and sharing best practices.
[NEXT SLIDE]

ONE CUSTOMER, MANY “JIRAS”
Man that looks so smooth and easy doesn’t it? And, with this number of instances and users maybe it might be. I wouldn’t count on it, because these kinds of migrations
tend to be very involved eﬀorts.

Why is that? A major challenge for some of our most enthusiastic customers who experience rapid growth is that everyone is taking advantage of all that wonderful
versatility I was describing just a moment ago.

You get Jira instances customized to high heaven, with a custom ﬁeld for every Tom, Dick, and Harry that expressed a requirement at some point. Some very loose
permission schemes have lead to some people get punch drunk on power, which in turn leads to a nightmare trying to do any kind of actual reporting.

It’s a precarious situation isn’t it? Because you want teams to own their processes and how they use their tools, because that shows they care and that they’re trying to
make it work for them. But at the same time, what works for startups doesn’t work for companies with even modestly sized teams.

[NEXT SLIDE]

Howdousersmigrate
toandfrom
yoursystems?
As the Atlassian ecosystem we’re hoping to earn their business during their entire journey. Even if that means showing them the way to migrate away from one of your
systems.
We’re conﬁdent enough in our business model that this isn’t encouraging people to leave, but instead it builds trust in us and that we aren’t trying to trap or trick them into
giving us their business.
So when you’re planning, think about how your users migrate to and from your systems? And then, what does that look like at 10x, what about 10,000x? If it’s painful at the
smaller scale, you can bet that the pain will be compounded for larger, more mature enterprise organizations.
[NEXT SLIDE]

CoFounder of Assemblient, a
fresh Atlassian services
company.
An experienced digital strategist
and health professional working
out of NSW.
Regular side gigs as a startup
mentor, hackathon event
manager.
BrianHill
www.assemblient.com
This is Brian. He’s CoFounder of an Atlassian services company called Assemblient, and they’re out of NSW Australia, if I’m not mistaken.

And Brian gave me the honor of responding to one of my posts on the Atlassian Community, where I asked about Weird setups that push your Atlassian products to the
limit.

And Brian rose to the challenge.

[NEXT SLIDE]

I won’t read all of what Brian wrote, but it’s up there if you’re keen. I’ll just call out a couple of highlights.
Brian initially replied: “I’ve got a customer who’ve implemented a custom UI in Jira…” first notable thing and we’re only one or two sentences deep. Let’s keep going. “…
sitting at over 6 million issues now…”
This just baffled my mind when I first heard it. Brian isn’t done yet though. “… we modeled the key artifacts into a complex 34 step workflow for the parent issue, with
triggers off into multiple child subtasks with complex workflows of their own… was a fun piece of work.”
This bloke is mad. And you can see I thought as such in my reply.
And, of course, Brian goes on. [CLICK]
“Like many customer stories, it started out with JIRA as an issues manager for project delivery management, and built out from there, incrementally.
The power of OS-workflow sparked our curiosity for going further, so started with 1 system integration and kept going from there. We're talking a multi-year investment.
System's been running for over a decade…” [NEXT SLIDE]

Whatelsearetheyusing
alongside,orinadditionto,
yoursystems?
Ask your team, what else are your using doing with your stuﬀ you’re not including in your planning?

[NEXT SLIDE]

Doyouknowyourlimitations?
Areyourusersaware?
Areyouclearenough?
Remember that unlike some other systems, in the Atlassian ecosystem you can fudge the rules when you need to. Sometimes doing that is to their own detriment, and
sometimes you learn something new about your product.

So long as users are aware of the risks, and your limitations, Atlassian customers are a capable bunch and will accomplish some incredible things. Who are we to stand
in their way?

You’ll be surprised at what some people are doing with these products.

[NEXT SLIDE]

Edgecases 
areespecially
importanttothe
Atlassian
ecosystem
Rapidadoption
Our self-service sales model and compon
platform can create high stakes and
inconsistent experiences.
Increasinglydiverse
they're familiar with to provide the most
value.
Versatileproducts
The last type of real-world edge I want to talk about is the increasingly diverse user base that makes up Atlassian customers.

Not that long ago Atlassian was the worst-kept secret of IT teams almost exclusively. That’s not surprising given Atlassian’s roots as a bug tracking software, designed
and created by software engineers for other software engineers.

But as Atlassian has grown and broaden it’s mission to unleash the potential of every team, so too has Atlassian’s user demographic broaden to include people from all
departments.

[NEXT SLIDE]

Growing
diversity
CUSTOMER STORY
For the veterans of the Atlassian ecosystem, identifying your target audience up until recently has been pretty straightforward.
Mostly the people administering Atlassian products were IT professionals with technical backgrounds. That is, before the Cloud-y days really shook things up and
empowered anyone, yes anyone to become an Atlassian administrator.
How did Atlassian do this? It’s an interesting story and I’m glad you asked…
[NEXT SLIDE]

Onceupona
time,therewas 
aTechWriter…
Once upon a time, there was a Tech Writer… [CLICK]

Good lookin’ bloke.

Anyway… one day, while interviewing for a new Tech Writer position, the interview asked him, “we are looking to implement some new processes, and also some new
project management software. Have you worked with any that you would recommend?”

Fortunately enough, I had, and I was happy to recommend “That Jira thing,” as something I’ve experience with that I found very easy to use. The interviewer had heard of
it, and said he would put it on his list of products to review.

Not long after I accepted an oﬀer to be their Tech Writer.

[NEXT SLIDE]

MY GLORIOUS TIME AS AN ADMIN
Interview-
recommends
getting“thatJIRA
thing”
Month -1
Submit2week
noticetoworkfor
Atlassian
Month 22
Designworkflow,
createtemplates,
integrate,train
staff
Month 1
Welcome!We
boughtJIRA!
Nowwhat?
Month 0 Month 2
But, I did very little actual technical writer for this organization. In fact I think I wrote about 5 or 6 pages and some templates during my time there.

Why? [CLICK]

Because on my first day I was welcomed with “Hey we got that Jira thing… now what?” I was a little confused.

“Well, um, you need an admin to set it up I guess. It comes ready to use out of the box with a simple workflow…”

No, no, my new boss told me. He had grand plans for Jira, and intended to use it to help teach his new team the Agile methodology for software development. [CLICK]

He intended to do this by prescribing a rigorous, 22-stage workflow for all issues touched by the engineering team. You see a big part of this effort was that we had hired
a considerable number of offshore contractors, and my boss hoped Jira was going to help get some consistency from their output.

Oh you should have seen this thing it was gloooorious. It had all kinds of checks and requirements to transition through the workflow. I remember it required a commit in
SVN to refer to an issue before it could be closed…

It seemed like a good idea at the time. [CLICK]

Well it didn’t take long for the dev manager to begin phoning me, using an actual telephone, to ask me to create exceptions to this intricate workflow that me a few
colleagues laboriously built after months of requirements gathering and testing.

Comprehensivesupportdoc
Clearlywritten,thoughtful,up-to-date
documentation.
InvestmentinUX
Simplifyingadminsscreens,optimizingfor
moonlightingadmins.
I worked there as the admin for two years, and I was fairly successful carrying out the ambitious goals prescribed by my manager, despite my having no real prior training
as an admin. Why?

The way I see it there are two reasons for this.

First, Atlassian invests heavily in UX, and it shows. I didn’t know it until I started working here, but we spend considerable time sparring the copy within our applications.
And Atlassian employs a small army of UX designers, researchers, and writers whose sole job is to understand how users get things done, and how we can better
optimize their experience.

That job is never done, but my success as a moonlighting admin I attribute to Atlassian’s success in lowering the barrier of entry to administering their products.

Which leads me to the second reason for my success, and that’s Atlassian’s commitment to providing comprehensive support documentation for its products. I know, I
know, the Tech Writer on stage is preaching about the value of documentation.

But, it matters, a lot. The documentation was what saved me, and helped me carry out my organization’s mission. It gave me conﬁdence in what I could do, and inspired
me by explaining what was possible.

By the end of my tenure there I was using the APIs to automatically generate spaces in Conﬂuence and projects in Jira according to a rigid set of requirements.
Previously I had not ever used an API and only had a peripheral idea of what it could be used for. The doc taught me the rest.

PERSONA & ROLE CARDS
Used company wide
Revisted and updated
Data-driven representations
Flexible, extensible
Nowhere is Atlassian’s investment in UX more evident than the planning materials we churn out.

In particular, my favorite tool in the UX arsenal are the persona cards. Have you heard of these? [CLICK]

To put our users into the center of the design process, Atlassian established personas to help make informed design decisions.

[CLICK]
Personas are data-driven representations of our target users. These personas are built out of 500+ customer interviews, surveys and contextual inquiries. Like real life
people, they are evolving and will change in minor ways as we get more data. Use these personas as a shortcut to solid customer data.

Another iteration of personas was role cards. [CLICK]

Role cards are for what people do in their job. Use these when you’re working with user stories, and deciding the main types of roles to focus on. Imagine my excitement
when I started to learn we already had a Tech Writer role card!

However, remember that in my previous life, despite my title, I did not do much tech writing. Actually, the persona that most matched mine at the time was that of a
system administrators. [CLICK]

However, the assumptions made about sys admins on this card weren’t always appropriate for me.

NOT THE TYPICAL ADMIN
No formal training
Secondary responsibility
Hard to define goals
Complex requirements
The fact is, I was not the typical Atlassian administrator. I wasn’t actually hired to do that job. I’m a tech writer, I write doc, that’s what I do. But I’m a team player, so I did
what I had to do to help my company to achieve their goals.

But, consider for a moment how much of the perception of Atlassian was as a result of me and how I configured the tools. A few hundred people depended on the tech
writer to configure their Jira projects correctly. No pressure.

How do you plan for someone like me? That doesn’t neatly fit into the typical sys admin role, but is critical to the success of the entire Atlassian deployment for an
organization?

Since joining Atlassian, one of our user researchers created more granular personas to try and capture this nuance. [CLICK]

You’re looking at one of those cards now.

[NEXT SLIDE]

ADMIN PERSONAS
Squeeze in admin tasks
End-to-end role
Not their full-time day job
Not typical IT admin
A Moonlighter was explained as such:

Carry out Atlassian administration responsibilities do it in addition to their full-time day job in another role. These folks squeeze in their administration tasks when they
can.

Even though administration isn't their full-time responsibility, they often have a more end-to-end role in managing the instance, integrations - and tend not to be the
typical IT administrator.

It could not have explained my role more perfectly, and it showed by my ability to do my job without the traditional training you’d expect for administrator.

And [CLICK], Moonlighter is just one of several more granular personas we use just for administrators, because it was no longer adequate to just deﬁne admins as “IT
staﬀ.”

[NEXT SLIDE]

Howdoyousupportusers?
Isitenough? 
Howdoyouknow?
The take away from my story as an admin should prompt you to ask in your next planning meeting:

How exactly are we supporting our users? Actually list the ways. Then determine, is that enough, and how do you know it’s enough?

Not every problem needs a technical solution, and supporting your users can take many forms. Make sure you’re doing all you can to help ensure their success.

[NEXT SLIDE]

MY GLORIOUS TIME AS AN ADMIN
Interview-
recommends
getting“thatJIRA
thing”
Month -1
Submit2week
noticetoworkfor
Atlassian
Month 22
Designworkflow,
createtemplates,
integrate,train
staff
Month 1
Welcome!We
boughtJIRA!
Nowwhat?
Month 0 Month 2
So, as I was making this presentation, I got curious. My buddy Matt the Intern is now Matt the Network Administrator, and still works for the same company. He’s not the
sole owner of all their Atlassian products, and we still keep in touch.

I had to know what became of all that hard work I did some 4 years ago.

[NEXT SLIDE]

So I asked him.

I ping him on Facebook asking “Yo are you still using the Atlassian instances I started?” Matt replies that he carried a lot of that work over. And sensing what I was after,
asks if I wanted to see what remains of my work. [CLICK]

You can see that I’m obviously excited about this. [CLICK] And there it is in all of it’s cringey glory.

I mean it’s not that bad, right? It’s a little convoluted, but it’s not the worst workﬂow I’ve ever seen. [CLICK]

My buddy Matt apparently disagrees, and responds by suggesting you’d need an engineering degree to read it… fair enough, Matt. He’s since cleaned it up and
optimized it a bit. But, this is my presentation and not to be outdone, you’ll have to use your imagination as to what that looks like.

[NEXT SLIDE]

Identify&measure
actualusers,whattheydo, 
&theirexpectations
Ok, let’s recap brieﬂy, I know that was a lot I went over.

The Real-World scale can be used to measure your what your actual users are doing (not just what you want your target users to do), and ﬁguring out how you’re meeting
their expectations.

[NEXT SLIDE]

Adoptionstrategy
Howmuchstuffwillusers
arrivewith, andwhataretheir
expectationsforonboarding?
Real-WorldScale
Diversitypotential
Howcomplexisyouruser
journey,aretheremany
actors?And
Versatilityexpectation
Howmuchwiggleroomwill
userstolerate,andhowmuch
dotheyexpect?
I talked through some less common customer stories and scenarios, identifying some less traditional variables to capture about customers.

First I talked about Boondocking with Rachel Writer, and the versatility of Atlassian products.

Next I described a complex adoption scenario for medium to enterprise level customers. Where organic adoption of Atlassian products helped our ecosystem with
getting a foot in the door, but then created some tough challenges to design for once our customers mature and grow.

And I ended talking about the growing diversity within Atlassian’s user base. I looked back on my time as an atypical Atlassian administrator, and how through serious
investment in our user experience I was able to succeed, despite not being the clear target audience.

Together, thinking about these variables while we build products at Atlassian has helped provide us with a fundamental empathy for our users.

[NEXT SLIDE]

Scalingshouldn’tbejustabout
‘howbigcanitget?’,alsoask
‘doesitfit,fornowandforlater?’
SCALE (SIZE) MATTERS
At the beginning of my presentation, I also bragged about tricking Atlas Camp selection committee and some of you in the audience with my sneaky use of the word
“scale.”

While I may not have given you what you wanted, at talk about how to grow with our tools, make no mistake that I feel size still matters. A lot.

But, I challenge you to not just ask your team “how big can it get,” but just as importantly ask “does it ﬁt for our customers now, and will it ﬁt for them later?” Be just as
concerned with accommodating what they currently have, and help them plan for the future and grow their business tactfully and deliberately.

[NEXT SLIDE]

Rememberthestories
Eachusecaseisimportant,andeach
userhasastory.
MakeyourownRWS
Everycompany,product,anduserbaseis
unique.
Nowwhat?
Ok John, now what?

Well, ﬁrst, I hoped that you all would remember the stories I told here during your next planning meeting. I don’t mean I want you to remember the details, just that your
users are diverse and complex people, and learning about them is to your own beneﬁt. And not understanding them completely is to your own detriment.

And of course I want you to make your own Real-World Scale. You don’t have to measure the things I laid out here, but you need to be measuring something about your
users. Doing a good job doesn’t mean stop supporting customers after they’ve paid you.

[NEXT SLIDE]

Measure
yourempathy 
foryourusers
Ok John, I get it, empathy is important.

Remember the goal of what I’m trying to convey is a need for you to better understand your customers. A need to build up your empathy for them, and their
expectations.

How exactly do you get a better understanding for your users? How do you get more empathy?

[NEXT SLIDE]

OUR NO-BULLSHIT GUIDE TO UNLEASHING YOUR TEAM'S POTENTIAL
Atlassian has something for that!

It would be irresponsible of me to not mention one of the favorite things Atlassian publishes. And like all of Atlassian’s best products, we give it away for free.

I’m talking about the Atlassian Team Playbook. Now this isn’t a new thing, but it’s still (in my mind) an under appreciated resource we put out, and I ﬁnd myself referring to
it a lot in my day-to-day work.

For those not aware, The Team Playbook is a collection of templates with step-by-step instructions for tracking your team's health, and new ways of working. We call
them “plays," and you use them to help build your team’s Get $#!τ Done™ muscle.

You can use the plays on their own, or together with Atlassian tools. We developed the Team Playbook internally at Atlassian to transform the way we work. And it has. I
can personally attest to having used many of these plays working for Atlassian, and even helped design and test a few.

[NEXT SLIDE]

Customer
interviews
Sparring
Journey
mapping
Experience
canvas
PLAYS TO HELP BETTER UNDERSTAND USERS
The Atlassian Team Playbook is a great place to help you get started.

It has dozens of different plays that can help you do everything under the sun with regards to working on a team. And lots of the plays are especially useful for improving
your empathy muscle.

The first and most obvious play to have a look at is [CLICK] the Customer interview. It’s the simplest and most direct form of feedback you can get. The play has some
email templates to help you get started, as well as lots of thorough, industry-leading advice about why and how to conduct a customer interview. Worth checking out.

Next up is my personal favorite, [CLICK] Sparring. Sparring is a structured way to get peer feedback from teammates and stakeholders. A fruitful sparring session can
help you reach specific decisions that will take the project forward. We do heaps of Design Sparring at Atlassian, mostly around early iterations of solutions to hairy
design challenges. Sparring looks different every team, even within Atlassian. When and where you do it is totally up to your goals and bandwidth. The fresh perspective
from people outside your team can often reveal some surprising gaps in your plans. Give it a shot.

These next two are the most fun of Atlassian plays to run, and tend to be the most revealing.

Journey mapping [CLICK] helps you visualize how customers experience your product or service, and how they feel along the way. You would use this play to help you
understand the existing journey from a specific persona's perspective so you can design a better experience. If you're struggling with shared understanding, proof of
concept, or customer centricity on your Health Monitor, running this play might help.

Last but certainly not least is [CLICK] is the Experience canvas, which you can use to help clarify precisely the problem your project is trying to solve, the customer(s)

go.atlassian.com/empathy-debt
Atlassian even has an entire category of Plays just for solving empathy debt, and I insist you check them out. I created a go link to streamline the process a bit.

So if you want to jump straight to the plays (the templates), which can be accessed and used for free, right now, go to “go dot atlassian dot com slash empathy dash
debt”.

[LAST SLIDE]

Thankyou!
Thank you.

Planning Atlassian Apps for Real-World Scale by John Paz

Recommended

Recommended

More Related Content

Similar to Planning Atlassian Apps for Real-World Scale by John Paz

Similar to Planning Atlassian Apps for Real-World Scale by John Paz (20)

Recently uploaded

Recently uploaded (20)

Planning Atlassian Apps for Real-World Scale by John Paz