I guess it is fairly obvious from my post yesterday, that I am pretty pissed off at Microsoft. I have always been one of those “Don’t point out a problem, without suggesting a solution” kind of guys, and I have done my share of pointing out problems with Microsoft’s Business Applications ISV efforts. So here are some ideas.
First, why should Microsoft even give a shit about ISVs? Certainly prior to sharing in ISV’s revenue there did not appear to be much reason, based on how Microsoft had historically engaged with ISVs. I guess we have to thank Salesforce and their successful AppExchange for Microsoft paying any attention at all. For years I have watched various Microsoft people get up and say “ISVs are critically important to us“, followed by very little in the way of tangible actions. Obviously, “We have a marketplace too!” should not be the end goal here.
What Salesforce keenly grasped, was that ISVs either generate business they would never have had, or make their platform for the customers they do have, extremely sticky. We know this from our collective efforts to get customers to move away from Salesforce; very often it is some ISV solution they depend on, that is making them stay put. It has gotten easier to be sure, but mostly because of Microsoft’s integrations to other Microsoft products being superior. SFDC customers are giving more weight to that now as so many of them have switched to Microsoft 365. On one side of the scale is this fully integrated Microsoft story, and on the other they have the disruption of losing a critical ISV solution for which Microsoft has no ISV comparable. What Microsoft really needs is 10X the number of ISVs they have today!
It all costs money
I don’t recall when Salesforce started AppExchange, but I don’t think it was long after they launched the company. I also don’t recall whether they took a cut of ISV’s revenue when they started, but they clearly do now. It would not have mattered, because at the time, they were essentially the only game in town. 800 lb Gorillas, with triple anyone else’s market share, can afford to be demanding of ISVs. I have no doubt that SFDC makes a huge amount of revenue from this motion, not only for licenses that they would not have sold otherwise, but also their ISV vig. I have no idea what they invest in their ISV ecosystem, but I am sure it is not small, because building and maintaining it is not cheap. But SFDC recognizes the value. Up until recently, Microsoft apparently invested the change found in the sofas around campus. I applaud James Phillips and Charles Lamanna for seeing they were not going to win the race with SFDC on Microsoft’s trajectory at the time, and pivoting into new ground. The “Citizen Application Platform” is an entirely different approach, but “Citizens” are not going to build robust mission critical applications on Dataflex. Microsoft needs customers on the big money, sticky stuff that ISVs have historically created for SFDC.
Cart before the Horse?
Guggs apparently realized there was no budget to create this thriving ISV ecosystem that Microsoft would be the primary beneficiary of, and decided ISVs should fund this. Let’s think about this for a minute. You have a historically dismal track record for ISVs, you publicly acknowledge that, and step one towards a fix is to ask ISVs for the money to fix it. I had suggested at the PAC meeting where the Revenue Sharing idea was first floated, that maybe they should “prove” success for ISVs first, but I guess they didn’t hear me. I am sure that Microsoft has had to spend some of their own money on this effort, as I doubt that the Revenue Sharing income is significant yet, but they need to spend a lot more. And they need to spend it fast and right, otherwise they should suspend the Revenue Sharing for a while until the value for ISVs is there.
I can see it!
When I throw my head back, and let the possibilities swirl around, I can see success for ISVs, and Microsoft. I know I have been a strong Microsoft advocate in the past, and call me a flip-flopper, but I could easily become one again. Even though SFDC does not have it perfect, I still envy their ISVs today. And, even though he is a egomaniacal as they come, Benioff still let ISVs shine, less concerned about brand positioning, than money rolling in the bank. So, what might I suggest to Toby?
Maybe they can’t see it. Maybe they don’t actually believe that ISVs are critical, or even necessary. Maybe they see us a necessary evil for certain edge case deals. Maybe they see an ISV ecosystem 10X the size it is today as a huge hassle. That would certainly explain things. Or maybe they don’t think any of that, and simply don’t know what to do to solve the problem. Launching a Revenue Sharing program at this stage, in spite of knowing full well that it was going to piss of the entire ISV ecosystem, does not appear to have been the best first step. If this is going to work, we have to all be smiling the whole way through. No pain, no gain, only works for the gym,
Equalize the effort
Right now, particularly in Co-Sell, my guess is that 5% of the ISVs are getting 95% of the attention from Microsoft. I understand that’s where the quick money is, but that is also short-sighted, scorecard-based thinking. The goal should not make the few large ISVs even larger, it should be to make all ISVs larger. If you want to recruit a lot of ISVs, they need to see that they won’t just be given the crumbs left over after the existing large ISVs have had their fill. Kind of like how many organizations and governments have a minority program, where a certain amount of projects must go to a certain population, Microsoft should come up with a similar program for small and start-up ISVs.
I am aware that Toby will not have much influence over what the product teams do, but it impacts ISVs in a big way. The last thing the product teams think about when they create new features is the ISV story… it’s more of an afterthought. As a result, many of these features or products are not what I call “ISV Ready” for various reasons. Every product team should have an ISV advocate, from the very first conversation about a new product or feature. I mean there’s like 6,000 people in the BAG organization now, surely we can task a few of them with watching out for ISVs.
One of the touchier subjects for ISVs is AppSource. If done right, AppSource could be a primary benefit to ISVs, and draw for new ISVs. I know AppExchange certainly is for SFDC. Unfortunately, AppSource for Bizapps ISVs has become little more than brochure-ware. Poorly built, hard to use, and not promoted nearly enough. I am also aware that AppSource is not “owned” by the Business Applications Group, they only own their own door to it, so again, Toby may have his hands somewhat tied. Supposedly, AppSource has been very effective for Azure, and some of the efforts have been toward trying to copy that success. But the Azure buyer is a completely different person than the BizApps ISV buyer, and AppSource is not giving that buyer what they need. What specifically might I do?
First, I would reverse the process. Right now when you enter AppSource, a significant amount of the page is dedicated to showing you a bunch of “Featured” solutions. The problem is, AppSource has no idea what I might be looking for. The odds that I am looking for a solution, that you happen to be “Featuring” are pretty slim. I’m not even sure how these apps got “Featured”. I would delete that whole section. The entire focus on the landing page should be helping me find what “I” am looking for. This is an area where Microsoft could actually do something better than AppExchange. Make this landing page into a “Process” that guides me easily to understand what I want and need first. Only then, show me a list of options, limited to that. Once I land on a solution that looks promising, give me the opportunity to book a time on the ISVs calendar for an in-person demo or conversation, not just a generic contact form. Circling back to the “ISV Ready” conversation, AppSource is not ISV Ready. Test Drive is clumsy and largely ineffective. Trials only really make sense for widgets, and there is no way to expire the trial unless the ISV builds that into it. The promised commerce component is nowhere in sight, and even if it was, the churn challenge will be similar for ISVs as it is for Microsoft when customers just try and deploy something on their own, again other than a widget. More important to ISVs than commerce, would be a universal licensing system that we can just plug into. Licensing schemes end up costing ISVs a lot to build and maintain, and customers end up with a different one for each solution they install. Lastly, drop the dime on promoting it. Stop being the marketplace that is down the street around two corners, and be right up on main street. I have more, but that’s a good start.
To offset the shock of the Revenue Sharing program there was a promise of benefits. Most of the benefits seem to be targeting new ISVs, and that’s fine, but when you look at the costs of an ISV, and particularly those that Microsoft is in the unique position to help offset, there are some obvious opportunities to create value. One of them is IUR. Historically Internal Use Rights have been a benefit of Competencies. But for an ISV, competencies are not nearly as important as they are for SIs. For a short time there was an ISV Competency, that again seemed to have been put together without talking to any ISVs. It was summarily cancelled without any replacement plan. Either this should be reworked and brought back, or IUR should be a benefit of ISV Connect. It is not reasonable to expect ISVs to have to not only pay Microsoft for development platform, but then also ask for a share of the revenue earned as a result of the platform we had to pay Microsoft to use… Pick one! I am aware that IUR is not free to Microsoft, but I did say Microsoft needs to spend some money on this.
I think I will leave this here, for now. I am aware that I ruffled a few feathers with my last post, and may with this one also, but to be honest, the survival of my business depends on Microsoft getting this right. I see no upside in keeping quiet.