Establishing a Technology Partner Program with Atlassian Dir, Product Partnerships Rich O’Connell

Rich O'Connell from Atlassian walks through building a technology partner program, from defining your why to scaling operations. He uses a crawl-walk-run framework: start by listening to partners and customers, move to a basic website and application process, then formalize with tiering and quarterly reviews. The biggest mistake is assuming your opportunity matches what partners actually want.
Questions this video answers
Assuming the opportunity the company sees is the same opportunity partners see, and adding too much rigor and process too early instead of allowing messiness to emerge and staying connected to customers and internal teams.
Yes. A dedicated integrations product manager is vital for tech ecosystems, regardless of program maturity, because they help internal platform teams build the right platform, provide subject‑matter expertise, and define what good integration looks like.
Chapters
So welcome everyone, thanks for taking some time out of your day to chat about all things partnerships. The focus of the session today will be on starting a partner program and I'll share some ideas around areas to focus on. We'll then cover how to evolve the program, how to deal with common challenges and situations, and we'll have some formal Q&A at the end as Lindsay mentioned, but please submit questions as we go, as you see things that are interesting, and we'll get to them towards the end. So let me start with a quick intro. I'm from Dublin, Ireland. I moved to the Bay Area several years ago with my wife and two children. Over the past 20 years or so, I've been lucky to work in a variety of partnerships roles across these companies. I'm currently working on the product partnerships team at Atlassian, where I lead our relationship with Slack, Microsoft, Zoom, and Zendesk, which is a lot of fun and a very dynamic area to be involved in. My email is also here, so feel free to reach out if there's any questions we don't get to cover today. I'm happy to continue the conversation. So let's dig in. So before deciding what kind of program you're going to start, I think it's important to think about why you're embarking on this journey and also how you're going to do it. So thinking about why questions can be helpful in determining the structure of your program, but also what teams need to be involved and engaged at your company. So some examples of why might be to increase company revenue, to fill gaps in product offerings, to grow via partners, or to expand distribution channels. There's no right or wrong answers here, but having a clear sense of what you're trying to achieve will really help navigate and evolve the program as you go. So I think a helpful step is to really also critically evaluate if your company culture and leadership is going to be partner-friendly. Or if you've got some work to do to move people in that direction. So some areas to look at here could be: do leadership have previous partnership or ecosystem experience? Will executives champion and support the initiative? Do you have a culture that's supportive of third parties? Do internal teams want to build everything themselves? Are marketing folks and comms folks very protective about your brand, or are they going to be willing to involve partners? Do you have a platform-first culture which already considers third-party developers, or will this be a completely new way of working? So questions like this can really help identify areas that need attention or changes in orientation as you go. On the topic of how you're going to run the program, some areas to think through are: will this be a sales-focused program with revenue or segment goals? Will it be more of a product or a technology-focused program, API-based, focused on gaps in product offerings and customer needs? Or even will it be more of a marketing or distribution-focused effort? I think the other set of things to always have in mind are, are what your partners are going to need to be successful. So this is far from an exhaustive list, but some things to think about are: is there a large opportunity for them? So to get people interested in working with you, the opportunity needs to be attractive. What data do you have on the addressable market size? Are you willing to share that data with them? Transparency with partners is also key here. So many folks think that partners only want to hear good news or shy away from some challenging conversations, but I found the opposite to be true here. When we're talking about B2B or B2C partnerships, having an open and honest dialogue is really key to helping partners be successful. So get them updates early, especially if it's going to create headwinds for them. Point number 3 then, so partners are going to want access of all kinds. Access to your product teams, access to marketing teams to chat about marketing and PR, access to customers and leadership. So you'll need to make a call on all of these requests and define what's appropriate based on your goals. Early notice for changes is also vital to get in place Things like breaking changes on APIs, legal or compliance changes, regional requirements, updates to your internal roadmaps or new product launches. Anything a customer may ask about, partners are going to want and need to know. Support is then another big area. So what are you going to be able to provide folks here? What channels will they have? Make sure you're negotiating the right support based on the goals you have for your unique program. The co-optation piece is an interesting one. So what areas do you potentially compete with partners? This is a common scenario, and we deal with it all the time when you work in partnerships. But you do need to think about the issues that may arise here and figure out how you're going to address them. And then last but not least is kind of access and validation with your customers or new customers. So partners want to grow because of the program. So how are you going to showcase them to customers? So how to get going? I mean, as Nike or Nike likes to say, just do it. Just do something. Don't get bogged down in procrastination or planning or architecting the ideal thing. Just do the next logical thing. We'll unpack this more over the next few slides, but if you take anything from today, just get started and try something. So some concrete ideas on what you might try and do I've used a crawl, walk, run framework for the next section just to break it up into some logical steps you can take on the journey here, but you can decide what's most helpful for your business. So when you're trying to crawl at the start of this journey, I mean, talk to as many people as you can and collate their feedback. You know, other partnerships teams will be willing to brainstorm or share their learnings. Entrepreneurs and accelerators are more than happy to share thoughts on the opportunity or what they'd like to see from you. Internal teams are often happy to give you a checklist of what they'd like to see from partners. And customers are, of course, key here. So find out what they want and need, and then use that to help shape your thinking. We've covered point 2 a little bit already, but as you're getting started, keep an eye on where you want to be in the future. Will you have services partners, or only tech and developers? What internal tech might need to be built to support the program? Do you eventually see yourself being a global program where you have thousands of partners, or will this something be smaller and much more focused? Point number 3, then, look for internal champions. So as you're chatting to internal teams, look for folks with previous exposure to partners that might help you show the value that they can bring. They might help champion the cause with you and help establishing your program. Big early in the process, it's also really helpful to showcase some customer wins. These can be anecdotal, but small success stories involving customers and partners can really show folks that you're on the right track here. And then a related point is if you can also show some early wins for sales teams. So these may not be the focus of the program, but sales can have a pretty loud voice at the company. So making sure they're, they're bought in can be very helpful. So moving on to the walk stage. So by now you have some idea of what you're trying to achieve. Some early partners are engaged. Customers' internal teams are starting to see some value. What's next? Now I think about establishing a kind of loose formal program. Very much an MVP. It can be a little bit rough and ready. But you should really be thinking about adding some process and operations to support the program. So simple things you can do are a website describing the program, some kind of an application process, listings for partners, some kind of an annual calendar to get into a cadence with your partners, you know, what you're going to give them, what they need from you. I would say don't gold plate here, you know, don't assume you know everything, you're still learning. You may not know what exact types of partners are going to be successful yet. So give yourself a lot of flexibility to adapt and learn as you grow. And again, try and keep that beginner's mind, but continue to give your customers and your partners more to work with. At this stage, you might begin considering an informal tiering of partners. So in general, 20% of your partners bring 80% of your value. So how can you find those and focus on those? This would be an internal classification, though, and not to be publicly said. Signaled at this point. You might also want to start bringing in more formality around kind of check-ins with your cross-functional teams. So how are partners going to have exposure to those teams on a more regular basis? Will there be a real-time connection with partners via something like Slack? And again, there's no right or wrong answers here, but having an idea of what you need is going to be helpful. I think a key thing here is also really stay connected to your customers. So it can be really tempting to focus solely on your partners. But customers are ultimately going to decide the success or failure of the program. So make sure you stay in touch with them as your most important stakeholder. So onto the run phase. At this point, you have a good sense for what's working and you're thinking about expanding the program. So you should really be looking at how to bring more partners into the program or how to keep the quality bar for partners high. For both of these goals, having some objective criteria to assess partners against could be helpful. You could also consider making some of that public at this point. A simple way to do this is to have a look at your best performing partners and deconstruct what's making them successful. So this can really help you decide what formal criteria should look like. You might also consider segmenting partners or creating different categories of partner. A signal that you could do this is if you're seeing customers use the service of multiple partners. If they're offering different kinds of value, they might need to be categorized and supported differently. Again, your 80% rule may change here with different categories, and you might need to figure out ways to champion smaller or newer partners versus incumbents. This is really important to keep the ecosystem healthy and to continue to spur innovation here. More partners is then going to mean more process and data needs, so you might want to consider something like a partner portal, so somewhere you can share data, manage support, facilitate onboarding in a scaled manner. This is an important area to invest in by this point and can save you a lot of time down the road. You might also consider some kind of a formal performance management system for key partners, so Many companies use things like quarterly business reviews. You might cover things like strategy, performance versus peers, but the real thing is to get to continue that regular open and transparent dialogue with folks. And again, the last step is really never lose sight of what your customers need, what's working for them, what's not working for them, and make sure the pro— the program itself continues to evolve. So I thought a short worked example might help here to make these ideas a bit more concrete. So, you know, many folks will know Facebook has a large and robust technology partner program. It involves hundreds, if not thousands, of partners at this point, and it brings some material value for Facebook and its customers. I've kind of mapped out the crawl, walk, run framework versus their revenue growth to show a way of applying the model. So their crawl phase ran from 2009 to 2011 with their Preferred Developer Consultants program. So these were actually mainly services partners, so small teams of people who were helping customers find more value on Facebook. Very MVP-like as a program, you know, really focused on finding customer value, building internal champions, and getting signals around what a good partner looked like. Also good to note, this stage lasted multiple years, so no need, no need to rush through phases of evolving your program here, as that process can be pretty natural. Their walk phase then ran from 2012 to 2014 with their preferred marketing developer program, and here they introduced concepts like a formal program website, application processes, partner listings and badges, and then added different categories of partner. They also invested quite a bit in the backend infrastructure to support the program and manage partner quality. Then their run phase started in 2015 and is ongoing with their Marketing Partners Program. So again, this brought a renewed focus on quality criteria, adding specialties, adding hundreds of new partners. It also really formalized their business review process. In some cases, there is annual planning with legal agreements. And then a lot more infrastructure to support and enable that volume of partners. And as you can see, the results have been pretty successful for Facebook and its customers. So I'd like to end with a few common challenges and a few key takeaways to keep in mind. So some common challenges, so giving partners too much access too early. So when you introduce a partner to a customer or an internal team, they're going to assume that this is a quality partner. So be really mindful about any implicit signals that you're giving and objectively manage expectations around those. Number 2, then, folks buying the market. So this is an interesting one. So in dynamic ecosystems with large opportunities, you might see larger companies enter and try and capture market share with low pricing. So this is a big red flag and can result in a race to the bottom for everyone. So partners need to make enough profit to continue to investing and innovating, so make sure your program allows for that. Concentration in too few partners can also be problematic. This is kind of like putting all your eggs in one basket. If those partners change focus areas, it can leave you with big gaps in your partner offering. So things that could happen here is a partner is acquired by a competitor, a partner just fails as a company and stops trading, they might decide to focus on other ecosystems or geographies. So make sure you keep a healthy pipeline of up-and-coming partners here. And then breaking changes. So I mentioned this already, but this is always going to cause headaches. So make sure internal company changes that might impact partners are flagged and communicated early. It's very easy to allow these slip between the cracks, and negative impacts for partners can be huge. Very important to get this right for trust, credibility, and even your own sanity, especially as the program gets bigger. And then last but not least, I think a few things just to always keep in mind. So, you know, try and keep things as simple as possible. You know, always try and do the most simple thing next. Partnerships is a very complex space, so you sit between multiple cross-functional teams. Products and platforms themselves can be very complex. You have legal and compliance environments that are getting increasingly more complex. So with that in mind, to give your program a really good chance of success, keep it simple. Keep your goals pretty simple and try and navigate the complexity in that way. I think also have empathy. So again, this is a really important one. In some ways, you know, you and your team need to be the most empathic people at the company. You need empathy for internal teams and the complexity they're facing, empathy for customers, empathy for partners. So always assume good intent and have the hard conversations that are needed on behalf of the teams that you're working with. I think the last one then is always give a little bit more than you're comfortable with or focus on building trust. Again, this comes back to being transparent and open and vulnerable. If you don't know the answer to something, say so. If you want partners to trust you, you're going to have to trust them first. And this is often uncomfortable but invariably worth it. So hopefully that was helpful to some folks, and then I'll pass back to Lindsay.
Great, thank you so much, Rich. And just a reminder, anybody that has questions for Rich, please drop them in the question section within the event platform, or you're also welcome to click the join the stage link and, and join us here in the meeting room. Rich, we've got a question coming through here. What is the most common mistake you've seen made in companies attempting to launch a partnership program?
Well, there's a couple of things. I mean, one, um, I guess assuming that the opportunity that you see is the opportunity that partners are going to see, so not taking their perspective into account. And, you know, a growth area for you and your company might not necessarily be the same for partners, or at least a large enough group of partners to make it a program. Then also, like, just trying to add too much rigor too early, you know, trying to create processes and trying to create systems and trying to hold people accountable You know, early in the process, it's really important just to let, like, the messiness and certain things emerge and be comfortable with that. And just, like, stay connected to customers and stay connected to internal teams and make sure things are moving generally in the right direction.
Great. Next question is, for a company in the crawl stage, does it make sense to have a dedicated PM for integrations?
Um, a PM for integrations is a really vital role for tech ecosystems, and I think if you're taking integrations and your own platform seriously, that role should be in place whether you have a partner program or not, primarily because they're going to help your internal teams build the right platform for the people who are developing those integrations. But also just from a subject matter expertise and a quality perspective, that person will really learn what good looks like for an integration. So I would say there should be someone in that role, whether it's from a partnerships perspective or just a general platform perspective, because it helps those internal platform teams really get that external view of the world.
Great. Thank you for that one. Looks like we have a little bit of a quieter group. I know it's in the afternoon, evening time for many. Any other questions we can ask Rich, please just drop them in now. As Rich shared in the beginning of his session, he's open to having you contact him. Obviously, you can always find him on LinkedIn as well. So to continue that conversation for another time. Looks like we will probably then close out Q&A now, Rich. But we thank you so much for joining us today. We thank all of you for joining us as attendees in today's session. And enjoy the rest of the afternoon, evening, wherever you are. Thanks again, Rachel.
More from Jason

Why Your Next Hire Should Report to an AI, Tragedy Apps, and Too Many AI SDRs? | The Agents #004

Our Agents Drove Our Salesforce Bill Up 80%, Marketo Hates Agents, and We Stealth-Churned Off Notion

Managing 20+ AI Agents: Lazy Agents, Our $500K AI Bill, Stealth Churn & the Death of 60% Solutions







