I'm delighted to have on our show Doug Gould, who is very experienced in partnerships. He is currently leading ecosystem partnership in LaunchDarkly and before that he was in AWS leading partnership with startups. Previously he was in Microsoft and before Microsoft he was building community in a VC fund. Doug has a lot of great experience in partnerships and I'm really fascinated by what he learned managing partnership in all those companies. Specifically, a very interesting concept about minimum viable partnerships, in which we dig deeper later on.
3:00 – Starting in partnerships
5:00 – How partnerships are different from alliances and communities
8:00 – How #businessdevelopment and #channel sales have evolved into platforms and ecosystems
12:00 – What is a partner #ecosystem [really] and what are key principles of developing one?
15:00 – How AWS builds its partner ecosystem?
17:00 – Which best practices you can learn from AWS to succeed in partnerships?
21:00 – Minimal Viable partnerships - how to start in partnerships with minimal efforts.
26:00 – Goals, KPIs and market testing in partnerships.
Starting in partnerships
Doug, you have very rich experience from working in partnerships in companies like AWS, Microsoft, and LaunchDarkly. You've done a lot of interesting things in partnerships, but let's start from the beginning, what actually got you excited about partnerships in the first place?
When I kicked off my career, first of all I really wanted to get into technology. That was the big thing. I really loved the technology industry, I always liked to geek out on new technologies. And going through school as a business student, initially, my background was in finance. And that was the first role that I took and ended up getting a job at a big company, Intel, the semiconductor manufacturing company.
I was hustling, trying to get into the startup world, learning as much about all the different roles as I could, and started to really get excited about business development for a couple of reasons.
One, is I was able to take a lot of the business acumen that I had learned as a finance professional, being able to run analysis, strategy, playing around with numbers. But then also, I had this yearning to get out of a cubicle and get out of 8 hours of Excel all day, and go and talk to the market and to the industry. And I felt like business development was a really cool mix of being able to keep that strategic aspect, but also being able to go out and have that interpersonal relationship building that I was really excited about doing.
Those are the two things, but really, when I'd started had very little idea of what business development was. As I've started to learn, there's many different types of roles within business development and partnerships, and have navigated towards where I feel like I make the biggest impact.
You've build communities, you were working on business development and now you're building ecosystem partnerships. Can you explain what is your take on how these different ways of doing partnerships in different companies stuck up into some sort of holistic picture.
I think that one of the biggest takeaways that I've learned across all those different companies that you've mentioned, is that there are two things that are really important, it's engagement and value creation. And whether that's when I was at a venture firm called Kairos and led the global community there. Very similar approach it was - are we actually engaging our community and keeping people bought into the mission of what we're trying to accomplish? And then also, are we mutually creating value?
there are two things that are really important, it's engagement and value creation
We making it really clear what those community members are supposed to be doing, as well as making it clear to them what we as an organization are responsible for delivering. And if you look at successful partner programs, Microsoft is a really good example, AWS, they've done a really good job of doing both of those things. They create a lot of programs, a lot of ways for partners to engage. AWS, for example, has things like their competency programs where you can create a specialization in a certain area and get specific benefits for that. And then they make it really clear what the partner needs to do. I think that they are always delivering new things that keep their partner community engaged. And then they're making it really clear where the value is generated as they continue to grow and expand their partnership programs. I think over the many different angles of the things that I've done, whether it's strategic technology, partnerships, its alliances, and go-to-market partnerships, and even community building at a venture fund, the constant theme that I've learned is it's really about engaging the right people and then creating value for those people as you continue to mature the relationship over time.
That's a really great insight about value creation. But let's dig a little deeper on that. You were in a venture company building a community and then in Microsoft. How do you differentiate in your mind between ecosystem alliances and communities, for example, and business development, which is an extra bonus layer I would say?
They're all very neatly woven together. It's all about the way that your company is engaging the outside world and the way that you give and get value from the outside world.
When you look at ecosystem - ecosystem is about being strategically engaged with the right key players. And then having points of product interoperability or technology partnerships to be able to drive the influence through the broader market along with some of these other technology vendors.
With alliances, I think it comes down to more around you're doing a lot of go to market and co-selling. The main KPI that you're driving there is in total dollars in revenue. I think they're different flips of the same coin. On one hand, it's a little bit upstream, thinking more strategically and deeply about what the story is to customers? What's the level of product engagement that's driven? How are you actually throwing in some of these more relevant product KPIs to the conversation? On the alliances side, it's really thinking about new business value creation, as you continue to go to market with another organization.
And then the community is really important in driving both of those. The community itself is the way people are starting to engage with your platform or your product. You want people to be thinking highly of you, constantly engaged with your product and your organization. That drives people into that top of funnel that big door that you're starting to open up so that everybody is able to find a place within the product or technology that you're building. I think that having a strong rooting in community has been helpful for me as I continue to build my career. Thinking about, for example, ways that we not only connect with our partners, or people who are building technologies to interact with our technology or our platform, but also ways that we can potentially connect those people with each other. As we continue to grow, how are we adding value by bringing some of these other groups that are like minded together? And that continues to make our position in the market stronger. It makes us more of a kind of a planet that others end up orbiting around, as we continue to grow and mature.
What is interesting about it, is that you have both actually top down understanding through your finance background, and then obviously a bottom up also based on communities. Just going back to your examples of definition of partnerships and alliances, how do you see this subject matter, which is business developments and channel in general, how is it evolving in the last 10 years? What is changing? Maybe if you give a couple of examples from any of your great companies you worked on, it would be fantastic.
It's a really great question because I think when I started my business development journey, I found that a lot of roles that were titled as business development were actually sales roles. And there was a very strong connotation to channel when you would talk about business development. But as organizations through the development of, for example, API's becoming much more available, organizations starting to build out much more strategy around being a platform, it started to evolve into thinking more about ways that you can, again, build a piece of technology that other people can plug into, and you can plug into other people's technologies. And I think that's where the phrase ecosystem over the last couple of years has started to really catch hold.
But if you look at when I first started, it was interesting to see the evolution because you had a lot of business development, again, focused really on channel. And then that started to evolve into everybody building a marketplace. There was a period where marketplaces became this really hot topic, and everybody started to build them up. I think that's subsided. And now, what's become a lot more clear is, every organization, every company wants to become a platform company. And these roles of ecosystem are about really driving a lot more value into that platform strategy.
And now, what's become a lot more clear is, every organization, every company wants to become a platform company. And these roles of ecosystem are about really driving a lot more value into that platform strategy.
Defining the platform strategy of saying, this is the programmatic way. We, for example, have a technology partner program. A programmatic way that we can bring people in, but then also making sure that you're really deliberate and intentional with when you go out and you develop integration points, that you're doing it with the right people. I think that the API has been a big piece of that evolution in the early days. I remember seeing some BD partnerships, I think Instagram leveraged Foursquare as part of their Places capability back in 2011-2012. And use that as an example of a really interesting business development case. That was pretty cutting edge. And now if you look, there's things like that happening all over the world.
There's a product that you're using that's powered by some other servers or technology that's either public or hidden underneath, and I think those partnerships, as technology has continued to get more sophisticated, have just started to explode. It's again, kind of touching on the originally it was all about channel and everything was really about focusing on driving deals through either partner channels or resellers. And now, it's become much more about this ecosystem as a topic of conversation and helping organizations develop that around their platform strategy.
There's a product that you're using that's powered by some other servers or technology that's either public or hidden underneath, and I think those partnerships, as technology has continued to get more sophisticated, have just started to explode.
A couple of questions regarding that. Obviously, not every company can become a platform, only a few companies can realistically become platforms. So there is a platform, and then there are many partners who integrate with you through the platform. Then on top of that you’re building ecosystem partners, correct?
Ecosystem is almost a mythical subject. Everyone keeps talking about the ecosystem. I think very few people actually have a clear understanding, I think you're probably one of them.
I think that the importance around ecosystem is prioritization and strategy at a high level. We've started to develop internally frameworks about how we think about going and working with other providers within our space. I'll take a step back and say, also, you made the comment that not every company is a platform company. And I agree, I think that a lot of companies might have a tendency or an urge to over-partner or over-platform themselves. And when you're doing that, without a customer at the table, it isn't going to end up delivering value.
It's important to take the approach that you have a product, that product lives within, call it in our world, a developer stack. The developer uses a handful of other services and technologies when they're using our product. We want to understand:
Which ones are the most relevant?
Which are the ones that are either upstream or downstream from that developer?
Are there folks that are on the product side or customer support side that are also getting value?
And then who are the relevant players within that space?
And how do we extend the value of our product into those areas?
The first thing that we do, it is really about understanding what that customer product journey looks like. And then thinking about that prioritization and strategy. Making sure that we go in and we work with the top providers that help us execute on what some of our high-level company goals are and product goals are. That's the big piece with the ecosystem.
And then within that, I think it's about the three things:
One, is making sure that we're always at the table, we're always a part of the conversation. We're aligning roadmaps, we're getting executive engagement at a handful of our key partners.
The second one, is making sure that we have really outstanding platform and technology that others can develop on. And that we have a technology partner program that makes it really easy for people to come in and work with us at a programmatic level.
And then on the third piece, it's making sure that we're going to market both externally, as well as supporting a lot of other stakeholders internally. Ecosystem is a role that's very cross functional, business development as a function works across many different threads. And I think it's about quarterbacking the priorities of some of these key technology integrations and key technology partners, so that everybody internally whether that's marketing, customer success, sales, etc. as well as our alliances team are fully aligned on where our product strategies are the strongest.
I think the ecosystem again, it means a lot of different things to different companies, because some companies are at different levels of maturity around what their platform strategy is. But ultimately, I think it's responsible for doing a handful of key things.
I would love to dig deeper into your experience across different companies. Because we are speaking a lot about what you're doing right now, I would love to hear your version of what LaunchDarkly is? And why is the company compelling? I found it compelling because I saw your founder speaking and was really impressed by depths of insights in technology and also the humility she has. I've also heard that the company is quite entrepreneurial. Tell us a few words about LaunchDarkly.
LaunchDarkly is a feature management platform. We help our customers be able to launch and deploy features, with confidence, and be able to do that faster and more securely. And the primary way that we do that is we have a platform that manages feature flags, that's where you're able to turn on or off features depending on who, where, when any type of logic that you want to apply to how that feature is represented within the product. And that gives teams an incredible amount of control. And that control can be useful if they want to do everything from understanding if a new feature is going to severely impact their infrastructure? Or on the flip side, they want a product team that would like to do some experiments and understand how this feature affects a user? Do they spend more time within the app? Do they click this button? etc. And it's at a high level really about helping teams be better software development organizations and be able to be much more efficient in the way that they go about building, deploying, releasing software?
We already know a lot about your ecosystem strategy for LaunchDarkly. Let's go deeper into your experience. Previously you were in AWS. AWS famously partners with a lot of startups and you were leading this effort. What did you learn by partnering with startups in AWS?
In my AWS journey, I worked on a couple of different areas of their partnerships. First, I worked on the partnerships that AWS has with a lot of incubators, accelerators, as well as third parties like Carta, Stripe, etc. And that was primarily around engaging startups through the means of deploying startup credits. AWS has an amazing program called AWS Activate.
It's an industry leading platform and product that AWS offers out to startups or service.
I started working with the AWS team back in 2011, when I was at a startup called Cloudability. And we were one of the first partners as part of their Activate program to be able to create a deal that was part of Activate for startups. And I followed that program and that team, and I felt like they just did an amazing job at being very long term oriented with how they would partner with startups. Instead of taking a very sales heavy approach, AWS has a lot of services, they have the credits, they have a lot of support from their team in order to get startups up and running, knowing that if they do that with the right companies, they're earning the trust with these companies that will make them a customer for life. And I worked on a handful of partnerships with these organizations to drive engagement, specifically with startups. And we were talking about thousands and thousands of startups - very, very high volume.
Then, I transitioned into a role on a team within AWS and their AWS partner network. That was focused on growth stage startups and partnering.
AWS has three components of the way that they build partnerships.
There's build, which is building technology, strategy, technology, partnerships.
There's a market - webinars, case studies, co marketing, etc.
And then the third one, is sell, this is co-selling.
AWS has a lot of programs and initiatives for companies to take advantage of going to market as well as the AWS Marketplace. And I managed a handful of partners in the machine learning space, as they were building out their initial partnership with AWS. And again, I'll say that I felt the AWS team is really industry leading in the way that they would support startups in that way. Most of these companies were at Series B and above, they were still building out their product-market-fit, defining their core personas, but the AWS team, our goal was to really spend time with a lot of those companies to help them flesh out a lot of those things and then support them as they went to market with AWS. And I really enjoyed the time that I spent there. AWS is a very strong partner organization. And that's clear across the different things that I did. On one hand it was working with startups and organizations that supported startups. And on the other hand, it was working with fairly late stage, growth stage startups as they were building strategic partnership.
What are the one or two insights that when you left AWS you got about partnerships? And maybe what is the one or two insight that you typically share with startups in terms of how you think about partnering with big companies or partnering with each other?
Yeah, that's a great question. I think that the first thing that I really took away is that you have to be customer obsessed. You can't fabricate any type of co-partnership opportunity in the sense of we would have some partners that would have a desire to partner with AWS because of AWS’s large footprint in enterprise or the total number of customers that AWS would have.
most compelling partnerships were really around when there's customers that are getting true value, or telling you that they're going to get true value out of these technologies working together. And I found that the Better Together story, it has to be very crisp, clear, something that can be described within a couple of sentences.
But, when we would start to dig into what the story was, the Better Together story between partner and AWS. There wouldn't be a whole lot there, it would be very clear that we were just fabricating a story for the sake of supporting the hypothesis around this partnership. And I found that the most compelling partnerships were really around when there's customers that are getting true value, or telling you that they're going to get true value out of these technologies working together. And I found that the Better Together story, it has to be very crisp, clear, something that can be described within a couple of sentences. If you start to kind of ramble on about, well, we want to partner with AWS because we see an opportunity to co-to market, co-sell yada yada, customers don't care about that. What the customer really wants to know is, what's the value of using AWS and the partners product together.
It was always about, what does the customer really want? How do we build that story? And then how do we package it up so that not just the partner, but also AWS can go out and tell it to the market.
And the partners that really got that were the partners that spent time understanding their own product, their own customers, and then being able to bring that perspective back to AWS. And that would allow us to start to do some discovery. Whereas partners who would come with a very, call it revenue sales perspective, and say, we want to go drive a million dollars of co-sell with AWS tomorrow, how do we figure that out? And those types of conversations were always very uncomfortable because there's no easy answer, there's no easy fix to being able to solve for that. It was always about, what does the customer really want? How do we build that story? And then how do we package it up so that not just the partner, but also AWS can go out and tell it to the market. And that was my biggest insight. It's the biggest thing is the Better Together story. It has to be crisp and clear. And it's got to be something that both organizations feel like they're really bought into.
Completely agree. The more I think about partnerships, the more I speak with different people and then, the more I reflect on my own experience. It does seem to discuss customer obsession that Amazon is a big advocate is the crucial component. Before AWS and after AWS, you have a lot of different great experiences.
Minimum viable partnership
One of the concepts that I liked and you mentioned in our previous conversation was minimum viable partnership. I found it really fascinating.
Yeah, it's definitely not something that I had on day one of my business development career. And it's something that I have learned over failure, as I've been in new roles and understood things from different angles. But, what I really started to discuss, and this was something I worked on with a lot of early stage startups when I was at AWS was the concept of this minimum viable product. And it was really about taking an iterative approach. Amazon has this concept of a two way door. And that's whatever you go in, you can just as easily come out.
And I think for early stage companies, you hear something a lot which is that, they want to partner then they don't know how. And then, you talked to late stage companies that haven't actually done BD or partnerships. And they always feel like they're getting into it too late. And I felt there was this big gap, where people knew they needed to do it, but they just sat on it. And they maybe had too much thought into it and never actually took action. And then on the late side, it's organizations that overreact because they feel they haven't done enough and that they're too far along. And they should have done it earlier. And this idea of minimum viable partnerships was about starting to spend a little bit of time initially, as a small team, maybe a founder starts to have some initial discussions.
for early stage companies, you hear something a lot which is that, they want to partner then they don't know how. And then, you talked to late stage companies that haven't actually done BD or partnerships. And they always feel like they're getting into it too late. And I felt there was this big gap, where people knew they needed to do it, but they just sat on it. And they maybe had too much thought into it and never actually took action. And then on the late side, it's organizations that overreact because they feel they haven't done enough and that they're too far along. And they should have done it earlier.
It's about using some frameworks to be able to think about who are the relevant players within our space? How do we play into those products or services? What are some easy ways for us to test out this messaging? Are there conversations we should have with our customers? Are there people we can easily get in touch with at the partner to be able to understand what their priorities are? And just come up with a very simple and clean hypothesis that gives you something to start testing on. And I was encouraging companies even at the seed stage to start doing that.
Because what you do is you start to build that out as a foundation. You start to collect some of this data to know, hey, there's this huge company and they seem like they're an obvious partner, but we've actually tried to have discussions with them. And it doesn't work because their priorities are this and ours are this. And I think that it's important, you can have those conversations and gather that information without, for example, even having a dedicated full time business development person.
I think it's important for startups to be able to take this minimum viable partnerships concept.
Think about what is the most iterative way that you can start to build out a partnership function
and then ultimately start to do that mapping and think about who the relevant players are.
And you have data to support what you could do with those partners.
And then, you bring people in to be able to accelerate that.
Whereas I think a lot of startups, what they'll do is they will go from binaries - zero, we have nothing going on from a partnership perspective, to one. Now, we've been able to develop this partnership perspective, because we hired one person, as the BD person, and they have to figure it all out themselves, and they're walking in with nothing from day one. And I think that it's important for teams to be able to set themselves up for success through doing this minimum viable partnership.
You almost feel that it is coming from a lot of experience. I found that really insightful and fascinating. Quick question regarding this minimum viable partnership, just who should be doing it in terms of within the company, you're saying it could be founder, or it could be a BD person? How many would you launch as a test? What is the failure signal? Or what is the success signal?
I think that at a high level, what it starts with is setting a goal.
And I think it's important to be fairly metric oriented with it, and what I do is I frame out the different types of partnerships.
I say:
this is a channel partnership, the reseller.
This is a marketplace.
This is an SI partnership - system integrator or services partnership. I outline the different types.
And then I say, there are three things that you want to do.
You want to identify what the type of partnership is that you want to do. What is the ultimate goal?
What's the KPI that you're tracking or measuring?
And then the third piece is, what is the timeframe that you're interested in being able to commit to this.
Those three things are important to build the hypothesis. And sometimes that will be a founder, sometimes that will be a business lead, sometimes it'll be a head of sales. It depends on what the goal is. Even could be a Chief Product Officer or Head of Product.
Because it's about just really thinking through what are we trying to accomplish here:
Do we want more users?
Do we want more money?
Do we want more influence within the market?
Setting those goals up, giving them some KPIs, and then putting a time box to them are the three things and then once you've been able to figure out that goal, it very easily maps to somebody within. The audience usually is a small team, and it could be a founding member of that team.
And the idea is that person takes that on as a side hustle research project, that they go out and they start to define. And I really emphasize the back of the napkin, it doesn't need to be long. It doesn't need to be complex, but it needs to be concise and it needs to be specific. What I'll get sometimes when I was at AWS is I would have startups reach out to me and say, we want to partner with Amazon. And I would say ‘Great, do you want to do robotics? Do you want to do space? Do you want to do e-commerce?’ You can't reach out to a lot of large companies and say that you just want to do a partnership. You have to understand the specific things, you have to have a point of view or a perspective. I really encourage teams to develop that using that goal setting framework. And then once you've developed that perspective, then you can go shop that around and see if people actually are interested. And I've pushed to startups, here's the framework on how to write a really strong cold email that you can send to somebody at an organization so that they could potentially forward or get back to you around what the conversation should be. I think it's all about capturing information and finding out who within the market,who within the industry actually cares about what you're doing. And will they actually help you towards your goal of adopting whatever the KPI is, if it's users, if it's cloud influence, if it's revenue, etc. And getting back to the minimum viable partnerships framework, it starts with goal setting. And that makes it very clear on who's accountable and who owns that? And then from there, it's about giving that time boxed ability to drive specific KPIs so that you're feeling there's some momentum. And then, what I encourage teams to do, and I say is part of the minimum viable partnership concept is that, it's not the right time for you to partner. And that's okay. And it's about giving an effort versus again, like some teams will do is they will do zero all the way until they're fairly late stage, and they'll feel they've completely under invested in this function. I'll tell them, it's important to just gather information about what you should be doing within the space and then layering on top of it when it's appropriate. But, for some companies, if they don't even have product market fit, it's good for them to go out and have some conversations, but ultimately, they have a lot more work they need to do internally. That's going to help get them towards where they need to be as a company.
That makes sense. But in your mind, the minimum viable partnership framework timewise, is it like three months? Half a year? What is the time frame?
I generally encourage months. I say it's important to give this, not one month, but within a few months to go out, to go have some of these conversations and collect information, because again, you want to make a decision. A lot of founders they need to think about ‘Do we want to hire somebody to do business development? Is this something that we need to be building out today?’ And ultimately, what I encourage them to do is go out and learn first about what is going on within the industry and how you can connect to that through the minimum viable partnerships model. And then, you give somebody the ability to go and scale that into a year, multi year type of partnership. It's a good way to risk bringing people onto the team to specifically be driving BD as a function.
I think we should have the second episode for specific details, but as of right now, I really appreciate your time.
My pleasure. Thank you so much.