{"id":55514,"date":"2024-08-22T08:30:58","date_gmt":"2024-08-22T12:30:58","guid":{"rendered":"https:\/\/sdtimes.com\/?p=55514"},"modified":"2024-08-26T15:08:23","modified_gmt":"2024-08-26T19:08:23","slug":"prioritizing-your-developer-experience-roadmap","status":"publish","type":"post","link":"https:\/\/sdtimes.com\/softwaredev\/prioritizing-your-developer-experience-roadmap\/","title":{"rendered":"Prioritizing your developer experience roadmap"},"content":{"rendered":"

If there\u2019s one thing a platform engineering team doesn\u2019t lack, it\u2019s ideas. When your customers are your colleagues and friends, you have an ever-expanding wishlist to<\/span> improve developer experience<\/span><\/a> \u2014 you only have to ask!\u00a0<\/span><\/p>\n

But as with any product team, you have limited resources and the need to balance both business and engineering objectives. So many stakeholders inform your<\/span> developer experience roadmap<\/span><\/a> that it can be difficult to prioritize.<\/span><\/p>\n

Yes, you need a roadmap\u00a0<\/strong><\/h5>\n

The biggest thing that distinguishes platform engineering from the top-down platforms of tech days of yore? Nobody has to use it.\u00a0<\/span><\/p>\n

When you\u2019re building any<\/span> developer experience tooling<\/span><\/a> \u2014 whether it\u2019s an internal developer platform or portal or just a directory or better documentation \u2014 you have to build something that your engineers actually want to use. Your platform strategy \u2014 sometimes called a developer experience or DevEx strategy \u2014 should make developer lives so much easier that they need a really good reason to go off that golden path.\u00a0<\/span><\/p>\n

Platform engineering requires a Platform-as-a-Product mindset, packed with user-centric design, prototypes and demo days. Your colleagues become your customers.<\/span><\/p>\n

You not only need an internal product roadmap, you need to actively publish it within your organization. This way not only are you making commitments to solve your developer-customer\u2019s problems, you are closing that feedback loop, so your platform team knows early and often if you\u2019re building something that they even want or need.<\/span><\/p>\n

Know your stakeholders<\/strong><\/h5>\n

Perhaps even more than when you are working with external users, a platform team, as stewards of the developer experience, is beholden to many stakeholders.\u00a0<\/span><\/p>\n

As Sergiu Petean from Allianz Direct pointed out, a<\/span> common anti-pattern for platform teams<\/span><\/a> is only addressing the single stakeholder of the software engineer. The larger the enterprise, the more regulated your industry, the more stakeholders you have to consider from Day One.\u00a0<\/span><\/p>\n

At the insurance giant, his team initially highlighted eight different stakeholders that all bring different demands:<\/span><\/p>\n