Product Management (PM) is a challenging discipline. More than almost any other role on a product team, it requires a holistic view on the product, its customers and the marketplace. A successful PM often needs to put him or herself into the shoes of multiple stakeholders, and advocate for the interests of those stakeholders in planning and execution. And though Product Management is a critical part of the product engineering process, sometimes as a PM, you might find yourself at cross-purposes with your development team.
Over the last decade, I've occupied a handful of roles that encompassed Product Management within my job responsibilities. Over the last two years, I've served as the Product Manager for Kendo UI a popular HTML5 framework for building rich sites and mobile applications. Across all of these roles, I've discovered a handful of axioms that development teams and PMs should know about Product Management and the people who occupy these roles, but which aren't always easy to come right out and talk about. In this article, I'll discuss the following five axioms, and share how a successful PM can communicate these to his or her team:
- Marketing is a vital good, not a necessary evil
- The customer really is always right
- The customers you want matter just as much than the ones you have
- You're on the development team's side
- A rockstar development team makes your job look easy
Before I start, though, it's important to note that my perspective and experience with Product Management is in the realm of software product development. Even still, while I might show a little bias for software teams in this article, I believe that many of these principles apply to PM in general, regardless of industry.
Marketing is a vital good, not a necessary evil
I've been a developer for pretty much my entire career. And even though I've held Software and Enterprise Architect roles, led a few teams, worked as a Developer Evangelist and now Product Manager, I've always considered development at the core of what I do and who I am, professionally. Because of my bias towards development, I've found myself at odds with marketing organizations and marketers on a few occasions in my career. I also I know how easy it can be as a developer to consider the role of the marketer, and even the seller, as secondary to the act of building a product.
To put it bluntly, developers can sometimes fall into the trap of believing that the code they pour into the product is the only essential piece of that product. Logically, we all know this isn't true. "Build it and they will come" rarely works in a crowded marketplace, and a product without marketing is, to grossly misinterpret U2, like "a fish without a bicycle." Wait, that's not right, let's try again. A product without marketing is like building a baseball field in the middle of an Iowa cornfield, not telling a soul, and expecting to turn a profit. Only otherworldly intervention could be expected to yield a result in such a case.
Products need marketing, just like they need sales, accounting and every other activity that goes into building sustainable software, all of which allows developers to focus on actually writing code. And while very few developers will deny that marketing is essential, often their frustration stems from the fear that having marketing too involved in a product leads to "Marketing Driven Development." And, to be fair, this is a valid fear. Sometimes your product marketing team will suggest features designed to tell a good story and bring in a rush or traffic or next batch of customers, but which may add little value to, or even harm your product, in the long run. Your job as PM, then, is to bridge the gap between marketing and development and advocate instead for "Market Driven Development," where the unique perspective of your marketing team is leveraged in the planning of your product. The fact is, your marketing team is just as vested in the long-term success of the product as you and the development team are.
As PM, I regularly lean on my marketing colleagues to provide critical analysis of our product, our customers and the marketplace. The data they collect and the analysis they provide creates a robust view of customers and the market that would otherwise remain unseen. The role of marketing is critical to building a product over time, and a successful PM will be a regular advocate for marketing and the essential role they play in shaping the product.
The customer really is always right
Anyone who's ever worked on a development team has probably either heard or said the following: "Our jobs would be so much easier if we didn't have any customers!" And while this sentiment is mostly a tongue-in-cheek observation, it often comes from a place of frustration. When development teams are organized, especially around greenfield products, they're often able to live in a customer-free valhalla for a time. Sure, they'll have Product or Project Managers to work with, or even the occasional executive sponsor, but much of the team's early development is done in a vacuum. Code is elegant, the team is clicking, and the feedback loop is nice and small.
Once a product is launched into the wild, things change, and drastically. PMs and executive sponsors are still involved, but now, the development team has to deal with the two-headed monster of support and customer feedback. From an engineering team's perspective, these two inputs might as well be called "what's wrong with your product" and "what your product should have shipped with." It should be no surprise than that it's quite common for development teams to quickly dismiss customer feedback with the phrases "not a bug," or "works as designed." And to be frank, this is fair. For popular products, development teams can be downright inundated with customer feedback, and developers tend to cultivate special skills for quickly triaging customer interactions.
And yet, within nearly every bug report and piece of customer feedback is a kernel of truth, even if those requests are "wrong," on face. Every bug report that's not really a bug is an example of a customer struggling to properly use your product. Every piece of dismissed feedback is an opportunity for your product to be that much more of a joy to use. As a PM, your job is to serve as the "Customer Whisperer" for your team. You can drill down to the essence of what the customer needs, even when the development team dismisses the request outright. The solution might be as simple as improving the way a feature is documented, or as complex as changes to the product itself. Either way, a good PM is able to distill patterns and trends from all customer feedback, and determine what changes are really needed to continue delivering a great experience to customers.
The customers you want matter just as much than the ones you have
Part of my job, as PM, is to be the "keeper of the roadmap" for a product , or set of products. The job entails drafting the long-term vision for the product, and populating the backlog for each release with a candidate set of features and fixes. Once a draft roadmap has been set for an initial release, I put my candidate recommendations in front of the development team and ask them to tear it to shreds. Over the last few years, our team has settled into a great workflow, and the time we spend collaborating on the plan for a release is one of my favorite parts of the job. I do my best to bring a high-level market- and customer-informed perspective to the table, and the team does a fantastic job of bringing their "in the trenches" perspective and complete mastery of the product, in turn.
The majority of the time, there's a great deal of give and take in this process. However, on occasion I'll hear someone use the phrase "no one has ever asked for that," in response to a candidate feature. From a developer's perspective, this is a perfectly valid response. Why bother spending time on a feature no one is asking for? Often, this response is enough to table a feature and move on. But it's not always the right response.
The truth is this: unless you work for Facebook, the number of customers you don't have, but want is probably many factors larger than the number of customers you have, today. Growing your product means growing your customer base, and to do that, you have to know why these individuals aren't already customers of yours, and what it will take to make them customers. As PM, your job is to know what the customers you don't have will want, and to be the voice of those silent customers for the product.
Of course, the customers you have also deserve a powerful voice with your product. But even for these loyal folks, the "no one has asked for it" argument isn't always iron clad. Markets change, sometimes overnight, and customer needs change frequently, as well. As PM, having your hand on the pulse of the market helps to not only know what potential customers need, but also what existing customers will need six months or a year from now.
Take Apple's iOS 7 Mobile OS, for example. While Apple's move to introduce drastic, "Flat UI" design changes to iOS was a surprise to many, the company's move was made in response to broader design and UX trends that have been happening for a few years now. Both Google and Microsoft flattened their mobile UIs in recent years, and were praised as a result. In many ways, Apple's move was just a matter of time. And while we on the Kendo UI team had no inkling of when apple would move iOS in this direction, we anticipated the "flattening of mobile" on our team, and moved to introduce a full-scale "Flat UI" theme in our most recent (Q2 2013) release, something that had been planned before Apple's iOS 7 unveiling. A lucky guess? Sure there was a bit of luck involved, but it was by paying attention to the market and anticipating what our customers would be asking for in the future that led us to take that risk (or venture that guess, if you will) in the first place.
You're on the development team's side
With all this talk about customers being right and marketing being critical to the product, it might be easy to become convinced that Product Management is more about these stakeholders than the development team itself. But the fact is that, without a product, there is no Product Management, no Marketing, no Sales and finally, no customers. And without a development team, there is no product. It goes without saying that a product needs a development team.
Having a great product development team, though, is something else entirely. It's not just about having a collection of people who know how to write code that makes a product. Talent is great, but it only goes so far, especially over time. Instead, having a great development team is about having people who are talented and passionate about the product that they're working on. If the development team cares about it's work, is excited about the potential it holds and feels that their work has meaning, you'll be amazed at what they are capable of delivering. On the other hand, if they feel that their personal stake in the product has been mortgaged off to others, their satisfaction will degrade over time, and the product will suffer.
As Product Manager, your job is to make sure that your development team always has a stake in the product, no matter what. At a fundamental level, this means giving up sole ownership of the product roadmap or backlog, and inviting the team to collaborate on the plan at every stage. While some PMs prefer to "own the roadmap" for their products, I prefer to "own the conversation." Rather than managing a piece of paper that represents the plan, I like to think that I'm responsible for making sure that planning takes place, contributing my expertise and perspective, to be sure, but most of all ensuring that every voice is heard, and taken into account.
Make no mistake, though, when you invite the development team to have a larger stake in the product, you will be making your job more difficult. Keeping your development team passionate and engaged might mean that you need to make difficult decisions from time-to-time. Sometimes, for the good of the long-term health and viability of a product, you'll need to weigh the happiness of the team over squeezing every last feature into or dollar out of the product. In practice, however, I rarely find these decisions all that difficult because an engaged development team shines through every line of code in your product, and your customers will most certainly notice the difference.
A rockstar development team makes your job look easy
As a Product Manager, you'll sometimes find yourself in situations where you're serving as a mouthpiece for, or being seen as the face of, your product. Whether it's participating in PR for your product, presenting product updates to the marketplace or speaking to communities as a representative of your product, you'll regularly be "that person who works on product x".
And while there's no doubt that PM contributes greatly to the success of a product, for many of the reasons we've already discussed in this article, a first-rate development team makes your job look easy. I know this, of course, because I work with such a team, and I've seen first-hand how a great team makes building a great product simple, and fun, to boot. If you're in a similar situation with your product, you know exactly what I mean.
The question then becomes, should you tell your development team as much? Of course you should! I'm not a big believer in the "withholding praise" style of management and team collaboration, mostly because I believe it's disingenuous and a manipulative motivator of people. Instead, regardless of the jobs I've held or the companies I've worked for, I've always tried to be a team member who regularly reminds people just how much I value them. As a PM, I believe it's critically important to let every single person you work with know exactly how much you value their contributions to the team, including your product's development team. On a great team, everyone tends to make everyone else's job easier, so never hesitate to tell great developers exactly how great they are!
Show, Don't Tell
My first writing love is fiction, and fiction writers have a phrase they use when describing how to tell stories about people, places and things: "show, don't tell." While it sounds like a bit of contradictory advice to give someone who's only storytelling outlet is the written word, the spirit of this advice is for writers to move a story along by showing how people act, instead of merely by what they say.
My advice then, to Product Managers, aspiring PMs and myself is the same: "show, don't tell." We might wish that we could come right out and say these five things to our development teams, but when we act as though these things are true, we never have to say a word. With that in mind here are five actions that, I believe, communicate the above axioms much louder than words:
- Be an advocate for "Market Driven Development" on your team
- Be a "Customer Whisperer" to your developers
- Be the voice for the customers you want, as well as the customers you have
- Ensure that the development team has a powerful voice on the product
- Let the development team know how critical they are to product success
Product Management is a challenging discipline, but it's also one of the most rewarding roles I've ever held. It requires a total cross-team perspective, and the ability to advocate for multiple points of view. And while Product Management and product development don't always see eye-to-eye, a successful Product Manager knows how to advocate for everyone involved in the product, and have fun while doing it.