Strange but True: Counterintiutive Paths to Building a Business on APIs
•Download as PPTX, PDF•
0 likes•368 views
This document provides unconventional advice on building a business using APIs. It suggests: 1) Don't build a business on APIs; 2) Don't be creative with your API and services; 3) Treat customers like children by keeping things simple; 4) Focus on doing fewer things well rather than many things poorly; 5) Prioritize documentation that few people read but is important for proper use; 6) Pay attention to small details and issues before they become big problems. The overall message is that developing an API-based business requires as much consideration of human psychology and usability as technical implementation.
Recommended
More Related Content
Similar to Strange but True: Counterintiutive Paths to Building a Business on APIs
Similar to Strange but True: Counterintiutive Paths to Building a Business on APIs (20)
Recently uploaded
Recently uploaded (20)
Strange but True: Counterintiutive Paths to Building a Business on APIs
- 1. Strange but True Counterintuitive Paths to Building a Business on APIs Thomas Bouldin Software Engineer Parse+Facebook @inlined
- 2. TL;DR: Building a business on APIs requires as much psychology as technology
- 3. PHYSICAL SERVERS LOAD BALANCING DATABASE BINDINGS RESTful API ROUTING MIDDLEWARE APP SECURITY APP BUSINESS LOGIC NETWORKING CACHING DATA MODELS USER SESSIONS SOCIAL PUSH NOTIFICATIONS FILES UI BINDINGS Parse+Facebook
- 4. PHYSICAL SERVERS LOAD BALANCING DATABASE BINDINGS RESTful API ROUTING MIDDLEWARE APP SECURITY APP BUSINESS LOGIC NETWORKING CACHING DATA MODELS USER SESSIONS SOCIAL PUSH NOTIFICATIONS FILES UI BINDINGS YOUR APP Parse+Facebook
- 7. What did we learn? (A Cynic’s Guide to building a business on APIs)
- 8. How to build a business on APIs: 1. Don’t build a business on APIs 2. Don’t be Creative 3. Treat Customers like (Your) Children 4. Do Fewer Things 5. Focus on the Docs that Nobody Reads 6. Sweat the Small Stuff
- 9. 1. Don’t Build a Business on APIs
- 10. 1. Don’t Build a Business on APIs controller.parseClassName = PFUser.parseClassName; controller.textKey = @“username”; controller.imageKey = @“avatar”;
- 11. 2. Don’t be Creative “You’re so vain You probably think this song is about you” —Carly Simon
- 12. 2. Don’t be Creative str_repeat strcmp str_split strlen str_word_count strrev
- 13. 2. Don’t be Creative void object.save() Task<Void> object.saveInBackground() void object.saveInBackground(SaveCallback) void object.fetch() Task<T> object.fetchInBackground() void object.fetchInBackground(GetCallback<T>)
- 14. 3. Treat Customers like (Your) Children
- 15. 3. Treat Customers like (Your) Children
- 16. 4. Do Fewer Things “Deciding what not to do is just as important as deciding what to do.” —Steve Jobs
- 17. 4. Do Fewer Things
- 18. 4. Do Fewer Things
- 19. 4. Do Fewer Things
- 20. 4. Do Fewer Things
- 21. 5. Focus on the docs that nobody reads “If you don’t know where you’re going, any road will get you there” —Lewis Carroll
- 22. 6. Sweat the Small Stuff “A stitch in time saves nine” —Unknown
- 23. How to build a business on APIs: 1. Don’t build a business on APIs 2. Don’t be Creative 3. Treat Customers like (Your) Children 4. Do Fewer Things 5. Focus on the Docs that Nobody Reads 6. Sweat the Small Stuff
Editor's Notes
- The first strange thing about this talk is probably the speaker. You may notice that I’m a Software Engineer. I’m not a founder. I’m not in sales or marketing, so I’m not in the type of role typically tasked with building an entire business. So why am I here in front of you today? Well, I’ve been around the block for a while and I think my view from the trenches has something to offer. I normally give talks which are a bit more focused on dry technical details of a platform, so this touchy feely stuffy is a bit new to me. Forgive me if I’m a bit gruff. I don’t intend to get all touchy feely without reason. I’m not some secret BA in fine arts trying to justify their way into a tech conference. Most of my career has been focused on building developer experiences. Before my time at Parse and Facebook, I also spent years working on Microsoft’s Windows Developer Platform. Windows is an institution; it’s lasted longer than many of our best practices. The never-ending process of modernizing a developer platform is tricky business, and when you have keeping a millions of users and billions in revenue, you adjust that business very carefully. I always wondered, however, what it would be like to start from scratch. What we could do were we to disrupt an industry rather than cultivate it? In 2012 I seized this chance and joined a little known startup called Parse.
- I’m not going to hold you in suspense; in case you’re waiting for some debate about the best stack to run a business on, that’s not what I’m here for. I couldn’t give a crap about what technology you use if you’re not using it to best serve your customers. Building business on APIs requires as much psychology as technology; the key trick is empathy.
- Parse’s idea was simple and compelling: Rather than spinning up servers, managing databases, building auth layers, planning scaling and failover scenarios, and writing networking code, we provide and SDK for a turnkey backend ready to host your apps. We replace complex infrastructure with APIs. Look at the world we lived in a few years ago: if you wanted to build a cloud connected app, you had so much foundation to build before even starting. You provisioned servers; planned a network topology; managed databases; built your own security layer; networking API; caching; mapped it to data models; and had to build advanced features like push notifications, file management, and UI bindings from scratch.
- All of this was before you could even get to your app; the thing that actually matters: engaging UI, useful functionality, unique content. These are the things that make you stand out amongst the sea of apps out there, and so it’s the thing you should be focused on; where all your time should go. Nobody is going to recommend your app based on how your data model spans Objective-C, Java, and C#, so Parse had a great idea.
- Focus on the part that matters (ingenious, right?). We give you the building blocks you need to build great cross-platform apps that delight people without reinventing the wheel. We had a great opportunity to revolutionize the way people build apps. Our core cultural value is customer empathy. We focus on a creating a terse and comprehensible SDK that’s intuitive, well documented, and well targeted to our audience. These values have paid off. In 2013, Parse joined Facebook as part of the Facebook Developer Platform. With Parse’s empathy and Facebook’s reach, the platform has caught fire. We now provide the backend for some of the top brands like Samsung, Groupon, VEVO, mobigame, Sesame Street, and the White House. Over 500,000 apps have been built on Parse and we serve billions of API requests each month.
- We provide this service across all the major platforms. Parse is available on Mobile (iOS, Android, Windows Phone), Desktop (Windows, and OS X), and Web as both Front End and Back End technologies. We also document the REST protocol with which you can talk to our backend, which enables developers to support Parse in languages and environments before we do. If you’re going Android to iOS, or vice versa. You might even be using a cross platform tool like Unity to build on iOS, Android, and Facebook Canvas—our games platform. This experience delivering a loved service across a wide variety of platforms has been an excellent learning opportunity. We’ve learned a lot about building a business on APIs.
- After three years and countless platforms, I’ve become a bit of a cynic. Sometimes people make mistakes that just feel so obvious in retrospect. So I’ve agreed to share our secret sauce, but I haven’t agreed to sugar coat it. So what did we learn?
- Not the cheeriest list, but one I’d advocate nonetheless. I think if you give me a chance to explain, they actually make sense.
- So rule #1 for building a business on APIs? Don’t. The API is never the product; the product is the service your API provides. A company which brags about its APIs is like a restaurant which brags about its oven: passion for your craft is a good thing, but it’s not the point. Consider the optometrist. Optometrists compete with each other for the latest styles of glasses, but this all comes after the assumed benefit of fixing your vision. VISION is the service an optometrist provides; the major breakthroughs in glasses get them out of the way. The best glasses are the ones which are most transparent (pun intended). Your API is not the product, it’s the medium. Learning an API has a real cost for your customers, so you should focus on reducing that cost. Your product is a service provided to a developer and their customers; remember to serve them. This isn’t an art, it’s the service industry.
- Let’s look at a way Parse tries to be transparent. Imagine you’re trying to table view in iOS which displays all your app’s users by username with an icon for their avatar next to the username. You need to map a User’s data to an entry in the table, download their icon, caching both user info and icons in memory and on disk, and implement drag to refresh. This is how you would do that with Parse. This code is terse and focused on the specialized task of mapping cloud based data to a UI. It handles all our complex requirements with three lines of code! The API is staying out of your way and letting you focus on the task at hand, not the technologies necessary to accomplish it. What about other great examples of APIs that just get out of the way and provide a service? Twilio makes it painless to interact with SMS or voice calls. Transcending “apps” and reaching feature phones is a magical experience, largely because using Twilio’s API wraps up their business of telephony infrastructure into something almost transparent. And Stripe: their business is handling money and monetary regulations. They don’t just talk to major credit providers, they handle all parts of your business necessary to avoid being subject to legal oversight like Sarbanes Oxley. You focus on growing your business and they handle regulations and security.
- Part of being a transparent service is understanding your place in your customer’s workflow. When you build a service focused on your product you think about your offering in a bubble. When you focus on your customer’s needs instead, you understand your place in their workflow. Remember, this is a service industry. It’s not about you; you don’t need to be a unique little snowflake. Customers will approach your software with a background steeped in all the other software they’re used to. If you feel familiar to that background, you will be easily adopted. Similarly, if your product is consistent, it will be more easily adopted. Be very strict about internal consistency within your product, including naming conventions, grammar, etc. Also be sure you fit in natively into the environment which your product serves. Fitting in naturally means you’ll include fewer (new) dependencies for your customer. You’ll also require less training to be incorporated in your solution. All of these lower the friction to your API (and your business) being adopted.
- When naming your APIs, err on the side of boring, not terse. Be internally consistent, even if this might conflict with your environment. In PHP, the authors chose to be consistent with C APIs where a counterpart existed but to be consistent with PHP conventions otherwise. The result is a confusing mess:
- The Parse API is internally consistent. It’s boring. It’s descriptive. You know exactly what what fetchInBackground is going got do. You learn very quickly that all methods have an InBackground equivalent you should prefer. All methods can either take a callback or return a task. This predictability means developers can intuit your tool; they spend less energy remembering your quirks and more energy getting stuff done. Some great examples of dull simplicity: JSON+REST+HTTPS. It’s secure, it’s predictable, and the industry loves it. It may not always make sense to follow industry dogma—even Parse isn’t fully RESTful—but if you’re going to break from the industry trends, try to at lear be consistent with yourself. It’s weird, for example, when a company uses JSON for their authentication service and XML for their other APIs. Dull design—aka “consistency”—has been a driving force in much of the cloud revolution. RESTful API were more easily developed by high-level tools like Ruby on Rails. They could be mapped more consistently to client code. Now that consistency is giving rise to meta-services and aggregators like IFTT and Mashape.
- Treat customers like your children. That doesn’t mean you should belittle them; who actually goes around belittling children?! Treat them the way you would treat your actual children: Invest in their success because their success is your success. It’s really important to reduce the number of ways your customers incentives and yours can be misaligned. At Parse we try to highlight customer case studies. We also try to be upfront about our limitations and use pricing to incentivize customers to design software we can better support (e.g. last year we transitioned from charging based on overall API usage to a much more gracious peak traffic model since this better reflected our true limitations) Anticipate their needs and provide an environment in which they can grow. Think about how the product feels for a beginner and focus on quick start guides. These guides should reach a checkpoint that validates the customer is successful early and often. For example, our quick start guides for data let you know when you’ve successfully registered an object. Our quick start guide for Push lets you send a push which will be received on any successful device.
- Consider the advanced developers. Pick a few types of sophisticated users and build optional complexity along their learning curve. Though your API should have opinionated defaults that keep things simple for the majority of users (esp. novices), it should be flexible enough for sophisticated users to extend. Sometimes this means open sourcing part of your product, but that can also be a sign of laziness. It makes sense in cases such as a UI library where the valid configurations are limitless, but other APIs can be just as powerful and much more approachable if designed to be flexible. Warn them if they are in danger of making a mistake, but don’t stifle creativity. The golden road is a support structure, not a prison. For example, it’s almost always a mistake to make a network call that blocks the UI. Parse will detect this, warn you, and even let you set a breakpoint to catch this behavior, but we don’t stop the developer. Maybe they just wanted to hack something together or it makes unit tests easier to build? Don’t lie to your children. Don’t make promises you can’t keep.
- Now that you’re being a parent, you’ll have less time on your hands. Do fewer things. Offer fewer features so that what is left tells a cohesive story. Understand your product at many technical level of detail: at the top level you should offer 1-5 things. Each of those things can have a small number of features with an approachable learning curve. While you should offer enough sophistication to satisfy the power-user, your product should be easy for the first-time user. At Parse we specifically consider what we call “wedge features”, things which must have no conceptual dependency on any other product because we want new customers to be able to use them as their first/only investment in Parse. These “wedge features” have synergy with other features but their basic use case must be fiercely guarded as isolated.
- If a company offers too many products, it’s hard to guide a new user. Looking at this product listing, I’m not even sure which technologies I’ll need to solve my problem or how they interact with each other.
- Parse however offers three unique pillars and customer knows where to look when they’re starting with Parse: Are they looking for a “cloud”, push notifications, or analytics? Each of these products is conceptually standalone, even if they leverage each other under the covers.
- Similar to narrowing your feature set, focusing on a narrower audience helps you provide better support. Consider a chef’s utility knife and a swiss army knife. Swiss army knives are fantastic utilitarian devices, but they appeal to a niche market for portable utility. You’ll rarely see a swiss army knife in a kitchen drawer; it belongs in a pocket. Similarly a chef’s knife is much more efficient for preparing food in a kitchen. You’ll rarely see a chef’s knife in a backpack; it belongs in a kitchen block. REI doesn’t carry a Swiss Army Chef’s Utility Knife because it doesn’t make sense to combine these two niche markets even though both tools accomplish the task of “cutting things.” Going back to Parse’s 3 pillars, how do we know we’re not making a Swiss Army Chef’s Utility Knife? Start with a core product and build sophistication to it. Strike out with a new wedge feature if it can be both useful as a standalone product and has a market advantage that only you can provide (due to your other wedge features). Parse Core provides basic data services without any other dependencies. Parse Push is conceptually distinct. And advanced users know how Parse Push is built on top of Parse Core so it can use the same level of sophistication in Parse Core to segment their audiences in Parse Push. Similarly, Analytics may seem completely disjoint from the other two, but when you add usage analytics for Parse core or A/B testing for Parse Push, suddenly Parse Core, Push, and Analytics are worth more than the sum of their parts.
- Even within a specific niche, varying levels of sophistication in your customers’ needs will require varying levels of complexity in your product. API designs, tutorials, etc. should focus on the simplest use case that will solve the majority of customer’s needs. The 80-20 rule (or Pareto principle) suggests that 80% of your customers will be satisfied with 20% of your grand vision. Release your first version when you think you’ve solved a good number of people’s problems, not when you think you’ve solved all of them. Take their feedback; see which of the remaining features are most important to potential customers. Remember that the API is the medium, not the product. Remember that an API has a cost. If you try to serve everyone, then everyone you serve incurs the cost of learning a more complex product. Branch out into new areas which have natural synergy with your existing product. Add complexity to your system in a way that is optional and keep it out of your quick start guides.
- With less time available to do fewer things, your first priority should obviously be the documentation that nobody is going to read anyway. Documenting software is like measuring lumber: it’s best done before the cut. You might want to do some finishing touches, but in the words of Lewis Carroll, “If you don’t know where you’re going, any road will get you there.” Build documentation for your feature before you implement it. I call this “Demo Driven Development”, which is an extension of “Test Driven Development.” Play with your potential product before its design is fixed and see how it feels; this lets you find design flaws early when they’re cheapest to correct. My rule of thumb when beta testing a potential API: a demo should reach its punchline in 3LOC or less. If you need to write too much boilerplate to set up the punchline, then your product may need to be more decisive and serve the 80% audience better with its defaults. As a contrasting rule, watch out for too much happening under the covers. “Magic” is a bad word in API design. The implementation of an API should be easily understood; this allows the sophisticated user to grow into advanced use cases because they intuit the way your API works and can extend it. Carefully planned documentation will also do a fantastic job at exposing conceptual dependencies in your product. How many concepts are necessary to create a push notification natively in Android? You need to understand the Android Manifest, GCM service, Intents (Pending Intents, broadcast Intents, and Intent security), the tradeoffs between Broadcast Receivers and Intent Services, Notifications, etc. And that’s just HANDLING the push, not registering or targeting. With Parse you can worry about those if you want (and there’s advanced tutorials on the subject) but your minimum requirement for handling push is to paste in a few lines in your manifest.
- Another benefit of Demo Driven Development is that it helps you avoid cutting corners. By putting qualitative work before quantitative, you ensure you can do a good job before running out of steam. This helps you spend less energy asking yourself whether you’re ready to release a product as it nears its target. This helps you avoid falling behind in technical debt. A hard to use API or poor documentation will leave you trapped in recurring customer support debt at best and out of business at worst. Spending time to learn your customers’ needs will help you build better products. This is why our Parse developers takes turns spending a week on-point to handle customer support across broad product areas. By helping out with customers support we feel their pain and it helps inspire or prioritize the features we build. We maximize our time to develop these features by keeping our technical and support debt manageable. We spend a day each month looking at ways to improve documentation outside of our product cycles. And each month we recognize the Parsers who have tackled the most technical debt and who have contributed the most to customer satisfaction.
- So to recap, here is my advice for building a business on APIs: Don’t build a business on APIs; build a business on a service. The API is the medium, not the product Don’t be creative, because it’s not about you. Fit naturally into your customers’ workflows Treat customers like your children. Invest in their success and design your product around a learning curve. Do fewer things so that your product can be mentally cohesive. When you create advanced features, put them in advanced guides. And remember you can’t help everyone. It’s better to give 100 customers a spectacular experience than 200 customers a shoddy one. Focus on the documentation, even if nobody reads it. By starting with your finished product, you’ll discover problems early and fix them cheaply. Your customers’ ability to learn your product is a core part of its value proposition, so focus on the learning curve early and often. Sweat the Small Stuff. Keep ahead of technical debt and customer education. The more you invest in a sustainable support system, the more time you will have to innovate. What’s the underlying theme to these rules? Empathy. Service. These aren’t secrets for building a business on APIs, they’re just good advice for building a business period. Remember, this isn’t an art; it’s the service industry and the customer comes first.