I accidentally a product manager

Within the front end development community, there is a relentless focus on cutting edge technology and the technical expertise that goes along with it. But in truth this is only a part of the role of senior and lead front end devs. That’s the basic premise behind this mailing list - I want to help UI developers with the rest of their job beyond the purely technical.

Depending on circumstances, front end developers can easily find themselves taking on other roles and responsibilities in software development teams. For example, it’s easy enough to find that you’ve become a reluctant scrum master.

But it’s also common for developers to take on some testing, system administration, line management, design, user research, customer support or IT responsibilities, depending on circumstances what kind of work you’re drawn towards.

For me, accidental product management work has appeared on my responsibilities list time and again. In the dim and distant past, this was because product management wasn’t a distinct job role unto itself. It was (and still is for many) something that’s handled collectively by the team in some way (however effectively).

The clearest example of when I became a product manager by accident was when I made the case for building an internal-only REST API at a consumer product company. Doing this would allow us to move our product beyond the desktop-only web application we currently had to a more flexible suite of products across mobile, desktop and other platforms. As a reward for my vociferous lobbying, I was handed the job of leading the team to design and build the API.

At first, I imagined that the role would involve learning about RESTful API design and then applying those principles to our existing product, which I already knew well. Simple!

It turns out that it’s relatively easy to design the basic structure of a REST API, but another matter altogether to design a user-centred API to reflect an existing product, taking into account pragmatic concerns around rollout, adoption, performance, availability, scalability, monitoring, change management, security, and all the other concerns.

It wasn’t the simple matter of mapping existing data and manipulations of those data to a RESTful format that I had imagined.

REST APIs have end users, even if those users are internal to the company only. But our team did not have a dedicated product manager. They were mostly focused on direct consumer-facing functionality, and I wasn’t part of their team.

It took me far too long to realise that I was now a product manager. I still behaved like a lead developer, focusing on agile practices, system design and the details of RESTful hypermedia design.

I waited too long to talk to the APIs end users - mobile client developers, front end developers, testers, product operations, even select third party partners. This should have been the starting point.

It’s extremely common to see internal or ‘technical’ products missing explicit product management. But in lieu of it, that work is done in any case. The question is whether it is and can be done well.

We need to detect when we find ourselves in a situation like this, where we have taken on de facto product management responsibilities.

Ask yourself these questions:

• Who are your end users? Even if they are internal people, they are people.
• Who has responsibility for representing those users in the team? I someone explicitly assigned to this or does it fall to a team lead?
• Are users’ needs being constantly researched, tested and validated?
• Does the product have a clear reason for existing? Is that reason well understood by the whole team?
• Who is responsible for setting the overall direction of the product?
• Does the company even talk about this thing as a ‘product’? Or is it a ‘tool’, a ‘framework’, a ‘platform’, a ‘system’?

Some examples of products that we often forget are products:

• Design systems (this is probably the most common product a front end developer will end up leading)
• Product admin and operational systems
• Financial systems
• Content management systems
• Developer tools
• Code libraries
• Build systems
• Continuous integration and deployment pipelines

In most growing product companies I’ve come across, some or all of these receive scant product management attention. That’s problematic.

If you find yourself as a de facto product manager, get yourself a rapid product management education. You can start straight away by identifying and interviewing one end user today.

All the best,

– Jim