Leadership, Technology

Building a Developer Program (In Brief)

APIs. If you haven’t heard of them, then start reading. They will be the foundational fabric that binds the next generation of the web, and in many ways, they already are. Think about how many apps and website are connected to your favorite social network like Facebook or tools like Google Maps – those are powered by APIs.

For the past year, I have been working with our growing team at MasterCard to ensure we build awesome developer products and programs. This has been a great opportunity for a variety of reasons:

  • The identity of the company is rapidly evolving from a legacy financial services company to a cutting edge technology company. APIs are one way the company is doing that.
  • Employees and customers alike are excited about this. I am often approached excitedly at developer conferences and literally thanked for being there representing the company.
  • There is a tremendous amount of value that a company like MasterCard can provide, whether in be in the areas of payments, fraud and risk mitigation or data services, for example.

I thought I would share some recommendations from experiences I’ve had along the way:

Internal Education

If you’re working within a relatively large organization where many stakeholders are responsible for ensuring (and/or allowing) the growth of your group, then take the time to properly educate them on what you are trying to do and the importance of it in the context of the market. Once those primary stakeholders are excited about what you’re doing, that excitement will spread throughout the organization, and your efforts will be more easily accomplished and more rewarding.

Building the Right Products

At MasterCard, there is no shortage of API products that we could build. Like any individual or organization, however, there is limited capacity. Make sure you build products that prospective customers will actually use. Perhaps the best option is improving services you already have rather than creating new ones. In any case, you need to understand your own goals and plan appropriately.

Having a Capable Platform

Similar to building the right products, a platform capable of managing your API products is essential. US-focused products, for example, will require very different architectural support versus global products in terms of both content and usability. When building platforms, it is important to take a long-term and realistic view of your requirements. Your platform construction will also depend heavily on your product architecture. For example, if you are building a service that requires a server to make several calls to your API per use case it may make sense to test your own platform against a relatively high transaction per second (TPS) scenario – you don’t want unnecessary call failures because of the popularity of your product, after all.

Engaging Where It Matters

In my mind, there are primarily two different types of API customers who can be engaged: in typical sales / business development scenarios with larger companies, or within the general developer community. The former may very well be a continuation of existing processes. Just tell your sales people that they can sell products with similar or the same value propositions as existing ones but with significantly lower integration costs for customers and they will be all for it. The latter type of engagement is much more difficult, however, and could probably take up a post on its own. The best way to be successful is to be present in the developer community in a grassroots way. Attend meetups. Go to those demo days. Be recognizable. Be branded (not quite NASCAR-style, but not too far off, either). Build a community around you and the products you represent.

Support Can Be Tough

Supporting developers who are trying to or are currently using your API products can be extremely encumbering on both sides, but there are ways to make it easier and good things can come from this type of engagement. When it comes to in-person support, thorough understanding of the products and major languages is necessary. You can decrease the amount of support required by having awesome, humanized documentation. In-person support provides a great opportunity to help inform your development roadmap, as well. Digital support is best provided expeditiously. That means using Twitter, email, web chat, etc. Don’t forget about regional differences – while most software development occurs in English, there may be language barriers linked to (non-software) language.

Recruiting and Deploying the Right Talent

Everything about APIs is technical – the platform, the product, the documentation, and the customers. It is important, therefore, to have a team that knows or has the capacity to learn technical details. Everyone on the team doesn’t need to code, per say, but everyone must be able to communicate with each other clearly. You also want people on your team who want to be doing what they are doing and want to do it in the best possible way – as Steve Jobs said in 2005, “Stay hungry. Stay foolish.”

Measure

This goes for any type of product management, but it is very important to measure as much as possible. There has been a lot of material written about measuring success. I recommend watching this GV presentation on OKRs and reading up on the subject. Measuring correctly will allow you to quickly make course corrections as you build and scale your developer program.

What are your thoughts on building successful developer programs? Tweet at me with #dev, and let me know!

Standard
Community, Entrepreneurship, Leadership

Inverse(STEM) – What Happened to Well-Rounded?

For a few years now, some of the most notable technology executives have impressed upon today’s youth the importance of learning to code and the importance of STEM. Even President Obama jumped on the bandwagon in 2013. When I served on the board of the University of Connecticut, we worked with our Governor to launch a new operational and capital investment initiative by the state called NextGen Connecticut. The focus of this initiative, as you can read about, was additional STEM faculty, facilities and programs. STEM initiatives, in general, are good for the long-term health of our businesses and society as long as they are not created through or with the debilitation of other initiatives. It is that last part I’m a little worried about.

Dave McClure and the 500 Startups team, who are doing tremendous work globally in entrepreneurship communities, focus on finding great companies that have three key team ingredients, succinctly called “H2D”: a hacker (software developer), a hustler (sales/business development), and a designer (product architect/humanist). This team formula can create fantastic results, as we’ve seen from many of their portfolio companies. Yet STEM only focuses on one or two of these three legs, those being hacker and (maybe) designer. Not even discussing the broader needs of society, have we become to narrowly focused on STEM while forgetting other important fields?

Fortunately, I have been able to become somewhat fluent in particular programming languages, enough to have a certain level of conversation with software developers. As a kid, I went to a computer science camp and learned some game design (yes, I was/am a nerd, let’s move on). Later, I took courses on Codecademy and I continue to work with many of our product groups at MasterCard who were building APIs. I never have any intention of being a developer, but a certain level of fluency has been useful. My job at Apple was sales and marketing focused, so that box has certainly been checked. You could say I have filled in two parts of Dave’s formula so far, which just leaves some design experience. I’ve been able to take on some prototyping projects, but I am sure I will lean on resources like GA to help fill the gap.

So while the President, industry leaders, and many individuals are correct in suggesting that individuals learn to code (or more specifically, gain some level of fluency in coding as one might learn a spoken language in school), it is also important that our leaders recognize, even from an economic development persecutive, the importance of other skills and fields.

Thoughts on educational investment for the next generation? Tweet at me with #edu, and let me know!

Standard
Entrepreneurship

B2B v. B2C v. …..

In a recent conversation I was having with a NYC early-stage VC, the conversation turned to a topic I quite honestly hadn’t thought much about: “In the near future, do you think B2B or B2C will be bigger?” After giving my reply, he thought that my view of B2B was contradictory to the general viewpoint of the venture capital industry. Thinking back, however, perhaps what I had a greater difficulty with was the premise of the question itself.

Traditionally, we have seen a lot companies serving businesses (broadly defined) and consumers. Now, however, we have some terrific large and small companies serving developers, an entirely new customer of the 21st century. One customer that continues to be underserved is governments, especially “non-federal” ones. I call this group SMGs (small and medium governments). There is a real data service opportunity for this group, and only a handful of local, startup and nonprofit organizations currently serving it.

Remember, that’s just the customer base; now let’s think of the even larger issue of geography. Yes, the internet has made certain products, platforms and services available to a wider variety of populations, but that does not mean that a US solution is applicable to Brazil. Of course there will be corporate consolidation through M&A activity, but the solutions still remain relatively unique given equal scaling opportunities.

So if asked again, do I think B2B or B2C will be bigger in the near term, I think the answer will be: “Yes. They will both be big, as will B2D and B2G. Plenty of room in all four for growth.”

What industries do you think will be biggest in the startup world? Tweet at me with #nextgen, and let me know!

Standard