Category Archives: Platforms

Three Thoughts on the New PayPal Developer Site

1. The relaunch of is long overdue and a terrific improvement. PayPal has never had a developer web site worthy of its promise until today. Part of this has to do with how PayPal and its parent company eBay were organized: a dog’s breakfast of products and ancillary initiatives that suffered from a lack of coordination and were often in direct conflict with each other.

It’s clear that a lot of thought went into not only how the site is organized and presented, but how PayPal talks about its products. No longer must you know whether Website Payments Pro or PayPal Website Payments Standard happens to be the correct choice for you before you proceed; the choices are very clear and are arranged in a manner that reflects the user’s goals, not the platform provider’s branding strategy:



Starting from a business goal (“Try Our Shiny New Blortz 2.0!”) rather than a user goal (“Make Money By Accepting Payments!”) is one of the most common errors I see in any kind of product web site; it’s particularly common to see with developer portals, which often seem to be developed by retooled consumer marketers who are operating out of their depth when addressing a developer audience.

2. This site was not developed in isolation. The new site reflects holistic coordination between the product/marketing side of the business and the people who are in charge of engaging with developers (which, at many platform companies, are frequently two distinct sets of people who don’t always coordinate with each other very well).

Presenting information about developer products in this way will certainly sand down the rough edges with regard to getting new developers on board for PayPal, so I’d expect them to see a benefit from the new site fairly quickly.

The new site has a terrific information architecture and a clean look. There’s even a bit of Twitter DNA in there (they’re using the tremendous Twitter Bootstrap UI library).

3. Federated authentication is an interesting and useful addition. PayPal has adopted federated authentication for its developer site, which means you have a button on that logs you in using the same credentials you use on the main site. This has a minor immediate benefit for developers, since you no longer have to maintain two PayPal identities — one account where your money lives and another account to access your developer sandbox. But potentially more importantly, it means that PayPal could transform into an authentication provider of its own at some point. This would give any consumer with a PayPal account the ability to log into a web application using PayPal in the same way that we log in using Twitter, Facebook, or LinkedIn today:


The difference, of course, is that the security regime provided by PayPal would be much greater than other federated authentication providers. As a payment provider, PayPal must adhere to international laws regarding data privacy and security, which would seem to support a higher level of trust for the federated authentication scenario. I’d feel much better sharing my personal information with PayPal than, say, Facebook.

Jeffrey McManus has led developer initiatives for eBay and Yahoo! and has consulted on developer platforms for a number of startups, including Twitter and Twilio. He currently leads Platform Associates, a consultancy that helps online businesses develop and manage platform products, and CodeLesson, which provides instructor-led online training for software developers.

Tokbox: A Platform for Adding Live Video Chat to Your Web Site

This evening TokBox launched a new platform that enables Web developers to embed live video conferencing into their Web sites. This is an incredibly exciting product and I’m sure it’s something that a lot of sites are going to take advantage of.

TokBox provides all the challenging bits to make this happen; all a web developer has to do is write a little JavaScript and you’ve got live audio/video chat in the browser with up to 20 simultaneous live participants (more people than you’d probably want to be video-chatting with at once, really) and up to thousands of audience members.

The important thing is that this is a platform, not just a canned widget, so web developers have control over how the in-browser video conference looks and behaves. This essentially enables you to integrate video conferencing anywhere Flash works.

For CodeLesson, the benefits to live chat in the browser are obvious — we’ve been working on using the new TokBox platform to embed live video chat into our online courses as an option to enable instructors to have live office hours with students online. Our hope is to have a video office hours incorporated into CodeLesson early in the new year.

To learn more you can check out their main site or their developer blog, or if you’re a coder and you’re ready to play, get started here.

My consultancy, Platform Associates, has been advising Tokbox on their transition from a consumer site to a platform for the past few months.

Figure Out How To Talk To Developers

Some Twitter developers are worried, and even started a Twitter hashtag to discuss it, #unionoftwitterapps. But software developers who build on top of platforms have always experienced the same give and take, other developers say.

“There’s some misunderstanding around platforms,” Mr. Williams, also a Twitter founder, said in a recent interview before the storm blew through the blogosphere. “I’ve been trying to figure out how to talk to developers about this.”

Free advice for platform providers: Figure out how to talk to developers before you make your platform available.

via Evan Williams’s Message to Twitter Developers – Bits Blog –

Cities Starting to Collaborate on Open Data Initiatives

I’ve been keeping an eyeball on open data initiatives in local government for a while now, and as I’ve mentioned here we advised our consulting client BART on their open data initiative last year.

I just noticed that the upcoming San Francisco Open311 initiative is planning to coordinate its efforts with a similar initiative underway in Washington, D.C. with the ultimate goal of making their systems interoperable. This is outstanding news; it means that if a developer builds an application that targets a data set emitted by one government agency there’s a decent chance that application will work against any similar agency’s data.

After machine readability, interoperability is the final frontier for open data. It’s not enough to post meeting minutes online as PDFs (the format where data goes to die), and soon it won’t even be sufficient to post it in a machine-readable format; data needs to be structured consistently. If every municipality invents its own format, this movement will be stillborn.

