Product Management Is Easier When Your Team Can Actually Ship.
Product Management is a tough job. One of the toughest aspects is the fact that, in nearly all cases, you are on the hook for delivering a product, and yet have no direct authority over the team members doing the work.
It feels imbalanced at first. Look at the title: “Product Manager.”
“I am the manager of this product,” you think. “Shouldn’t I be able to tell people what to do?”
No. You shouldn’t. Product development doesn’t work that way, as I have belabored endlessly elsewhere.
Instead of authority, you must use other tools such as empathy,collaboration, influence, and incentives to empower (not direct or instruct) your teams to ship.
Let’s focus primarily on the empathy strategy for this post. Maybe we’ll cover the others another time.
We have all either said, or heard a product manager say, a sentence like this:
“I can’t understand why the engineers are not getting their tasks completed. I keep asking for status and estimates, and they keep waving me away. I am afraid we’re going to be late shipping this product, and I don’t know what to do!”
I feel ya, man. There is nothing you can do at this point, apart from wringing your hands and waiting. Maybe bring them coffee. But earlier onin the project, there was quite a lot you could do. Let’s dig into that stuff, shall we.
Not An Engineer? Learn To Think Like One!
The best product managers I have worked with are able to feel and express deep empathy with the designers and engineers working with them on a product. Some of them have been engineers previously in their career. Others have been able to pick up on the engineering mindset along the way.
[I am going to lump you designers in with the engineers for this post. There are enough similarities in this particular area that you’ll appreciate it.]
Engineering, software engineering in particular, is a peculiar job, different from most others. Engineers are motivated primarily by the desire to solve hard technical problems by constructing something novel, something of their very own design, in order to solve it. There is nothing more satisfying to an engineer than to see a system she’s built humming along processing data and making users happy.
It’s the joy of the craft. That’s what we’re in it for. You need to understand that motivation very deeply to be any kind of reasonable product manager who works with engineers.
Often, you’ll hear complaints by non-engineers that the engineers get too caught up in the particulars of one technology or approach over another. And certainly that can be true. I am as guilty as anyone of occasionally picking that new JavaScript tool for a project just because I want to try it out.
But an engineer’s desire to construct solutions is not a distraction or a liability for your project if leveraged carefully; it’s an asset. But like a nail gun, if you don’t know what you’re doing when you use it, you’re likely to end up with a nail in your foot.
Your job as a product manager is to guide and influence your fellow engineering teammates (note the emphasis that they’re your peers and not your subordinates) to solve the right technical problems at just the right stage of the product development process. It’s all in the timing. And to understand the timing, you need to understand technical risk.
De-Risk Technical Tasks Early And Often
Every project has some degree of technical risk. As I wrote in more detail here, the value of software is in its novelty. Each new technical problem that is solved with software, is only ever really solved once. From then on, it may be refactored and improved, or copied pattern by pattern. But the first time is the most valuable, the biggest shift from some business process that is manual to something that is automated. Once written, the same functions can be used in an infinite number of combinations whenever that same problem appears.
Given that, an engineer will think about a project in front of her as a set of choices that fall roughly into two buckets: what to build versus what to borrow/buy. We want to build, sure. But if we are experienced, and hopefully at least someone on the engineering team is, we won’t attempt to build components that have already been built well by someone else. Every part of the system that represents a solved problem goes into the borrow/buy bucket.
No one in their right mind would build their own mail delivery system today. You would use something like SendGrid, or Mandrill, or whatever. Likewise for many other services like payment gateways or even search. Even lower level, most of us would eschew designing our own web framework or template language unless the problem you have is so unique that you simply must start from scratch. And even then, I would challenge you.
[Likewise, good designers do not spend all of their time designing new form components from scratch. They leverage libraries and frameworks that exist, and apply styling for the right brand and interaction design decisions for their customers’ context. Same principle as the engineering examples above.]
Every other technical area that does not have an existing reliable solution already available in the market or on GitHub goes into the “build” bucket. That is going to be where your product team’s intellectual focus needs to be most of the time.
For this second set of items, the engineers do not know what problems they will find as they build or how long anything will take. It has simply never been done before. It’s not possible to estimate because there is no historical data.
The way you, as a product manager, can be really helpful in this scenario is to help divide all of the pieces into these two buckets. Fully understand the functional requirements of the product, and do it together with the team. Is this mobile or web or a service? Are there payments? Authentication? Search? Mail? Calendaring? What existing services or components are out there that can save time for the team?
At essence, you are carving away everything from the project that isn’t absolutely unique to your value proposition. Get involved with the team in figuring this out, and earn their respect by knowing some of what’s out there. Label that “borrow/buy” bucket stuff and then put it aside.
Finally, as a team, prioritize the big, scary unknown pieces (maybe using this framework) that are left in the “build” bucket. De-risk those unknowns first. Everyone knows how to integrate with SendGrid. That’s not a risk! A unique machine vision algorithm to differentiate humans from dogs (I dunno, whatever). Now, that’s more complicated. Do that first!
Adding People Won’t Help
One more thing. So, you’re late. Get over it.
Adding people to a late project only makes it later. We’ve known this for nearly 50 years, maybe longer. It’s the subject of the infamous book by Fred Brooks, the title of which you’ve no doubt heard, and which you’ve almost certainly not read: “The Mythical Man Month.”
The basic idea is that every time you add a new person to a project, there is an exponential — as in, nonlinear — increase in the number of communication links between each person on the project to each other person on the project. It’s basic networking math. So, in practical terms, when you add a new person to a project, the poor bozo has no idea what’s going on. They have to be ramped up. Someone has to stop what they’re doing to show them around, introduce them to the code.
It is therefore the biggest, most common mistake in software projects when they are late, that some clueless manager says, “get them more resources!” It never works. And you can kinda tell right there because he called people resources. Obviously has no idea how management works, much less product development.
Cadence, Balance, and Flow
What’s left for you to worry about? The final piece of the puzzle is to learn how you can be a support to the team and not a hinderance.
Generally speaking, once the team is on its way, cranking away at the code, you more or less want to step aside. Your focus should be on making sure that the engineers have the information they need at the right times. So you need to understand cadence, balance, and flow.
Cadence refers to the rhythm of the development process. This is where you have your weekly planning, your daily stand-ups, that sort of thing. The team should figure out what cadences are appropriate for them (including you in this decision — you are still on the team, remember?). Whatever cadence the team establishes needs to take precedence for any communications. In the middle of the week? Don’t change the plan from what we said it would be on Monday. Let it play through.
Balance is also important. Sometimes an engineer will be hard at work on a core feature. Other times they will be cleaning up some code, or fixing a frustration in the tooling or infrastructure. These trade-offs are necessary. It’s part of the job. Respect your engineering peers by allowing them space to oscillate between cutting the wood and sharpening the saw. They can’t be running full speed all the time. I mean, unless you want to lose them to Amazon or Facebook. That’s your call.
Finally, flow is the near mythical state of being that a person enters when they are really in the zone. It was researched extensively by Mihaly Csikszentmihaly and then later popularized by Dan Pink in the book, Drive. Flow is hard to directly affect. You can really only create the conditions for it, and then allow it to emerge naturally. But know this: Whatever you do to break the flow of the team is a bad idea. Pay very careful attention to this if you want to stay employed as a product manager.
Conclusion
Product management is hard. It’s sometimes a thankless role with many pressures and responsibilities and little power or authority. But the best product managers are folks who everyone wants to work with.
Learn to think like an engineer and respect the craft.
De-risk hard and scary technical problems early in the project.
Enable your team to achieve cadence, balance, and flow.
Do these things and you are greatly increasing your chances of shipping the right thing at the right time next time. Good luck.
