Indeed, developer platforms require a product approach. However, this should mean a commitment to understanding the context of the development work and how that context (both technical and organizational) will change and evolve over time. On a broader level, this requires sensitivity to the work of developers and the role they play within an organization: it is ultimately impossible to build an effective developer platform while maintaining the view that technical teams are little more than a resource that writes code creates and executes demand.
But what does sensitivity to the developers actually look like? What does it include?
At one level, you need to break all assumptions about what developers need or how they want to work. We have to start from scratch and understand the collaboration, tools, processes, skills and culture.
At Thoughtworks, we champion a technique we call path-to-production mapping. While this is a simple idea, with teams literally coming together and putting together all the steps needed to make a change and then push it into production, we rarely see customers do this, thereby exposing and not addressing developer pain points and inefficiencies will. For teams, too, it helps to ensure there is a shared understanding of how things get done. Ultimately, it forces everyone at multiple levels to figure out what developers are actually doing and what they need to accelerate time to value. This is a valuable foundation for any future platform development.
At another level, we also need to articulate and acknowledge the broader goals and drivers of the organization. In other words, where do development teams add value? And how can they add value More quickly?
This will vary greatly depending on the type of organization. Because of this, having a preconceived notion of what a platform should be (i.e. what features it should have) can be risky. It would be great to be able to list examples of exemplary developer platforms – Spotify’s Backstage is rightly lingered here a lot – but the problem is that there is no role model. A perfect developer platform in one context is an inflexible antipattern in another. Basically, a good platform implements guardrails that allow developers to focus on what they do best: writing and shipping code. It should reduce the team’s cognitive load, minimize the risk of errors, and maximize the time developers can spend on value-added work.
The needs of software developers and the commercial needs of an organization are best managed or mediated by a Product Owner. This is a role that is often overlooked. The product owner is not a business analyst nor a strict development role, but an essential person to ensure that developers are empowered and that they also deliver value to the entire organization.
However, it is important that capturing feature requirements is not viewed as the full extent of platform-as-a-product work. Attention to detail is important, but we need to pay attention to more than just the nuts and bolts of the platform: we need to ensure the value of those nuts and bolts can be realized. This is only possible with a coherent and sustainable internal marketing and communication strategy.