We’re all product managers… but what are we building?

Product Management for software engineers (part one)

Photo by Alexander Andrews on Unsplash

I will admit to have dabbled in product — I even quite enjoy it. The more senior I became as an engineer and then engineering manager the more it mattered that I knew (and had a voice) in what we were building. I also realised along the way that good product managers are a rarity. A good product manager is the catalyst that makes teams great. An ok product manager gets things done and, depending on how well they work with the team, keeps everyone pointed in the same direction. A poor product manager is an anchor dragging the team’s productivity into the depths. I’ve also spent a fair amount of time debugging the relationships between product managers and engineering teams because this is one of the most common dysfunctions I have come across.

By the end of this article I’ll give you a simple framework that can give anyone within the team the head start to understand what you’re building. And also a valuable tool for understanding whether people are aligned with each other. If you’re coming into a new team and want to understand why people are pulling in different directions it can help you get going.

So, product friends, look away now. The rough proportions of good, ok and poor is probably 5%, 25% and 70%. The reason for that is that nobody really knows what a product manager is. One of the most common questions I’ve been asked in my career is “what’s the role of a product manager?” because it can vary wildly from person to person and team to team. I’ve seen product managers so technical that engineers and data scientists come to them to learn. I’ve also seen product managers who believe they are the custodians of all decisions in the team. One even described their role as being the “officer class” of the team (I wish this was a joke).

One thing that’s true in every team is you to be able to do a number of things:

1. Clearly articulate what problem you are trying to solve. A former colleague at Google had what he called the one-slide test (or you may have heard of this as the elevator pitch). If you cannot crisply describe why you’re here in a short space of time or few words then it’s likely that you don’t really know yourself. (I once asked a room of engineering managers this question and watched them freeze up in horror at their inability to answer it — hint if you can’t answer this as a manager you’re going to have a bad time).
2. Understand the value of what you’re doing. If you cannot ascribe a value to work being done it’s impossible to prioritise. It’s also demotivating working on something because of a hunch. Teams don’t stick around long if they’re not bringing value.
3. Work with users or stakeholders to understand their needs. You’re building things for users to solve their problems. You also need to solve their problems in a way which brings value to your own company. This balancing act is at the heart of all good software engineering. You also need people to understand how to engage with the team. A product manager frequently fulfils this function alone which is another anti-pattern.
4. Communicate progress to your business. This includes sharing misses or when things have gone astray as well as progress towards goals.
5. Decide on the relative priority of tasks. Now this is where things tend to go wrong. There’s a balancing act between code health and infrastructure and product features. If you only build product features then you are likely to be a factory for the creation of tech debt. This is great for the product manager and their career but un-great for the team. Likewise if you’re only doing cool technical things without solving user problems then there’s also a problem. Understanding how to resolve disagreements (because you will have them) is how you maintain forward progress and harmony. If you don’t agree how you’re going to do this then, again, you’re going to have a bad time.
6. Understand what other features are being built around your company. A company of any moderate size will be working of lots of things at once. You want a joined up product rather than falling victim to Conway’s Law and shipping your org chart.

Now we have a simplistic view of the responsibilities let’s also talk about team resilience. If these responsibilities sit entirely with one person then what happens when that person goes on holiday, gets sick or moves team? At the very least you need to have a number of people able to represent this role. It enables the product manager to scale and think further into the future. It provides redundancy and, most importantly, it gets engineers thinking about the product they are trying to build. To empathise with users and to understand how decisions are made about what the team is working on. It also results in engineers speaking the same language as product which means they are better able to say what they need from each other.

I’ll also say — the very best engineers have a good appreciation of product. They are able to relate what they’re building to the technology they are building it on and make the trade offs required. If you want to progress your career as a software engineer you need to start learning complementary crafts. Product is one of these.

Which leads me to my simple (and some might say childlike framework). It consists of three questions you ask to everyone in the team and also their stakeholders. By comparing the answers to these questions you can quickly get an appreciation of:

• Whether people are aligned on what they’re working on
• Whether people know the value of what they’re doing (and are therefore able to prioritise work)
• Whether people know who they are building for
• Whether people know who they are (or should be) working with

I ask these three questions whenever I join a new team or organisation. The answers have always been illuminating (and it’s been a cheap way of showing I’m bringing some form of value without treading on anyone’s toes). Not to mention allowing me to know where there are likely to be fault-lines between people and teams.

With all that in mind. Here are the questions.

1. What problem(s) are you trying to solve? (and who for?)
   If people think they are solving different problems then they’ll be working towards their view of what needs to happen. They’ll be constantly surprised people are not aligned to this. If people don’t know who those problems matter to (either user or stakeholder) they will have no way to empathise with the problems/needs of those people. A rambling answer to this question is a strong indicator that someone doesn’t know the problem. I’ve seen 80 page strategy docs for a 3 month project.
2. How will you know you’ve succeeded? (how do you measure success?)
   If you don’t have objective measures to determine success (or progress) then decision making comes down to opinion. Which is an invitation to all manner of unhealthy behaviour including decision making by job title. Even if people can’t agree on how to solve the problems, understanding outcomes means people are empowered to think creatively towards these and have a mechanism for demonstrating they have solved them. If you’re basing the success of your product or feature on something you have no way of measuring then you’re going to have a bad time. Either change the measure or invest the time in measuring properly — with the caveat that counting things is always harder than you think it’s going to be. This is not an excuse to go and beat up data scientists (appreciate their craft too).
3. Who do you need to work with to solve this problem?
   If you don’t know you’re running the risk of being surprised when your feature is mutually exclusive to another team’s (cue internal politics). More importantly there may be someone out there who can accelerate what you’re trying to build. Teams which only look inwards miss both of these things.

And, that’s it. Ask yourself these three questions. Ask the people around you these three questions. Now you have a sense of whether you’re working on the right things or even together towards common goals. Also, congratulations — you’re now a product manager (maybe not a good or even ok one yet but you’re on your way). Because, if we want to build great products we all need to think like a product manager.