Link: San Francisco and D.C. Set to Launch Open311 APIs

Yahoo Pulls Plug on Shopping API

I’ve been getting a few pings from folks regarding Yahoo’s plans to transition its Shopping property to a third party. My team at Yahoo launched the Shopping API in August 2005 (although I don’t work for Yahoo anymore so I can’t provide insider answers on what’s going on here).

Since the new partner service (PriceGrabber) apparently doesn’t have a public API, that essentially kills this API. Killing an API is a very big deal, not just because it kills applications — it kills your credibility as a platform provider. I’d be very reticent about adopting any technology integration provided by Yahoo until things settle down over there. That said, there would have been a potentially interesting opportunity for PriceGrabber to provide a compatible API and make the developer switchover fairly seamless. It’s anyone’s guess as to why they elected to not do that.

Ben Metcalfe has some “cautionary” words which I think describes Yahoo’s lack of developer/platform strategy pretty well. The company’s developer releases over the past few years have mostly fallen flat for a variety of reasons (lack of business value for third parties being foremost, I would say, although there’s also a very unfortunate lack of organizational focus and unclear articulation of product strategy and tactics at work here as well). It was not clear to me that enough of Yahoo’s execs valued third-party developers in 2006 when I left the company, but it’s quite clear that they value third-party developers and open integration even less today.

How Not To Describe Your Platform

Link: PayPal Taps the Developer Community to Build Next-Gen Payment Apps

We haven’t actually released new APIs; what we have done is that we announced a set of APIs on November 3rd, which was our adaptive suite. Adaptive suite APIs include adaptive payments and adaptive accounts. Then we also announced our authentications and permissions API. What we had done at Innovate was to make those APIs exclusive — adaptive account, authentications and permissions, exclusive to the attendees of the conference. We did a full-on release for those APIs on November 3rd when we announced the platform. But we’ve had an overwhelming response from the community where people where saying, “You’re limiting us from actually using these APIs. Is there any ability for us to get these early on rather than to wait until 2010?” Based on the feedback, based on what people were looking for, we decided to open it up to everyone now, instead of sometime in 2010.

This quote is from Naveed Anwar of PayPal. It’s supposed to shed some light on the new PalPal platform. But I feel like I’ve been following the reboot of the PayPal platform for a month and a half now, and I’m still not sure I understand just how it’s supposed to help me. Apparently there is some conference that I was supposed to have attended? And if there are no new APIs, what has changed? Adaptive suite? What is that?

It’s not really possible to get the information you’d want from their web site, which at the moment is dominated by information about a new developer contest. (Developer contests are problematic on their own, as I’ve written about here previously.)

I’m really concerned that PayPal, like Yahoo and others, is going to miss a huge opportunity here by failing to articulate its vision in a straightforward way. (On second thought, screw the vision. Maybe just focus on saying what your products and services do on your web page first.)

Technology Platform Content Strategies

A frequently-overlooked aspect of managing a platform technology product is creating a sensible content plan and executing on it effectively. This is not what you’d call a sexy topic: In a lot of ways, technical content is to a platform as horse manure is to a farm. Very few people get excited about working with it, but if you don’t bring yourself to do it, things won’t grow as fast.

Having produced content to support a variety of technology platforms for more than a decade, I’ve come up with a few very general strategies for how to approach this.

The first strategy is Identify and Develop Reference and Narrative Documentation. Reference documentation is the bare-metal documentation that anyone would need to use your platform. This is the absolute minimum you can do in terms of documentation and content — without it, nobody will be able to figure out what you’re doing. Narrative documentation is far less dense than reference documentation; a good example of the difference is the Java tutorial for exceptions versus the reference documentation for the Exception class. Typically, reference documentation is delivered by your engineering team; narrative documentation is provided by technical documentation specialists.

The second strategy is Build Content Out To the Last Mile. It’s not enough to run an automated documentation generator on your source code and upload it to a web server, or even to set up a wiki and declare victory. You have to create technical content that is going to speak to software developers where they live, and generally that means writing to some kind of programming language. The languages you target will differ depending on several factors, including the programmability model of your platform, the amount of resources you have to devote to content, and the expected number of developers using each language you want to address.

Some examples: Let’s say you’re Palm and you want lots of developers to adopt WebOS. You have something of a head start here because you’re leveraging a single, commonly-used language (Javascript) and other web-centric technologies that a lot of web developers use. But there’s still a Last Mile for you: you’ve got an SDK, a Javascript framework, and a bunch of paradigms that are unique to mobile development.

On the other hand, if you’re a web services platform or some sort of back-end product, your Last Mile strategy is a little more complicated because you’re not tied to any particular programming language. That means that your Last Mile is the all programming languages used by your current and prospective developers, multiplied by the different pieces of narrative content that addresses each of those languages. I like to arrange this in a grid, like this:

