BizDev 2.0: "Much, much better this way!"
Caterina Fake's 2006 naming of "BizDev 2.0": an API-enabled approach to partnerships and its relevance today. - ¡APIcryphal! 04
This edition of "¡APIcryphal!" retells Caterina Fake's 2006 naming of "BizDev 2.0": an API-enabled approach to developing business partnerships.
Occasionally, moments emerge among the daily business-as-usual which change the course of entire industries. The API landscape is a space as molded by legend as any other. While their accuracy to actual events remains debated, these tales remain the cornerstones of hallway tracks and executive talking points. These are API's apocryphal stories - the ¡APIcryphal!
TL;DR:
BizDev 2.0 captured a significant shift in how companies could automate portions of their business development. The degree to which open APIs and self-service portals can disrupt traditional strategic relationships and market engagement remains in flux, however.
💰An Aside for Former Paying Subscribers...
You're receiving this email because - at one time or another - you paid for Net API Notes. Whether you are a current subscriber or a historical backer, you rock; never underestimate how encouraging a few bucks a month is to a bespoke operation like this. THANK YOU.
You might have heard that Substack, my previous newsletter platform, had a Nazi problem. As I described in an earlier note, I suspended all January subscriptions from Patreon and Substack backers while finding something less fascist-empowering.
In the future, Net API Notes will be Ghost powered. The format may look different. So will the subscriber structure. I've canceled all existing payments, refunded annual subscribers the remainder of their balance, and disconnected my Substack info from Stripe. I've also canceled the legacy Patreon support tiers. You should not receive additional charges from Substack or Patreon for Net API Notes.
Please enjoy a complimentary month of access to Net API Notes' paid subscriber exclusive, ¡APIcryphal!. In this series, I recount the (mostly) true lessons of API's past. After the complimentary month is up, I'd love your continued support to fund ambitious projects, things like buying licenses to research API generation with AI or paying to analyze API job listings. But if you choose not to become a paying subscriber after the free trial expires, I completely understand.
Thank you for the support, please excuse the moving boxes, and back to the original point of the email.
Observance
In an era where MMORPGs like World of Warcraft and EverQuest II were all the rage, Stewart Butterfield and Caterina Fake had partnered to create what they hoped would be the next playable sensation. However, their "Game Neverending" was struggling. Almost out of money, Butterfield proposed that they spin the game's photo-sharing tool into its own service. The success was almost immediate.
Butterfield and Fake launched Flickr, their photo-sharing tool, on February 10, 2004.
Flickr exploded in popularity, becoming an early poster child for the burgeoning "Web 2.0" and "Social Web" concepts. In March 2005, Flickr was acquired by Yahoo!, then still a popular and influential services provider and internet brand. With Yahoo!'s resources, Flickr grew significantly and introduced numerous features, including tagging photos, creating groups, and organizing images into albums.
Flickr's success invited suitors. Fake found herself inundated with requests: other companies hoping for an introduction, a chance to pitch their ideas, and possibly develop a partnership. On an archived post, Fake wrote about the challenge (my emphasis added):
'Several companies – probably more than a dozen – have approached us to provide printing services for Flickr users, and while we were unable to respond to most of them, given the number of similar requests and other things eating up our time, one company, QOOP, just went ahead and applied for a Commercial API key, which was approved almost immediately, and built a fully-fleshed out service. Then after the fact, business development on our side got in touch, worked out a deal – and the site was built and taking orders while their competitors were still waiting for us to return their emails. QOOP even patrols the discussions on the Flickr boards about their product, and responds and makes adjustments based on what they read there. Now that's customer service, and BizDev 2.0.'
Venture capitalist Fred Wilson further popularized the approach. For years afterward, BizDev 2.0 remained a justification for developing an API program. But what was it about utilizing an API - and the Flickr API specifically - that led to partnership success?
Interpretation
Working within a large organization can be difficult. Cross the semipermeable membrane we call a company, and things can become downright complicated. Business development (or BizDev) is the tasks and processes meant to develop and grow opportunities within and (more importantly for this case) between organizations. A massive part of these multi-organization affairs is the establishing and nurturing of strategic partnerships outside a company's walls. These partnerships could be with suppliers, distributors, or even competitors in some form of alliance.
Traditional BizDev necessitates extensive networking and outreach efforts to establish contact. This might mean attending industry conferences or participating in exciting, big-picture conversations.
BizDev could also be a tedious slog, particularly when practiced by individuals more comfortable developing technology than interpersonal relationships. In that same post introducing BizDev 2.0, Fake characterized traditional BizDev this way:
'Traditional business development meant spending a lot of money on dry cleaning, animating your powerpoint, drinking stale coffee in windowless conference rooms and scouring the thesaurus looking for synonyms for "synergy". Not to mention trying to get hopelessly overbooked people to return your email. And then after the deal was done, squabbling over who dealt with the customer service.'
Flickr's API, introduced shortly after their 2004 launch, provided several benefits for companies looking to work with the high-flying startup:
- It automated the technical integration details (things like applying for a key, getting access to data, etc.), allowing those partners to assess the technical feasibility with a relatively modest amount of upfront investment.
- Partners could try and iterate ideas until they found product-market fit themselves without subsequent legal or support haggling, naturally encouraging a more agile approach.
- Partners that did gain traction could enjoy increased support from the API provider, as their limited reserve of time, budget, and energy wasn't fragmented across every potential API user.
I need to note that using an API to facilitate BizDev 2.0 didn't end custom negotiation or relationship management. Things like white glove service or brand management still warranted meetings. However, for a host of "mashups", public-facing APIs unleashed a wave of creativity and development energy to address new use cases.
As summarized by Shaival Shah, writing about the popular APIs of the time:
"-here self-serve makes a whole lot of sense because the value of these services are well understood and it cuts out expensive teams of sales, business development, account/client management, professional services, etc."
Keys
As companies would learn, making any API available outside the company firewall wasn't enough. Flickr's API exhibited several vital characteristics that made it one of the most prominent examples of the BizDev 2.0 phenomenon. These characteristics included:
- Simplicity: While other data exchange methods required cumbersome SOAP integrations or bespoke RPC patterns, Flickr's API innovated simple access and control methods, offering a model for web services that many other companies would later emulate.
- Openness and Affordability: Flickr’s approach to its API was seen as open and developer-friendly - providing essential features and functionality for free. This openness was a critical factor in attracting developers, as it allowed for substantial creativity and usage amounts before requiring payment.
- Accessibility and Relatability: Some APIs perform abstract, technical, or niche functions like cryptography and validation. The functionality provided through Flickr's API could be appreciated even by a non-technical audience, thus greatly expanding the potential integrations (and requiring a much lower degree of explanation). The benefits were immediately grokkable.
Through these principles, Flickr's API became the leading example of the BizDev 2.0 execution. The API created agile and efficient partnership formations, harnessed external talents and innovations to extend a platform's capabilities, and encouraged a vibrant community of developers to experiment and create. Taken together, these keys reinforced Flickr’s market position.
Reversal
In revisiting the concept of BizDev 2.0 as outlined by Caterina Fake, it's crucial to understand that the shift didn't imply the elimination of interpersonal relationships but rather their transformation. The initial approach allowed for a broader engagement with external developers through a preliminary, self-service exploration of APIs. This freed resources to support the most promising partnerships better. However, this subtlety often got overshadowed as BizDev 2.0 became synonymous with a hands-off, self-service model between API providers and users.
Effective business development is more than just facilitating potential opportunities; it involves a strategic engagement with the market. For numerous companies, merely setting up a platform and passively waiting for impactful use cases to emerge proved to be a gamble fraught with uncertainty and risk.
Moreover, the industry began recognizing the value of selectivity in partnerships. This discernment was driven by a recurring pattern: innovative applications emerged, only to be stifled by the platform itself if they either threatened to bootstrap a competitor or became so valuable that the platform preferred to monetize the generated value themselves. Consequently, this led to a stagnation in innovation, where developers were either deterred by the lack of creative freedom or wary of investing in platforms where their efforts might be abruptly curtailed or appropriated.
This cautious approach led to a significant shift in the landscape of API programs. Initially welcoming, many platforms began to retract or severely limit the integrations permitted through their APIs. Notable instances of this trend include:
- Twitter's 2011 clampdown on third-party developers to maintain control over its feed and advertising revenue
- Netflix's 2014 ending of its open API program due to an imbalance between the costs of support and the return on investment
- LinkedIn's 2015 API access restrictions were aimed at protecting its core business.
By the mid-2010s, it became apparent that while BizDev 2.0 had remained the same, its applicability was narrower than initially imagined. Critics from the era argued that:
"Biz Dev Classic may be slower, but it affords much more protection and stability for your business."
The sentiment underlined a nuanced reconsideration of the balance between openness and strategic partnership management in the digital age.
Legacy
Caterina Fake resigned from Yahoo! on June 13, 2008 - the same day as her Flickr co-founder, Stewart Butterfield. She has since served on numerous boards, received honorary doctorates, and became an author and angel investor. Fake also hosted the podcast "Should This Exist?".
In the years since Fake christened the BizDev 2.0 approach, Flickr grappled with increasing competition from other photo-sharing services like Instagram. Meanwhile, Yahoo!, its parent company, was faced with its own struggles to remain relevant. The frequent pivots sapped focus, and Flickr suffered. In April 2018, Flickr was acquired by SmugMug, a photography platform company.
Public API programs with self-service onboarding - the kind that came to be associated with BizDev 2.0 - remain valuable when the API is the business. Modern examples include Stripe, Twilio, and AWS. In each of these cases, the “self-service” API is not only the go-to-market mechanism but the core product of each company.
However, these services (Stripe, Twilio, AWS) are exceptions, not the rule. For most public APIs offered by companies, the API often ends up being long-tail marketing. Unlocking meaningful revenue opportunities still requires the expertise of a traditional business development team.
Examples of BizDev 2.0, with its pioneering self-service onboarding for public API programs, continue to be found in today's most common API examples. Platforms like Stripe, Twilio, and AWS would not exist without their APIs and a refined onboarding experience. In these instances, the self-service API is both the product and the pathway to market, demonstrating the profound potential of BizDev 2.0 when aligned perfectly with the company's core offerings.
Yet, it's crucial to recognize that these offerings — Stripe, Twilio, AWS — represent the exception rather than the norm. More often than not, public APIs serve as long-tail marketing tools rather than direct revenue drivers. Unlocking significant business revenue, in these cases, still necessitates the nuanced, relationship-focused expertise that traditional business development teams bring.
BizDev 2.0 was an innovative utilization of newly available digital practices, circumventing much of the laborious processes of traditional relationship building and contract negotiation. However, its universal applicability remains more limited than initially anticipated. It could not displace the necessity of human insight and strategic judgment required to navigate complex business ecosystems.