Product Management is My Co-Pilot

“Hey Siri, What do Product Managers do?”

I was only a couple of years into my career when I started managing software development teams, and I continue to do that to this day with only a short excursion into the world of Product Management. At the time I wasn’t looking to be a Product Manager, but someone showed up and thought I was the right guy to establish a Product Management department in their company. When I agreed to do it, it was less based on whether I thought I could and more based on whether it would be interesting, such is the hubris of youth. So off I went to be a Product Manager, I’d worked with Product Managers for years of course, but my main interest in their job up until that point was how they could help my engineering team be more productive and not so much all the other stuff they did. So I Googled “What do Product Managers do?”, I read a couple of books and set about creating an exciting new department. It may not be surprising to you that the Product Management team I created looked a lot like a department mainly focused on supporting the Engineering team. To be fair at the time that was the most pressing task for the company and whether the existing Engineering group knew or wanted it, it was what they needed, it was also why it made perfect sense to my boss to hire a software development manager for the role.

We Don’t Need No Stinking Product Management

Many companies share the common situation where in their founding days ideas are the currency not user requirements and it is sufficient for a handful of engineers to bootstrap together a piece of running software and declare it a product. As time passes the software grows in complexity, competitors arrive with shiny new features, customers start demanding software that they can use and in fact it turns out that not every end-user values the speed and "efficiency" of a command-line interface. Before you know it you look around and you’ve completely missed the internet as it blazed past you, and you are a rocking a UX that is reminiscent of the software used to control soviet-era power stations. You are so deep in your technology stack that you think Silverlight is your path to “the web” and Windows CE is a sensible mobile solution (if you can just use a little less memory it will stop crashing for sure). The limited customer feedback you receive is rationalized as whining from a sales team that just sucks at selling. Isn’t it obvious to the user what #NOSOURCE means?! If they can’t be bothered to read the documentation what do you expect?

If you've been around as long as I have, anecdotes like these might sound all too familiar.

What happens next is the business starts to feel external pressure from customers, and competitors, and investors. Suddenly it is not enough to “just” have a product that works, and the messaging to Engineering gets increasingly chaotic, there are more and more stakeholders and the stakes keep getting higher. Now the engineers have to take all these vague, but increasingly loud and urgent, requests and attempt to satisfy them. What they build isn’t what the business wants, or the business is changing too fast under engineerings feet, inevitably those outside of the engineering department who so infrequently understand what it takes to actually build software get disillusioned with the engineering team. All this is happening within an engineering team trying to solve a whole bunch of technical and process problems that come with growing and scaling, throwing chaotic and often contradictory demands into the mix is a surefire path to waste, failure, and misery. Is that really where you want to go?

You and Engineering form a symbiotic circle, what happens to one of you will affect the other, you must understand this...

I’m not suggesting that engineering teams can’t be successful without a Products group, but something magical happens when you can build strong collaboration between the two. Teams that not only seamlessly integrate but actually overlap so that when you look at the “team” you cannot tell that it is made up of different departments. Sometimes engineers who haven’t experienced this symbiosis fear that they will become nothing more than cogs in a machine run by “the business” and that their creativity will be siphoned off as they pound away at their keyboards. To be fair perhaps they have experienced a “bad” variant of this relationship, but for the sake of argument let’s examine a good implementation. Engineers building a product are already serving the business, the idea that having a team member who can provide insight into users, competitors, vision, and priority in ways they probably have struggled to is going to make their job in some way less satisfying simply doesn’t make sense. Yes it will establish new boundaries on what you build and when you build it, yes it may push you in new directions that challenge your beliefs or push you outside your comfort zone, but if done right it will help you create software that people will actually want to use, and I can’t think of much that is more exciting than that.

The key word is collaboration and sometimes it does go wrong, sometimes a products group does become a master barking orders at the engineers as they cower in their cubes, perhaps you can find a short term return from this approach, but the downsides will quickly outweigh any benefits. Any engineer worth his salt won’t put up with that environment, innovation will be crushed, trust will vanish, and quality communication will quickly break down. Fixing teams that have experienced that kind of environment is not easy, the scars of betrayal run deep. When the products group becomes a tool used to push the engineering team rather than being brothers in arms it all breaks down, we undo decades of workplace progress because we fear that which we don’t understand, the art of software engineering.

Even Colin McRae Needed Help

Rally drivers have a co-driver who sits in the car alongside them. Without the co-driver the driver has no chance of being successful in a race, the co-driver’s role is to constantly communicate the road ahead, the severity of turns, bumps, drops, and other obstacles. The driver puts a huge amount of trust in the co-driver as he makes velocity and direction choices for the vehicle based on that information, information that if wrong could end very badly. In turn, the co-driver is putting similar trust in the driver, that he is going to use that information responsibly and safely. They both have to get over the finish line in one-piece and they both want to win.

I am totally in love with this analogy, it illustrates the way the products team (co-driver) and the engineering team (driver) should work together. The co-driver sets the context, communicates importance, priority, and gives some insight into the future. The driver takes all of that information and applies it to moving the vehicle toward the finish line, but not blindly with only the information from the co-driver, but assimilating those data points with what the driver can see through the windshield and feel through the steering wheel in his hands and the pedals at his feet. The co-driver doesn’t know everything, if there is an unexpected rock on the road ahead it is the driver that needs to react in realtime to safely deal with the obstruction. Each participant knows the importance of their role and trusts the other to share the same goal. The co-driver doesn’t understate the severity of a curve because they think the driver can take it faster, the driver doesn’t ignore the directions relayed by the navigator because they think they know the path to the finish line better. They form a mutual trust about each others abilities and desire to win.

Let me put it this way if the question you find yourself asking is

“Without the Product Owner/Product Manager/Scrum-master/Jailor/Dictator acting as a project manager, who makes sure the engineers are working fast enough?”

then I would suggest you need to step back and look at your organization. In this statement “project management” equates to whipping, suggesting that engineers don't share the same goals and even given the correct context won't be motivated to "win". The real answer to engineering productivity lies in more general process improvement and increased trust with the product and executive teams, it has nothing to do with whipping a team over a project finish line. Using a Product Owner as a project manager to “push” the team is a big smelly anti-pattern that needs to be resisted at all costs. The best advice I can give you is to build trust between product and engineering, share context in both directions, have each other's back and before long the seam between the groups will vanish. This is why it is so critical that the Product Owner is an actual member of the team not just a member of products who shows up to a few team ceremonies to point at a deadline.

Magic Happens When Products and Engineering Drive Together

Whether you are a startup that doesn’t yet have a products group or you have one but the results aren’t where you’d like them to be, take a close look at how products and engineering work together because they are at the core of what you do and when they align magic happens.

Colin McRae Image Carolyn Colin McRae crop CC BY 2.0