512kg / dima

Products for developers

Dima ·

1. Bet on open source

Experienced developers value open-source software because they know the limits of closed alternatives. They have had to debug opaque tools whose inner workings they could not inspect or, worse, have watched an open project change its licence or stop publishing its source code.

It has happened to widely used projects: in 2023 Terraform moved from the MPL 2.0 licence to the BSL, and in 2024 Redis dropped the BSD licence.

Developers who are just starting out benefit from open source too. They learn technical skills that transfer between companies, which helps their careers. Open projects also tend to have documentation that makes it easier to understand how the tools work and how to use them.

Technical transparency reduces vendor lock-in and makes software easier to debug, adapt and maintain.

2. Offer a free plan

Developers do not want to depend on a sales team to try a product. They want to get to it with as little friction as possible, check whether it is useful and decide for themselves whether it solves their needs.

Let people start for free and make it easy for them to expand their usage once they have validated the product.

There are exceptions, especially in enterprise software, where procurement can take months of negotiation, specific licences and a setup assisted by technical staff. Even in those cases, though, many developers would prefer a self-service way in.

The goal is to lower the barriers to entry: trying the product should be simpler than asking for permission to use it.

3. Invest in excellent documentation

The better the documentation, the more likely a developer is to try your product.

The point is not to pile up interface features, such as a dark theme or a search box behind a keyboard shortcut. What matters is how long it takes the user to find a solution to their problem.

One way to measure it is the time to the first result (time to first hello world): how long it takes from opening the documentation to successfully running a first call.

Good documentation does two jobs: it serves as a technical reference and it makes learning easier.

Educational content should be useful to beginners and experts alike. Experienced developers appreciate complex concepts being explained clearly, while beginners need to move forward step by step from the fundamentals.

Avoid introducing too many new concepts and acronyms without context. Explain each idea before building on it, as you would when teaching a technology to someone who is still learning.

Documentation is not an add-on to the product: it is part of the experience of using it and it determines how quickly a developer can start getting results.

4. Give direct access to other developers

When the documentation does not solve a problem, the user needs technical help.

At that point they expect to talk to someone who understands their situation and has the knowledge to help. The difference between effective and poor technical support usually shows quickly: one understands the problem and proposes a solution; the other adds intermediaries and makes the user repeat the same information.

Minimise the distance between the problem and the person who can solve it. Wherever possible, remove unnecessary layers of communication.

Fig. 1 — Distance between a problem and whoever can solve it. A schematic, not measured data. With n intermediaries, a question needs 2(n + 1) hand-offs to come back answered and the problem is explained n + 1 times. Both lanes assume every hand-off takes the same time. Gold is the question, blue the answer.

That is why roles such as Developer Advocates and Customer Success Engineers exist: they combine technical knowledge with the ability to help other developers.

Someone who builds software expects help from someone who understands how it works, not only from someone who knows the customer-service procedure.

5. Take part in existing communities

Developers exchange knowledge and experience in online communities and at in-person events.

This does not mean you should create your own community around your product. In many cases it is better to take part in the places where developers already gather.

Find out where they share knowledge, debate tools and look for solutions. Take part, answer questions and contribute useful information to the conversations.

The key is to understand that a community is not a conventional sales channel. Its relationship with companies is built on trust, participation and the value contributed.

Do not expect an immediate return. Results can take years to materialise, but steady contribution builds a relationship that, in hindsight, can prove to have considerable commercial value.

The strategy is to give value before expecting to receive it.

Sources

  1. HashiCorp (2023). HashiCorp adopts Business Source License.
  2. Redis (2024). Redis Adopts Dual Source-Available Licensing.