Software vendors always assure you that their "partner ecosystem" is doing just great.
But I judge the health of a vendor's so-called ecosystem by one key factor: the morale and success of their smallest partners. Why?
Because I believe smaller partners will:
- build the most creative solutions
- bring needed vertical expertise to bear, ideally through platform apps
- indicate just how accessible a vendor's platform is - or isn't
Up until this year, I've been disappointed with SAP on this front.
Yes, there are exceptional stories here and there, but for the most part, it's been an uphill battle for smaller partners. Despite the improvements made such as the SAP Partner Edge program, there were still too many disparate apps stores, and too little support from SAP sales on go-to-market for third party apps.
Changing the SAP partner story - Sodales Solutions speaks out
At this year's Sapphire Now in May, I finally saw a significant shift. In my review of event highlights for 2019, my talk with Sana Salam, founder and president of Sodales Solutions, stands out. Beating the odds is what Salam is all about. As she told me, it wasn't easy standing out from other startups:
All the other people who started with me, they were funded, they were like a group of six or eight founders, all guys. They looked a certain way, and had a lot of social connections, from playing golf or drinking. I don't drink; I don't play golf. I didn't know if we'd be able to survive - but we did.
Sodales Solutions did more than survive. I met Salam via a panel for Sapphire Now media facilitated by Amanda Mountain, Vice President Marketing Communications with SAP. Mountain has been an advocate for partner apps for years now, through her key role with SAP Digital.
The panel included other SAP team members and executives, as well as SAP partners Sodales Solutions, Mediafly and Ingentis. My only concern: the panel sounded almost too good to be true - after years of smaller SAP ISV partners telling me their struggles. I needed more context; Salam joined me for a sit down.
Salam's journey was sparked by necessity. As she finished up school in 2014, a non-compete from a prior role inspired her to start something totally new. Her company launched into app building. But SAP wasn't ready to fully support her at that time:
The first two apps we built got a lot of recognition from Microsoft and Google, not so much from SAP though. It's also because there was not a lot of change management done on the SAP employees' side; no one cared about the small vendors and their innovations.
Regardless, Sodales Solutions was off and running, learning hard lessons:
Our first app, Post to Close, was a month-end closing app, which would allow you to do actions on mobile. It was a full commercial failure. We could never sell it because there was no good market support at that time. For a small vendor it was a very difficult time to survive.
Salam got one thing right from the get-go: her apps weren't dreamy, next-gen placeholders. They were all based on customer pain points, documented from her project work. Her challenge wasn't just market recognition. The platform itself was a challenge:
The platforms SAP was promoting at the time, such as the SAP Mobile Platform, were heavy, so even if someone would implement my product, they would still spend so much in consulting dollars that there would be no motivation for an agile innovation.
Rebooting the startup - "I saw SAP's entire design thinking process"
So what's an upstart to do? Seek advice. At an SAP event, Salam was advised to volunteer at SAP Labs. So she started taking the bus from her home base in Toronto to Buffalo, where she would fly to SAP Labs. That gave her a firsthand look at the SAP Cloud Platform, as it was being built. And: she confirmed the customer demand for apps was real.
I saw the entire design thinking process. I saw the product development process. I met costumers who had these small little gaps in their core products that they wanted to fulfill, and I saw, "Oh, this is a great market opportunity. Customers actually are trying to build things."
At SAP Labs, Salam met an SAP salesperson who invited her to build app demos for an upcoming road show. From there, she met a customer with a unique need:
I met a customer who said. "There is a big industry gap. If you're into the apps business, why don't you build something?" And that's how I got my first app idea that became a product.
That app is now Sodales Solutions' Labor Relations Software, built on the SAP Cloud Platform. LRS has become a full-fledged specialty suite, with 500,000 live users, and functionality that spans from grievance and appeals to union job bidding. And yes, it's an official SAP SuccessFactors extension.
Sales of SaaS suites can depend on functionality gaps filled by a platform app. Salam says this was true of an early customer:
They said that all of the legal teams in their state departments need software to better manage their unions: "It doesn't matter what cloud product we bring in; we will have zero adoption if we don't have a good product for the unions."
And why did Sodales choose SAP, given the prior challenges?
We chose the SAP Cloud Platform, not because it's a buzzword, because it has HANA in it. Because of the amount of data related to collective bargaining, we needed SAP HANA and big data technologies.
Building a SuccessFactors extension made sense: Salam determined the best way to reach legal teams that need labor relations software is via the HR line of business. With a strong customer reference, the market opened up. That customer called their SAP sales rep, and told them:
"By the way, we just bought a product from one of your partners, and it fulfills a big need." That got the sales team's attention, and the word got out.
Once salespeople realize that platform edge, you're on the way:
They soon found that in almost all of their public sector RFPs this was a gap, a gap that their competitors such as Oracle and Workday couldn't fulfill.
At this year's Sapphire Now panel, I heard about a much more cohesive apps store strategy, and a much better link with SAP's sales teams. Is that Salam's experience?
I would say the main difference between this team, and all the other teams that were there before, is personality types. They are open to working with people; they're willing to market them; they're willing to promote them; they're willing to go out and make things happen.
Enterprise apps are still usually a mix of online and direct sales; you need to be able to switch sales channels as the customer does. Salam says that's definitely the case for their solutions, where traditional government procurement processes must still be navigated. The goal: use online wherever it can be used, such as for app provisioning.
But the biggest breakthrough was SAP changing their sales team's compensation to account for partner apps:
SAP's sales teams are now so motivated, because as of last year, they aligned the compensation, which wasn't aligned before.
Hard-won tips for SAP app building success
Salam made a strong case for how SAP has changed, but she didn't let partners off the hook either. Ultimately, your success falls on you. She offers these tips for enterprise apps success:
- Not every app will be successful, and IT will always validate it - anticipate the hardcore security and compliance needs of enterprise IT shops. Even though the business is buying the app, IT will validate. Build apps using tools that the IT teams will know and trust.
- Build robust apps that customers can't easily build themselves - not three-click functions. As you gain traction, add new modules.
- Tech can be copied by others - but business content makes your app unique. Tech companies with deep pockets can (and will) match your tech. "The partners who were successful are the ones who embedded business content by industry in it."
- Hire someone to sell your app that knows the business. "If I'm selling to a plant manager, I literally need to hire a plant manager to sell my app. If I'm selling to a lawyer, I need to hire a person with a legal background to sell my app." The customer wants to hear industry language, not SAP tech language.
- Respond quickly to all prospects, even if they don't buy online. They might be in the middle of an RFP and suddenly hear about your app. You won't have long to get a demo in front of them.
- Figure out the size of the idea, and the potential for growth. Some apps are too niche and can't be expanded to new industries or use cases. Example: LRS has expanded to new modules and new markets - expanding the functionality into health and safety.
- Use your best people to build your app - not just someone on the bench. App design shouldn't be relegated to a "we should build an app too" backup resource.
Salam knows she can't stop here. She's made it to this point entirely bootstrapped - no outside funding - and you must press your market advantage while you can. In some cases, Sodales is selling to S/4HANA customers who don't run SuccessFactors at all. Meanwhile, one of SAP's tier one consulting partners is now implementing LRS at a government agency in Australia.
It takes more than one panel to win me over, but for the first time, I saw real momentum on the SAP partner apps side - not just a standout story or two. But speaking of exceptional stories, next year, it's time for SAP to get partners like Sodales Solutions on the Sapphire Now keynote stage. Come to think of it, SuccessConnect 2019 would be a good start - so would SAP TechEd. Now that you have these types of partner use cases, why not lead with them?
Updated, 7am UK time with additional resource links and a few tweaks for readability.