Secrets of the Partner Series — Technology Partners — Part 1
A sign of a very healthy product (software or hardware) is a robust ecosystem of partners with product integrations. Just look at all the third-party products for the iPhone (or Surface Pro 4 which I am typing on now). My first role at VMware was to Product Manage from the Business Units point of view the vRealize Operations product Partner Ecosystem and Partner Program. My partner in crime was Justin Griffin,
who owned the partner program and the vRealize Operations product infrastructure needed to produce great integrations, called Management Packs. This is the first of three blogs on building the right technology partner program, how your product needs to adjust to provide the best value for customers and partners and how to make that work in a large scale corporate environment.
Wayne: Justin, as you and your fellow colleague started the program even before I arrived, can you tell us what was the original motivation for the need for integrations and partner programs, and how you drove the multi-release product roadmap for the APIs and SDK needed for quality integrations?
Justin’s Answer:
Well, the main motivation was driving more product revenue growth. We were having success selling vRealize Operations for vSphere use cases, but when faced with supporting heterogeneous environments or elements beyond vSphere, we didn’t have a solution. Solving this would enable us to expand our footprint in existing customers and win over new customers who required a holistic solution. We had partnerships with nearly all the vendors that customers wanted integration to, granted on some other product front. So leveraging those seemed like the right approach when compared to the cost to develop internally. Of course, the heavy lifting internally was setting the product up for these types of integrations. We had to drive a switch from internal, undocumented integration hooks to an API which could be used externally and was also adequately supported by an SDK. Balancing this work with core product feature development was certainly a challenge. Especially given that the revenue we expected to derive from that work was largely indirect. We took a forward-facing approach to this challenge. In many cases first building APIs and SDK content for newer capabilities.
Wayne, as you can see, there were a lot of moving parts, working with engineering, QA, Docs, and all the organizational work we had to do to get the appropriate level of investment and attention from the core product teams. This was necessary to build the right technical environment for our partners and customers to be successful. When you joined, we started working very closely with VMware’s partner ecosystem program to help mature the partner ecosystem. I know that was one of your passions — maturing the program. Tell us more about your assessment and how you structured maturing the corporate beast.
Wayne’s Answer:
When I first arrived, the need for a well-run partner program was obvious. The Business Unit set up an early partner program without HQ’s help and while there were some early successes, it was pretty ad hoc. Those who know me know this was one of the first things we changed. We started working very closely with Ecosystem Engineering, the Partner Ecosystem folks at VMware. One of my early observations was that the self-assembling nature of early immature efforts was very apparent. It took me two weeks of meeting about 5 people a day on all levels in all organizations to figure out the different organizations involved, who did what to whom, and who the real leaders on the organization chart were.
There was an early setup of the program modeled after an early and quite successful ecosystem program at VMware. One where VMware completely dominated and controlled the ecosystem. Either you were certified with VMware, or it didn’t work and was not supported. In the Systems Management business, the lines were not that well defined. People integrated when they wanted to, and when it made sense. We wanted a private program as our API and SDK were not quite ready for 100s of integrations as Justin commented upon. I had to temper the inexorable desire by the ecosystem folks to scale big early, make money with the ecosystem partner fees and support, and to work with every partner who requested an integration. We needed collaboration to figure out staffing models as we scaled (tied to the fees I wanted to keep low, this was a constant battle to get the quality and timeliness of support right). We needed to address the legal issues in the program and to try to phase the program maturity to match the product maturity, the huge revenue growth vector the product was on, the SDK maturity, and the alignment of what the technology partner ultimately wanted — VMware to bring them business.
We had weekly meetings with the ecosystem folks and worked with the system to improve the program, working closely with key collaborators at many organizational levels. The biggest issue I saw was aligning partner go-to-market needs with what we were able to do (and were comfortable doing). How much could the Ecosystem Engineering folks do and how much would the BU be able to do? We were learning with each engagement with a partner what worked and what didn’t. In the second blog, we will discuss some of the tough lessons and alternations we had to make to make sure we could grow the program successfully.
Justin’s Parting Shot:
Once we really started engaging with the partners, the value of a quality SDK and enablement became very clear. In fact, we began to see that we could spearhead a new high-quality standard for how products in the Management Business Unit should enable partners. As Pat Gelsinger once stated, a sign of a successful product is a successful ecosystem. However, working with partners and prioritizing those efforts brought a whole new realm of product management challenges.
Originally published at fromchemistrytoclouds.com on March 14, 2017.
