Today, everything revolves around software, especially in financial services, the industry in which Galileo participates. We don’t create an actual physical product. We enable fintechs and other businesses to move money using our APIs, which are our product. For Galileo, developers are important stakeholders—not only because they influence their companies’ decision to partner with Galileo—but because of their essential role in working with our APIs to build their own products. So, for us, creating a premium experience for our clients’ developers is essential After examining a number of companies (including Galileo) and the developer experiences they’ve created, I’ve concluded that the following fundamentals are the building blocks required for a premier developer experience:

1. Developer advocacy. Without an internal advocate, the developer perspective can be easily voided by others with louder and more authoritative voices: for example, the CFO may advocate for the least costly approach, the CTO for the most engineering-friendly approach and the CSO for the approach that is most impenetrable and least transparent. While their concerns must be incorporated into decision-making, their department-specific concerns can’t be allowed to override the need for developer-first products that are transparent and enable users to start fast and experience how a product works before fully committing.The developer advocate role doesn’t need to be a full-time position—although in some companies it is. And it doesn’t require any special title. What’s critical is for the person who fills this role to understand your developers’ agenda and to be qualified to explain and defend that agenda with facts and authority.

2. Consistency and reliability. Consistency means that the product you’re creating is uniform and predictable. If you know how to use one piece of the product, you know how to use the whole thing. Reliability means the product does what it’s expected to do every time. If your product isn’t consistent and reliable, it doesn’t matter if it has incredible documentation, a dozen client libraries or a fancy command line interface, your developers will be dissatisfied.

3. Feedback. To ensure you’re building a product that developers will want to use, you want them involved during every stage of the product development process. To achieve this level of all-stage involvement, you need to seek out constructive criticism, ask hard questions and accept critical feedback.Hackathons are a fun way to encourage and engage your developer community. Hackathons have helped us learn how developers are using the APIs we’ve created. And, you can be sure, hackathon participants will challenge you with questions you never imaged you’d be asked.

4. Communication. Developers need documentation—and the simpler, the better. So, you’d better put advance thinking into your documentation and iterate, iterate, iterate to continually make it better. And they want forums where they can get answers for the more nuanced questions that you haven’t included in your documentation.We’ve found it make sense to embed a forum into your own documentation or support page. A developer’s nightmare is a site that doesn’t give them what they’re looking for and makes them “request a demo” before they can get an answer. My advice is to meet developers where they are and remove as many communication barriers as possible.

These four fundamentals should be the beginning of any company’s journey to building a developer-first product. With these fundamentals under your belt, there’s no limit to what you can achieve or where you can take your organization. If there are any fundamentals that I’ve missed here, please let me know! I look forward to your feedback.