11 Thoughts on Developing for Developers

Execution time:

Difficulty:

Cost:

We’ve recently come to realise that building products for developers isn’t a well-understood category. Enterprise and consumer sales are known quantities, but a precious few 'get' the developer market.

It could be seen as a way into enterprise through the back door, but you’re speaking to real people, who are looking to use your product to make their lives more enjoyable or less painful. And in that sense it resembles consumer products. Companies like Twillio, Heroku, and GitHub, have done this very well, and have reaped the benefits. On the other hand, some behemoths try to approach the market with the enterprise playbook and fail spectacularly.

Being in the process of making products for developers ourselves here at Resin.io, we researched successes and failures, and have boiled down 11 ideas about the developer market that we're going to battle with. No plan survives first contact with the enemy, so as time goes by we'll definitely learn and adapt, but this is where we are right now:

Be a developer. First and foremost, we haven't found any examples of successful entrepreneurs building tools for developers that can't code themselves. It looks like you really can't take the business school approach to this, and simply attack a gap in a market you're not part of. Coming up with (or even understanding) a product idea will be significantly harder, to say the least, if you can’t code.
Build a team of hackers you respect. Your first team members will develop your product with you. They’re not only producing the code that runs the system, they’re also domain experts, prospective users, and have lots of developer friends who respect their opinion. In addition, engineering and marketing are not separate functions in this kind of company. Marketing is mostly about telling the world what engineering is doing. Likewise, support is not something that can be done off a script. In short you’ll need technical talent absolutely everywhere.
Go to the bleeding edge. Find an up-and-coming ecosystem, and focus on it. For Resin.io, this is JavaScript. This has several benefits. For one, it helps with point number 2 above, as developers who try to stay on the cutting edge are more likely to be doing this for the love of the craft rather than for strictly defined work. Paul Graham has covered this point at length. Also, by working on the bleeding edge, you’ll find the problems that need to be solved. And therein lies your source of business ideas. Measure the pain, consider the opportunity, estimate the difficulty, and you may have a winner. Notice that this implies that you may not start building a product immediately but build your team up by solving more pedestrian problems for others. This has definitely worked well for us, but it does need you to be absolutely dead set on being a startup, not an agency, in the long run.
Give your users new superpowers. Twillio broke open the telephony world. GitHub made talking about code easy, even fun. Heroku allowed developers to command data centres from their bedrooms. Stripe made getting paid to stop being a headache fraught with risks. Find the next superpower to deliver to entrepreneurial hackers, and they will build multi-million dollar businesses around it.
Be frictionless. Once your users/developers get comfortable with your platform, you can only mess it up by making their life harder than it absolutely needs to be. Make your product as frictionless as you possibly can, and then some. Every proposed step to be added in a workflow needs to be brutally attacked with Occam’s Hatchet.
Be hackable. On the other hand, when your users do want to modify the way your product works in legitimate ways, make that frictionless too. Make APIs available, find ways to give deep hooks into your system, or make your system de-composable so users can put it together again in novel ways. You may be surprised by what you see done to/with your product. In other words, be generative.
Question what needs to remain closed. As opposed to the traditional enterprise thinking where closed is the name of the game and opening up anything is seen with great suspicion, developers understand the power of community. You will probably build your product on a codebase of 95% open source anyway. If you develop something that is not core to your business, why not open it up to the community, have it examined and even improved by others. Even without counting the heightened profile among your key hiring and client pool, developers, there is a strong case for opening up non-core components. And sometimes that can change your business completely. Just ask dotCloud – sorry, I meant Docker Inc.
Be transparent. It’s hard to overstate this. Developers have a notoriously low tolerance for bullshit, a long collective memory, and the ability to read through the lines for things that don’t add up. Play to your strengths and be open with your users. Being straightforward goes a long way towards mitigating product failures. The case study for this is probably Buffer, who had a breach but their phenomenal response means their users probably have more, rather than less trust in them now.
Examples, examples, documentation, examples. Here’s a totally unsupported assertion: most programmers learn not by theory, but by seeing and doing. Coding skills grow through experimentation and personal side-projects. When a user wants to use your platform and has to jump through hoops, fight through bad documentation, infer functionality that’s undocumented, or can’t see how everything falls together, they’ll quite likely move on to a different project or product. Make starting as easy as you can by providing ready access to working examples, up-to-date "getting started" guides, videos, and thorough documentation. But good documentation can’t be the only thing that's there. Excite your users about the possibilities your technology has by showing them real examples before asking them to invest their time.
Don't delegate support and public relations. We've so far established that you're a technical founder of a technical company serving sophisticated technical users. Leaving communication with your users to non-technical "experts" sounds like a recipe for disaster. Learning is the most important thing you could be doing early on in your company's lifecycle, and your early users will have the best lessons for you. Don't redirect them to /dev/null.
Don’t be afraid to charge real money. Last, but never least. If you choose to see developers as consumers, see them as highly sophisticated ones, who take total cost of ownership very seriously. It’s not unheard of to see threads on Hacker News where users of free products insist their makers start charging. While this may sound counterintuitive (or just plain crazy), it makes more sense after you go through the implosion of several beloved products for business model related reasons. As opposed to the naive consumer view of free stuff, developers want to build a relationship, and they know sustainable relationships go two ways. Being incredibly demanding users, they know making them happy in the long term isn’t free. As soon as you can, give people the opportunity to pay you. If they love your product, they will, and if they don’t, you need to know that.