Former VP, Product at Adaptavist, largest European Atlassian Reseller
Rafael is a Former Product VP at Adaptavist, the largest European reseller of Atlassian products. He spent 4 years selling Jira and Confluence across all deployment types to both large and small enterprises across Europe. Rafael has also ran engineering teams and is the current VP of Product at Influencer where he is now a customer of Atlassian using both Jira and Confluence products. Read moreView Profile Page
Rafael, can you share some background about your experience at Adaptavist and what the company does and what you were selling?
When I was working for Adaptavist we were, essentially, building applications and plug-ins for Atlassian. You have your Atlassian offering as it comes standard, out of the box. But quite often, you need plug-ins to augment that experience and to provide additional functionality. What Atlassian provides is a marketplace, where vendors can go in and deploy and sell their products through those means. That’s what I was, essentially, involved in; leading the Confluence product portfolio, at Adaptavist.
Is Adaptavist is an Atlassian exclusive reseller or do they sell other products?
In this case, Adaptavist only focused on the Atlassian ecosystem. Obviously, it’s one of the many other partners that exist in the world. Some of them focus on other areas, not just Atlassian. In this specific case, Adaptavist focuses on Atlassian, exclusively.
Which type of customers were you, typically, selling to at the time?
It’s interesting, especially from the product management point of view, because you have a huge diversity of customers, from many different types of industries, both big and small. For example, you had customers such as Uber and Apple, which are obviously massive. But then you also had small and medium enterprises that you would sell to. You have to build a product that fits the bill for all of these cases, which is extremely challenging. Even for Atlassian themselves, building something that can cater for all of these different audiences, is extremely difficult. I think that’s why they built an extremely successful product.
What were the core differences in the way that, let’s say, Uber versus the local company, deployed Jira, for example?
It really boils down to the complexity and the sheer amount of data that these instances created. As you can imagine, with Uber, they have extremely complex systems and workflows and a lot of information share. In the specific case of Confluence, they have many pages they need to share; rightfully so as it is a massive company. Whereas, if you have a smaller company, they probably don’t have that amount of data or that complexity and their workflows are much simpler. You don’t have to follow too many processes and it’s great that Atlassian really allows this flexibility. It is one of their core value propositions, which is really to do with the customization that allows for different types of scenarios.
How did the large and small companies choose the different deployment methods?
It depends on a couple of factors. The first one has to do with where you want your data to lie. Do you want your data to stay in Atlassian servers, or not? Using Germany as a very good example, there is a law in Germany that doesn’t allow your data to stay in third-party servers. For lots of German companies, SaaS and cloud is not even an option. Then you exclude the SaaS offering and you have to go with the server.
If you go with the server, we’re talking about one single instance, lying in a data center or, potentially, an AWS container. This mean that if, for any reason, that server goes down, the application will, pretty much, go down and everyone loses access to it. This might be totally doable; if the company is small, maybe they don’t need that high availability at all times. In this specific case, the server instance is just fine.
In the case of big companies, like Uber, for example, you naturally need to have high availability because having Jira, Confluence, Bitbucket or any of that down, can cause massive disruption in the business. For that, you need to have data centers. A data center, essentially, is a grid of servers that provides high availability, so that if one goes down, it automatically goes to another one and people don’t even realize that one of the servers has gone down. But at the same time, it also has benefits, in terms of performance. You can really split the performance and you can, pretty much, route some of the users to one server and some of the others to another one; it’s like a load-balancing solution. It is, obviously, much more expensive and harder to implement.
During your time, did you see a shift away from server deployment, more towards the data center and then, eventually, to cloud?
That is such a tough question because, certainly, that’s what Atlassian wants to push forward. They have made a massive push towards cloud, in general. This is because the SaaS model serves them much better than the regular one. But just to point out here that the way it works, in terms of pricing is, with the server, you have a one-off payment; you make a payment and that license is, generally, valid for life. You get what you get with just that one-time payment. Each year, if you want the support, you can just pay for the support. Initially, you pay for the support and the latest update, but your license is good to go.
Whereas, with cloud, it’s a recurring payment. If you don’t pay, you will lose your instance. As you can imagine, Atlassian wants to push the cloud, moving forward. But I think they also recognize that the cloud is also very hard to scale for companies that have 300,000 or 400,000 people. In those specific cases, they will recommend a data center. I suspect that the server offering will go away, at a certain time. But that is just my opinion.
So the Atlassian ‘Data Center’ offering allows customers to seems customers to deploy their data center on Azure or AWS, or you can deploy the product traditionally on a server? Is that correct?
You could, but in those type of situations, you would probably have everything on-prem. You want to manage it yourself and there is a good chance that you have a massive IT team that can support that. Cloud is great for kickstarting and playing around with it, I guess. It works very well and you get all the support from Atlassian but it is way more expensive than the server version. The data center option is also quite expensive. There are a lot of variables that one needs to balance and try to understand what the right solution for them is.
Can we walk through a typical structure? Let’s say that you are selling Confluence and we can compare the different models but what is the value proposition? If we take a 1,000-person company, what is your pitch; what is the value proposition?
It depends. Ultimately, it depends on if the customer goes directly to Atlassian or goes to a third-party vendor, such Adaptavist or Clearvision; there are many third-party vendors, in many different areas of the world. Adaptavist is, obviously, very strong in the UK and the US. But you also have some local ones, so you have to pick which vendor you want to work with. The difference is that if you just go to Atlassian directly, you don’t really get much support. Here’s the executable; just deploy it and do all of it by yourself. It doesn’t really provide the support.
Whereas, if you go to a third-party vendor, it can help you, not only with the set up and making sure that everything runs smoothly, but also the whole consultancy piece, which relates back to what you were asking. Why do you want to use Jira? Why do you want to use Confluence? What are your pain points? What are you trying to solve? They are great tools but, ultimately, they are just tools and you need to understand why you are using them. The developer position, obviously, has to do it with the whole customization, as I mentioned. But also price, risk reduction, the convenience are extremely valuable. Each case is each case and I think you need to understand that and that’s why the third-party vendors can really help out.