In this second blog of the Technology Partner Series, Justin Griffin and I will discuss the second chapter in our partner program and how being agile in your program is key to responding to success (and failure) as you scale. In our first blog, we discussed the need for the technology partner program, working with ecosystem engineering teams to build the right program elements and making sure the product itself could support these integrations. We had many partners really step up and build integrations. Here are short vignettes of three partners and some of the motivation and successes they had:

1. One of our earliest and most motivated partners was Brocade. They saw tremendous value in bringing data together to get more value out of it. The secret to their success from a partnership perspective was their engagement. They included their partner manager, as well as an engineering lead and product manager right from the start. This enabled the teams to move from concept to plan to execution very quickly.
2. Dell storage was another prime example of a successful partnership. They, like Brocade had good engagement, and also really embraced new capabilities to deliver strong and current integrations. The Dell engineering team met with us frequently to stay on top of new features that were coming down the pipeline. This allowed them to deliver integrations with these features very shortly after our release.
3. A third company that had great success in partnership was Hitachi converged infrastructure. While they did a great job on the development of their solution, the aspect of the partnership that stood out was their collaboration on go-to-market. They sponsored a couple of customer events and asked us to participate by discussing the value of VMware’s solutions. They then followed this up by covering their integration. This was a great example of a win-win event for both companies.

As you can see from these vignettes there was a great groundswell and success for partners who were willing to invest in the program and take things seriously versus just “checking the box”. Just as we were having success with our ecosystem engineering teams we decided to reduce the business units’ direct support of partner conversations and let the corporate folks start to drive the execution of the program. It was a good thing, in that the program was scaling and scaling meant that we in the business unit had done the groundwork to work with the extended teams to set up the program elements for success without Justin or me jumping in on every minor flare up.

Mind the Go-To-Market Gaps

Even if we were the 800 lb. gorilla in the market, we started to hear from our partners that they were questioning how much to invest in the integrations and could we help them with their go-to -market. Could we help promote, sell, close, yada yada. The list went on and on. Well you know, we had a marketplace ecosystem site. That should have been enough. We were willing to provide quotes and marketing assistance with asset creation. For the partners that were more strategic, we would help out with webinars and other more direct promotion. We gave out awards to our top integrations. Still this was not enough. We struggled with what steps to take to help with this go-to-market. Our business unit marketing team would help where they could but it just was not the priority we wanted it to be. The selective assistance actually caused more problems, as more and more partners wanted the same treatment. It became very difficult to navigate the relationships.

Cracks in the Armor – Too Many Integrations

We overcame many issues and the number of integrations grew and picked up steam from quarter to quarter. With the increased volume the quality spectrum became quite broad. They were all good enough for a dog and pony show and some good proof of concepts, but would the integrations really help our joint customers in their IT operational management? Would they help triage problems faster? Would they provide enough actionable intelligence? In some cases the answer was yes, in others it was questionable.

To combat the quality concerns, we instituted a certification program. This was a tough thing to balance as it increased cost of the partnership engagement in exchange for better customer satisfaction. So for those partners who just wanted a check the box integration, it was a little harder to swallow. The other challenge the certification presented was with the development efforts. The certification added additional time and back and forth engagement between the ecosystem team and the partners. This added complexity resulted in an interesting new breed of partners. In fact, we ended up developing a “cottage industry” of professional integration partners who got really good at scoping, building and supporting the integrations that they built. A good example of this was Blue Medora.

Ultimately we drove toward the program metrics of many partner integrations, with little support from the Business Unit. The Ecosystem partner folks took on a large majority of these integrations with individual endpoint vendors with success driven to the same metrics we were driving to as well. This success bred the seeds of reversal. Too many of these integrations were of low quality, low use case coverage and generally were good as POC-ware, but not a full -fledged integration for production usage.

Reversal of Direction

As with many long-term programs at big companies, after a few management changes and a fresh look at the program, there was a change. “Why do we have all of these integrations that customers are not that enamored with? Do we really need this many?” The core product business metrics were doing so well, “Did we really need this much emphasis on the partner ecosystem?” At this point many options were explored: do we take integration back into the business, do we anoint one of our ecosystem integration partners and focus our efforts there, or do we get strong commitments from a partner (3 year use case coverage) before we allow them into our “we get to approve” partner program? In the end, the business did a little of all three of those, attempting to experiment and see what worked. Ultimately the hand of the market voted and one of these options became the preferred integration motion. Can you guess which one?