Throughout my career, I’ve worked on countless projects involving enterprise management software for IT jockeys across various lines of business.

Within this field of expertise, we’ve all encountered enterprise software at some point during our career.  The extremely practical, albeit boring  UI, the constructs of users, groups and roles, on premise installers and ilk of that sort.  Billions and billions of revenue made, hopefully with good margins and sleep-filled nights for support staff.

As the years moved along,  IT folks consolidated and controlled the experience for the developers.  Around 2007, however, two things occurred that altered the relationship between IT folks and developers that has effected the way we work together still today.

The first was the rise of the use of the web and smart phones to conduct commerce and business. Our economy became increasingly driven by these applications, or “apps” as even grandma began to refer to them.

The second was the rise of virtualization and cloud computing.  Developers were freed from the shackles of institutional processes and rules and were afforded limitless access to computing power with the rise of those trusty 16 digits to freedom (AKA corporate Amex card).  The impact this had in the short term is often overestimated, while the long term structural and secular effects on the psyche of the IT department often receives the opposite treatment.

Having been in the trenches with my colleagues, working on numerous software product management projects within in a variety of roles, I am often struck by how quickly the diverse array of roles played by developers is frequently overlooked. We tend to lump all developer roles into one simple “developer” persona.

We design and build user experience around the broad and amorphous requirements of the “developer”.   Treating the needs of the development community this way is just naive.  And then there is DevOps, the magical intersection of development and IT operations that’s transforming how all companies scope, design, build, test, deploy and operate software apps.

But before we get ahead of ourselves, let’s shift the focus back onto the job of product management and the art of building the right software product, at the right time, for the right persona.

It’s critical that we develop an understanding of a key nuance that goes into designing enterprise IT operations tools, products and platforms for the IT guys who use them, as well as for the developers and their needs in the IT-focused products.

The following statement I heard later in my career always resonated with me and sums up this point:

“We need to build products that serve the needs of the customer of our customer”

With a deeper understanding of the tools and processes in place, I want to provide readers with a bit of background on each role to really showcase the diverse nature of the roles a developer can play, the customer of the IT Operations team.  These roles are roughly the same independent of the type of application the developer is coding (traditional enterprise, mobile or cloud native) or whether the application will be delivered on premise behind a companies firewall, or software-as-a-service (SaaS).

Here area  few of the many faces of today’s developers:

Coder/developer – This person writes and tests code, doesn’t care where the application is tested for performance and scale, expects development and test systems to be provisioned and configured in minutes.  She wants complete control of her environments.

Middleware Platform– This is the team responsible for selection and support of database, app server and other platforms that the application relies upon, whether open source or commercial software.  This team can be in the business or it can be a core team in IT.  They are generally concerned about enterprise standards and reducing their costs to support the developers.

Application Architect – This individual is concerned with overall system architecture, the tiering of the application stack, performance, scaling and scale-out policies.

Application Operations – They care about how the application acts in production,  configuration and change management, response to peak loads and upgrades.  This team is responsible for address outages and restoration of service.

Line of Business – These are the business owners of the service the application supports. They care about customer satisfaction, costs and speed of patches, new release and functionality development and deployment.

DevOps – This is the newest group on the block. They possess a combination of skills and interests that span all the previous personas. They ultimately care about the velocity and throughput of features from concept to actual customer value and feedback in production.  This interesting read, The Phoenix Project, will give you a better understanding of the world of DevOps.

As you can see, in relation to the developer persona there are many different requirements from a variety of different constituencies. When you work in product management or engineering and you meet with users to design that next UI, process flow, or end-to-end use case, it would behoove you to look at your assumptions and design it from these different angles.  In most cases, what IT Operations requires may not be what the business developers want to experience.  Make sure your early customer feedback and Beta testing programs are populated by both IT and developer personas.