Building Products and Experiences that Developers Love

Developers are users too. Most of my experience in Product Management has been with very technical products for a unique group of users known as Developers. My current role is with PubNub, where we offer a real-time Data Stream Network to app developers. We offer our customers all of the security, scalability, and performance on that network layer through simple APIs and SDKs. Clearly, we sell an engineering-centric product.

As with a lot of other products on the market, this company started by solving a problem that the founders had themselves. It was a data streaming network made by developers for other developers. But as companies like PubNub grow and scale, its end-users start demanding more than links to Github repos and word-of-mouth support.

This blog post encapsulates some lessons learned from my experience. For instance, today we grapple with the questions like ‘How do you convert the wary visitor to a user?’ and ‘What do developers want from you?’

1. Sell the Dream

The first step, as with any potential customer, is to sell the dream. I don’t mean in a smoke-and-mirrors Boiler Room kind of way, but by explaining what customers can accomplish with your product. As new users visit your website or learn about your product, they are in search of a solution to theirproblem. So focus on their desired outcome, not your own list of features. Remember, it’s not about you.

For dramatic flare, I’ll repeat that: It’s. Not. About. You.

“People don’t want to buy a quarter-inch drill. They want a quarter-inch hole.”
—Theodore Levitt

Buffer offers a great article that delves deeper into this topic. The simple yet essential central idea is that it is important to listen to your customers’ problems and understand their needs/wants. Solving real pain is always good for business.

This recommendation applies to the developer community as well. It is a smart group that may be able to build the solution you are offering, but it is also savvy enough to know how to evaluate the ROI for the build vs buy argument.

Here are some real-life examples which illustrate this idea. Stripe “enables businesses to accept and manage online payments”. Simple, direct, clear. Airbrake and Heroku also do a great job explaining their benefits to developers. To paraphrase both value statements, ‘we take care of this annoying thing you don’t care about so that you can focus on the thing you want to be doing’.

Of course, these companies don’t win by just having a snazzy, splash page. They gain traction because of their straightforward APIs, quick setups, clear documentation, accessible support options, among other factors. So let’s talk about which ones are most important next.

2. Anticipate the Questions

There is never enough time or bandwidth to do everything we want to do to build a great product. So you need to focus on the material that is really important to your customers. It might sound obvious but even if you aren’t a developer yourself, you need to be able to empathize with them. Know what is important to your end-users when they are considering and using your product.

Developers will definitely do some research when deciding whether or not they want to try you out. This is especially true if you are a core service because the cost of ripping out your solution later may be much worse than designing the right architecture now. So help them out! Answer the questions that developers or technical decision-makers will most likely be asking as they evaluate your product. For instance:

• Does this product work within my tech stack and how long will it take to integrate it?
• Is my favorite programming language well-supported?
• Is the reference documentation up-to-date? Has there been recent activity on the Github repos?
• Are there code samples and tutorials available?
• Are there recent technical blog posts covering topics of interest to me?
• What support channels are available and what is the response time? (Examples: email, chat, community forums, Stack Overflow posts, etc.)
• Has anyone else I know tried this out before? (This could include recommendations from peers or influencers in their social circles.)

Another important factor is general communication of the product. Everyone has experienced bugs and downtime in their own code before. So take ownership of issues, provide transparency with uptime status reports, and maybe even write postmortem blog posts to build loyalty and respect from your target audience.

3. Design with Purpose

As users dive into more details about your product, they will look to what enables them to do things better, faster, or cheaper with your solution. If it’s too cumbersome to get started, you’ve already lost them. So design your solution in a way that removes barriers to get them coding and building.

You want to ensure that your product design is easy to use and to understand so that they can start hacking. I’ll talk about visual elements towards design in my next post. Right now, though, I’d like to talk about API design for your developers.

Don’t build APIs just for the sake of having APIs. Take a product perspective to this effort. Understand why your API will be valuable to a developer. Why will they need this functionality? What specific problem or use case will it help them solve?

Of course, you may not envision all of the amazing uses or applications of your APIs right off the bat. But focusing on solving users’ pain points instead of fulfilling a bureaucratic industry specification will lead to better design in the long run. I’ve heard the term “REST-ish” to describe a more human-usable API. And that, in my opinion, should be the goal.

A friend once explained it to me like this: think of your API as a conversation with your users (developers). If you aren’t answering their question or only giving them half an answer which they need to use another API endpoint to get the full response, then that’s a weak API design. Even if it follows protocol to the letter, it becomes additional work for your users. Don’t put the onus on them to use your product.

Hopefully the recommendations above help move your interested visitors toward trying your product. Just remember, succinctly explain the value or benefit you provide, and anticipate and answer questions they will invariably have. This will help guide them along the journey that will ultimately end in their using your solution.