Usually the process of prioritizing a product roadmap is simple (in principle). You identify the problem with the highest impact, and you rank it higher than the ones with lower impact. (This is of course way harder and way more subjective in practice, but that’s a conversation for another time.) But when key functionality in your product relies on third party APIs, the calculus gets a little trickier. This has up enough times in my career that it seems appropriate to capture some of my thoughts about it.
Outsourcing our work
When I was working on improving the pick-up experience at Lyft, one of the major issues we were constantly facing was getting the right side of the street during pick-up and drop-off of passengers. You could imagine how this was especially an issue if we had passengers with limited mobility, or on a busy streets where pedestrian crossing is unsafe.
It wasn’t as simple as us making a few changes on the product. Lyft uses Google’s API to give our drivers routing information. And no matter what geolocation we fed into the directions API, the route returned would always give us the fastest way to the point on the street ignoring which side of the street the pin was dropped.
Could we solve it? Yea. We knew better than Google where passengers wanted to be picked up, and we could use that information to “force” the maps API to give us routes that would get the driver to the right side of the street.
But let’s pause there for a second. Does Google also want to solve this problem? Arguably, yes, they did. For one, we couldn’t be the only API customer who had the same issue. Second, we were one of the Maps API’s bigger customers and Google had non-trivial incentive to keep us happy to not consider either building our own solution, or going to a competitor.
Everyone wins?
It almost became irrelevant about who could solve the problem better, because a new risk had identified itself: If we built our system to take input from their API to inform our own route-making choices, we introduced a new vector for breaking changes.
Imagine if we built our own home-grown solution, and then Google introduced a higher quality alternative. Should we have built additional functionality on top of our own system (e.g. give riders the option to cross the street to save time on pickup), we now have legacy code that we no longer want to support.
We decided it was Google’s problem to solve. We ultimately worked with their client services to get it on their development roadmap and have it offered to us as a feature of their API. It was a decision that we made over and over again, and ultimately I think it was to the benefit to both Lyft and Google.
To us, it felt like we had two development teams, as long as we could identify feature sets that we needed that Google was also incentivized to build for us. Even if those features also benefitted potential competitors who were also leveraging Google’s API, it allowed us to focus our resources on features that were hard to compete against.
To Google… well, it made their Maps API that much more powerful and appealing to new, potential customers.
On the other hand…
Let’s talk about an example where the relationship is less rosy.
A few years earlier when I was working on our startup, Teleport, we found there was an unrealized market to help small businesses send cars to move their employees and clients from place to place. We had already built up the infrastructure using Uber’s API to dispatch cars on behalf of others, so it was a relatively trivial task to re-align our product to serve this new customer base.
I still take the view that as a small startup in our position, we took the the only reasonable play for us to make, but it’s as clear today as it was back then how precarious the position we put ourselves actually was.
The reason comes from asking the question: What was Uber incentivized to build?
We, at the time, didn’t have volume or leverage with Uber. And even if we did, we were in a very different situation as Lyft/Google, because we were offering services that Uber—should the market prove to be lucrative—would undoubtedly like to own rather than lease.
What incentives were in play?
We did exactly what Uber hoped the community would do when they released their developer API: we took the platform and found the opportunities they weren’t looking for. They provided only exactly the amount of access and controls that we needed, using us as their “test suite.”
Their ToS didn’t allow for this kind of behavior initially, and we worked with their lawyers to update it to make sure that it did.
Their infrastructure didn’t support one account sending many simultaneous rides until we identified it as a need (but not before we jerry-rigged together a hundred dummy user accounts to support it), and worked with their engineering team to make it possible.
It’s possible, even likely, was already an internal team at Uber already working on enterprise solutions, but I think it’s reasonable to assume that Teleport gave Uber a leg up. When they officially launched their official “replacement” for our product, the writing was on the wall. While they still offered barebones API access to allow us to continue, we could hardly compete and Teleport was shut down a year and a half later.
They’re businesses, too
None of this is new, but I think this is only going to get more and more common, as developer tools proliferate, and more and more businesses are bootstrapped off of the infrastructure of others.
We’re seeing this at an accelerating pace in fintech, as things that used to take months, or even years of development work are being reduced to a simple API call that can be integrated into your platform in the matter of weeks. Handle customer transactions and chargebacks? Move money between two accounts? Open a new checking account and issue a debit card? As long as you do your legwork, it’s done, done, and done.
Of course, the businesses offering these APIs are… well, businesses themselves, with their own strategies and playbooks. As you bring on new partners in your API decisions, it might help clarify some decisions to think about what has to be true about their business and what incentives they are carrying in their back pocket.
If you found this post interesting, maybe you’d also find what I’m working on interesting as well. I’m currently designing for a new financial product, called Northstar.
Northstar is the simplest way to automatically put your money in the best places, according to a custom financial plan. Our advisors tailor a plan to your life situation, and intelligent automation transfers the right amount of money each payday to pay off debt, save, pay bills, and invest. We’d love it if you’d like to come work with us to help make financial advising more accessible to all!