Language Getting Started Guide Authentication Tutorial SDK Others
Java Done TODO Done
PHP Done TODO Done
C/C++ Won’t Do Won’t Do Won’t Do
Python Won’t Do Won’t Do Won’t Do
Ruby Won’t Do Won’t Do Won’t Do
Others Won’t Do Won’t Do Won’t Do

Making this into a grid turns it into a handy two-dimensional task list. It also informs where you devote resources (and potentially how you hire people; when we realized that PHP was important at eBay in 2004, and we had exactly zero PHP content, I hired a PHP guy pronto).

There’s a lot here, but the good news is, you only have to fill in each cell in the grid once. To manage resources, you are also likely to draw a horizontal line somewhere on the grid; languages below that line don’t get direct support from you (although you can graciously accept support from the community for edge-case languages that you can’t or don’t want to support directly). But the number of languages that you choose to support should exceed one (this was a serious problem in Facebook’s platform content until very recently).

Also, as you add major new features to your platform, you will of course add new columns to the content grid so that you cover your new features in all the languages that matter.

All that said, it’s also possible (even common) for platform technology organizations to over-plan their content strategy. This isn’t quite the same as what software architects refer to as “analysis paralysis,” but it feels the same. When you hear things like “we want to make sure we specify exactly what content we’re planning on publishing before we create a system to manage it” or “we don’t want to publish anything until every piece of content is ready,” these are signs of an over-planned content strategy. Best in this situation to develop the content you have, get it out there as soon as possible any way you can, and iterate on it frequently in collaboration with the developers who are using your platform.

This process supports a few tenets of the Platform Manifesto: actively managing platforms, nurturing communities of users, and providing self-service access.

Facebook To Let Others Play In Its Stream

Link: Facebook To Let Others Play In Its Stream

If true, this could be huge. It looks like the premise is that third-party developers will be able to get access to Facebook data (including photos) through new APIs.

This could make Facebook much less of a walled garden and give them a more compelling competitive response to services like Twitter.

The iPhone is Not a Platform

A post on the NY Times’ “Bits” blog describes the trevails of a developer who went to the trouble to build an iPhone podcasting application only to have the application rejected because it duplicates functionality found in iTunes (which is to say, the developer’s product is competitive with Apple’s own software).

This violates our first rule of platforms (“A ‘proprietary platform’ isn’t a platform”). Put another way, if you have to ask permission to develop a piece of software on a platform, that platform isn’t open — it isn’t even a platform (it’s a walled garden or a collection of integration points). If you attempt to build a business on such a product, you run the risk that the company that owns the product can destroy your business at any time, for essentially any reason. You are, in essence, a sharecropper.

The amount of revenue that Apple will lose from a third-party podcasting application is zero. The number of developers who will think twice about developing for the iPhone because of these capricious policies is almost certainly more significant.

Update: It’ll be interesting to see if Apple relaxes their rules in response to today’s release of the Android Market, the open application store for the new Android phone.

Product Managers, Lawyers, and Google Chrome

Product managers have an interesting relationship with corporate attorneys. In my various product management jobs I had to deal with attorneys quite a bit, but this kind of interaction clearly doesn’t happen often enough, for reasons I can sort of understand (lawyers can be intimidating, they frequently say “no” in a overly authoritative way that evokes images of the apocalypse, and in a big company they sort of operate in their own little world).

In the consultancy I have to talk startups’ attorneys off the ledge quite a bit. I have two talks that I find myself giving over and over with lawyers: the Open Sourcing This Tool Does Not Invalidate Our Entire Business talk, and the You Don’t Get To Invent Your Own Open Source License talk.

So there can be a pretty big divide between what lawyers want and what product managers want. Their interests are slightly out of alignment (product managers want to deliver feature functionality to customers; lawyers want to insulate the business from legal risk), but that’s okay. But it does mean that these two roles need to figure out ways to communicate and negotiate to move the business forward.

Not too many people get excited at the prospect of a meeting with a lawyer, and lawyer-wrangling is not the kind of activity that product managers get much credit for. There were several developer products my team released at Yahoo! that would not have seen the light of day if my team hadn’t devoted a bunch of time to convincing the attorneys that it was in the company’s advantage to releasing them. We certainly didn’t devote the majority of the time that went into creating these products, but it’s a fact that if it weren’t for the time we put in with the lawyers, the products wouldn’t exist today as products (they’d be a set of firewalled APIs or internal tools).

So I was thinking about this dynamic this week following the release of the Google Chrome browser. The product used the standard Google licensing agreement, which gives Google a non-exclusive license to anything you submit to a Google service. Because they used the same license on the browser, people who didn’t read or understand the legalese came away with the impression that Google owns everything you do using the browser. And “non-exclusive” is key here (it means they can use your data — in a search index, for example — but they don’t “own” it). Still, it freaked some people out and for good reason — the one-size-fits-all nature of a license agreement that’s appropriate for a web site isn’t necessarily going to fit well for a browser product.

Google has since said that they’re going to look into the licensing and retroactively remove the clause from the license agreement, but in a lot of ways the damage is already done — the license kerfluffle culled some momentum from their launch and made them appear less than thoughtful. Getting this stuff right is the kind of thing that a good product manager does.