We harp on POS companies who suffer under the delusion that they’ll build everything themselves. Despite all the evidence we point to – and even recent stories of behemoths like Apple recognizing that they must relax their walled gardens to keep pace with innovation – too many POS companies see something shiny and believe it’s in their best interest to build it in-house. We’ve even outlaid the crap math they use to arrive at these horrible decisions.
When it comes to APIs, however, POS companies must own this piping. Before we explain why, we’ll first reiterate our stance on the build, buy, or partner conundrum.
Certain product areas are core to POS. These are things that should be built in-house. Imagine features like tax compliance, check splitting, tipping, employee and customer work flows – you get the idea. As the underlying technology changes, POS companies must stay on top of those dynamics and invest to keep their core POS relevant. Attention paid to non-core items – like analytics, marketing, or something similarly far afield – results in the NCR Outcome, a term we’re using to describe the case where the POS company lost its focus and became totally irrelevant in the market. A good rule of thumb on determining what you should build is the 3-month rule: can you build and ship the product in 3 months, and do you have confidence it would be independently competitive? That is, if you didn’t force your merchants to use this tool through a walled garden, could it compete in an open market? Considering most POS companies couldn’t even schedule the first meeting to talk about said product – let alone research competitors – within 3 months, it’s a probably non-starter.
The buying options should be used sparingly unless the POS company has absolute conviction in its ability to keep the acquired product (and team) totally separate. It’s fair to assume that the POS company is making an acquisition to increase their product breadth. This shouldn’t come as a surprise, but what made that product successful was the fact that it didn’t need to focus on POS in addition to its core features. So what made a loyalty company compelling to merchants was the simple truth that it was not the shitty loyalty product offered by the POS company. As soon as you buy that independent loyalty company you risk strangling the innovation and focus that company had. If you’re convinced you can keep the acquisition separate enough that the team is still motivated to build a best-in-class product, then go for it. But remember that upwards of 80% of all M&A fails to deliver expected results due to cultural issues.
Partnering is the best option to extend functionality but requires egos be put aside. If you’re a large company courting a smaller one, this is going to be very difficult. As market success has been increasingly driven by the speed of innovation, larger companies – despite their relatively copious resources – are finding themselves underhanded. Partners with a singular focus can execute innovation in their respective category much more quickly, and POS companies should leverage this as an opportunity. While we do have bias towards a partnership approach we’ve spent enough time studying POS to know that this option is the lesser of evils.
A hybrid approach that combines all three of these options is a labs approach, where the POS company seeds an idea, develops it externally, and even collaborates with competitors to ensure this new feature or benefit is partially owned by POS participants. We’ve written about this model at length and it has become incredibly popular with larger companies looking to hedge their risk of replacement by a fringe innovator. As the Boston Consulting Group (BCG) has analyzed, the lifespan of public companies has shortened significantly in the face of exogenous innovation – see the graph below for a visualization.
Now that we’ve written our opinions for how POS companies should approach innovation outside of their core, let’s talk about APIs.
As the market evolves, merchants are realizing that there’s an entire universe of possibility out there and it doesn’t come with a Micros or NCR logo. Look at what Salesforce did for CRM, Intuit for accounting, and SAP for HR. None of these companies is a POS company.
Merchants have thus far been kept from this value by despotic POS rulers but the internet has democratized research and self-discovery. Now when a merchant hears about a tool that can increase sales or save money, they want to know how they can realize the same benefits for their business. The products a merchant is researching will most likely integrate or touch the POS in some capacity, which is why the POS needs to view the API as part of their core offering.
First, understanding what data these integrated products are extracting, what value they’re providing, and how your merchants are using them is imperative to your own survival. What if there’s a huge trend toward X: do you want to miss the opportunity because you had no visibility into the adoption of X across your own platform? Had you known X was finding rapid adoption maybe you could have repositioned your sales material to take advantage of the trend.
Second, there’s no better resource to map and extract your fields than you. You built the databases and file structures and you should be the one that figures out how they’re shared or modified. If we can agree that POS is becoming a hub that extends functionality for merchants, isn’t it critical that you own the metering from your own hub?
Lastly, using a third party for API development/management adds additional expense and will make you uncompetitive in the long run. Think about it logically: if your merchants are paying 20%, 30%, or more for a dumb pipe, that’s money they’re not reinvesting in their business. Although we’re still in the early years we’d bet there’s data to support the correlation of higher APIs fees with higher rates of insolvency – just like merchants who pay more for commoditized payments processing go out of business faster. Are you willing to eat increased churn in your customer base because you were shortsighted on API development?
In closing, we believe APIs must now be considered part of a POS company’s core development needs. To ignore this obvious requirement is a massive strategic blunder.
