Startup Lessons — Partners vs. Customers — Move Beyond the Kum Ba Yah and Address the Conflict
Lesson #6 from the untold stories of Appirio
This post is the sixth part in a series. The original post sets the context, provides the disclaimers, and gives a preview of all of the lessons.
Its popular for every firm to say that customers come first, just like every doctor says the patient comes first. But time and time again studies have shown incentives matter to even doctors and they certainly matter to software companies and their partners.
As a services partner, Appirio worked closely with the mega behemoths of SaaS (salesforce.com, Google, Workday, Amazon, IBM) and dozens of emerging cloud app providers. In many cases, we jointly pitched prospective accounts to help the vendor close business; in others it was only through the vendors recommendation we were brought into the customer. So who was our real customer? The tension between the end customer and your most important partner is a conflict every company working within the gravity of a mega player will need to face thoughtfully and directly.
We were clear with our clients about potential biases. For example, we only worked with cloud players and actively shared our rationale publicly. As a result our partners and customers knew we would never recommend on premise systems like Oracle or SAP. In addition, we never helped customers negotiate price. We felt like that would break trust with our previous customers and could create a significant conflict of interest with the SaaS partner.
The relationship with our SaaS partners was particularly complex where we disagreed with them on the capabilities of their product or how the customer should use it. Customers have a finite budget; so conflicts could occur in our respective views of what product capabilities and consulting services were necessary to help the customer meet their goals(e.g.how many seats / what products would they need to buy, did the existing features meet their need or would it need to be customized with consulting..). Our general approach was to try to clearly explain everyone’s biases to the customer so they could evaluate our respective advice in context.
With our partners, we emphasized that this cycle would repeat itself across many prospects over many years. We created relationships with management team members who cared about the broader portfolio of customer success and could see beyond a single prospect situation. Strategic leaders inside the partner focused their team on what’s the right thing for the customer vs how much commission will I make from this single deal. For our firm, it was a fine balance; being perceived as a sales blocker to the partner would hurt our business, but underserving customers could bury it.
The most significant conflicts with partners often came because we knew the gaps in their products better than nearly anyone in the industry. We understood how those limitations impacted our customers’ initiatives. Collectively, these gaps were threats to our partner’s long term viability.
Early cloud applications had to have 1. products that genuinely felt an order of magnitude better than legacy applications. 2. a rapid rate of product improvement that demonstrated it was a different model of innovation.
We were more forthcoming than our partners in the limitations of their products. Yet, we also attempted to keep customers focused on their overall goal and help them understand how to work around limitations. We also wanted to influence the partner to improve their product and align its capability with their message. But how was that possible without embarrassing them publicly?
On specific occasions, independently we did full internal reviews of product limitations and prepared a detailed white paper on a partner’s product gaps and our viewpoints on their implications. These were substantive exercises that took weeks or months of effort. We then sent the document to key executives at the partner with a commitment that they were the only ones that would see them.
In all cases, the partner would be appreciative. However, in some cases it dramatically increased the trust and credibility we had for one another. When we sent such a document to saleforce.com about force.com in early 2009 we were initially concerned.
If such a white paper ever got out it would be a massive competitive issue for salesforce.com. Yet their reaction to it was telling. They were open and receptive; wanted to learn more; and kicked off a broad series of formal and informal discussions with us. The breadth of the response showed us they were a company that broadly wanted to get better and knew they could organize R&D to attack the problems directly.
In contrast, when we did the same in another situation, a couple of people at the partner showed interest, but there was limited engagement. It substantively impacted our opinion of their R&D function. Did they understand and agree on the issues and their implications? Did they think they could rally colleagues to want to address them? Did their technical architecture allow for them to address the limitations? In the end, the list of topics we presented mattered less; the reaction to the list became a reliable gauge of the sophistication and capabilities of the product organization of the partner.
Our corporate relationship with most our partners was never one of peers. They were clearly the 800lb gorillas. However, by building individual relationships across firms we could navigate complex issues as colleagues. The truer that was, the better our collective outcomes with that partner.
You cannot approach your mega partner as an equal. Its your job to cast topics you care about in terms that matter to their business. At the same time, your organization must always prioritize its own resources and strategy based on whats best for you and your customers — even in the world of consumer tech and cloud computing. In fact, the pace of change today makes this legacy philosophy more in vogue than ever.
