Chapter 3
YOU’RE ACTUALLY MANAGING PEOPLE, NOT PRODUCTS
I hope by this point you’ve begun to feel a sense of enthusiasm about product management and understand why it’s so important and how stimulating and rewarding the work is. There is excitement in the journey of bringing a new product to life. But the job isn’t for everyone, and this is in large part because it involves not only managing products, but managing people.
Product managers will almost always both report to a manager and manage other people. You’re responsible for the collective efforts of a virtual team of people across the different departments within your company, even though none of them report directly to you. And if all goes well, at some point you’ll probably also end up directly managing other product managers, as well as business analysts and possibly even developers and designers. Your product’s success (and so your own) is largely contingent on your ability to understand, relate to, and influence others well. One of the side effects of being hooked into so many different aspects of your organization is that you’ll quickly uncover the dysfunction. Every company has some kind of dysfunction—whether a charming eccentricity or a less desirable habit—so you just have to figure out how to cope with the various kinds of dysfunctional behavior. And that can get rocky.
As the one in the center of the three rings, the product manager bears much of the burden of reconciling competing views and goals. The most common ways in which any organization goes wrong boil down to the triumvirate of poor communication, incompetent or adversarial senior managers (those with a “them and us” mindset), and lack of alignment with a shared vision. These are all people problems—and you’re the person in the eye of the storm who has to overcome them. I’ll be honest, the job can sometimes feel like a struggle against the machinations of people whose sole purpose in life is to derail your product at every turn. Jean-Paul Sartre wrote in his play No Exit, “Hell is other people.” On some days, I know exactly what he means.
A product manager is often described as the “CEO of the product,” but this is misleading—you will rarely have any of the direct authority that the term CEO implies over other departments, and sometimes only limited authority over the development team. This is why you’ve got to achieve success almost entirely through influencing others to follow your plan, which is made much more challenging by the fact that more often than not your coworkers fail to understand your role or appreciate your value. To have the necessary influence, you must empathize with all the various players, speak their language, and earn their respect. The good news is that the sorts of issues that come up tend to fall into categories with which you become familiar, and you will get better and better at heading them off at the pass.
Every new product assignment is an exploration into treacherous terrain, and like a clumsy explorer, over the years I’ve tripped into every ravine, poked every wild bear with a stick, and been bitten by every poisonous snake. Along the way I learned to have a good deal of humility, and I tell my Golden Rule—to ignore or do the opposite of what I suggest—to every product team I work with. The advantage of my mistakes is that I’ve learned some valuable things about how to work most effectively with each of the main groups of people you’ll be working with as a product manager. Here I want to give you a sense of what their respective roles should be when done well, and also illustrate the typical dysfunctions that crop up and how you might circumnavigate them. Are there organizations out there that have only paragons of excellence working for them? Absolutely. Have I bumped into any of them? Occasionally. Most often, you’ll have one or another laggard or difficult person to cope with.
I should also hasten to add that although I have performed each of the following roles in at least a basic capacity at some point in my career, which I hope qualifies me to make some observations from both sides of the fence, I make no claim to be an expert in any. I should also mention again that my experience has been almost exclusively in creating software products, so the personnel and issues covered are specific to that domain. But the issues that come up are mostly fundamental human issues, so they are likely quite similar in any product domain.
THE DEVELOPMENT TEAM
A product manager’s relationship with the development (or engineering) team is one of the most important ones to get right, so I’ll start with them. Software developers are an interesting bunch, but they can often be a difficult group of people to work with, particularly if you don’t come from a technical background yourself. Google, as mentioned earlier, only recruits product managers with computer science backgrounds, on the basis that anyone less technical will fail to “earn the respect of the engineering team.”1 Developers’ impatience with a lack of technical knowledge is perfectly understandable; to them programming languages, frameworks, software architecture, operating systems, networks, and the workings of hardware are the stuff of daily nuts-and-bolts process. Each comes with its own sets of rules and constraints, and a developer has to negotiate all those constraints like a multidimensional crossword puzzle in order to make the product actually work. Unaware and unrealistic designs can be infuriating.
The really good developers can instinctively tell from a set of your software requirements where the complexity, performance bottlenecks, and other difficulties will arise in making the vision a reality. And that’s before they encounter a previously undiscovered bug in one of the many different building blocks of third-party software they’re relying on to assemble what you need, which necessitates them to either rethink the whole approach or undertake a massive development detour to work around the problem. They’re like car mechanics who can diagnose a leaking cylinder head gasket from the sound of a running engine alone and can strip down and fix the offending part by the end of the afternoon—but more so. Developers are miracle workers. They turn a product vision into reality and make it look easy.
If you really want to annoy development, follow these easy steps:
- Have no technical understanding whatsoever, nor any desire to acquire it.
- Be vague or ambiguous in your product requirements.
- Belittle tasks by declaring that they can’t be that hard.
- Never use the product.
- Change your mind without warning and then expect delivery timescales to remain the same.
- Shift all blame for a product disaster to the development team.
- Shout and stamp your feet like a child when you really want things done.
- Never provide context or reasoning for any decision.
- Start offering advice on how to implement a feature, even though you have no idea how to do so.
- Use technical terms you don’t know the meaning of.*
- Never consult the opinion of anyone in development before making a technical decision.
- Promise features to customers or the board without first checking whether they’re possible.
- Never celebrate releases or customer wins with the development team.
If, on the other hand, you want to work well with them, develop a good understanding of the difficulties they’re dealing with, which many people at most companies neglect to do.
Your relationship with the developers is important for many reasons, but one is that very often the senior management regards the development team as obstructive and slow-moving. Of course, occasionally the criticism is justified, but more often than not the development team is perfectly capable and senior management has unreasonable expectations of how much can be achieved in a given period of time, or the product has become so knotted up that even a simple change takes ages. The team’s efficiency may also be hamstrung by a collection of outmoded, complex procedures that they’re obliged to follow but have no authority to streamline, which upper management tends not to want to hear about.
Of course there’s no denying that developers can sometimes be hard to work with. People with minds finely attuned to the nuances and complex interactions of software can have a tendency to relish minutiae over the big picture—sometimes to an obsessive degree. When coupled with an almost religious fervor for the “right” way to do things and a surprisingly vigorous approach to arguing their point when someone suggests any alternative path, they can be incredibly frustrating people.
Early in my career, when I was still working as a tech support operative at Zeus Technology, I could always easily provoke the entire development team into a heated debate. I’d just lob a conversational hand grenade into their midst, such as asking which of the two predominant text editors at the time was better for writing code. Developers can also be undeniably geeky. I remember one Zeus social evening where at one end of the room the sales guys were belting out songs on the karaoke machine, spilling their pints of beer, while at the other end the development team had rigged up a multiplayer computer game and were all huddled around a table, glued to their monitors.
In any team of people you’ll find a spread of personalities, and developers are no different. I’ve found, though, that they do tend to break down into types: the visionary, most likely scribbling frenetically on a whiteboard somewhere, possibly while wearing a hat and cloak; the deep but narrow-range specialist, often a sage-like character whom the more junior developers are slightly scared of; the perfectionist, who’s most likely to be engaged in a pedantic argument over an inconsequential aspect of programming; and the no-fuss, get-it-done implementer. You’ll hopefully also find among them the team player, an immensely useful inside man who can defuse arguments and mediate with the rest of the team to come to consensus on which way is in fact the “right” way.
I’ll be the first to admit that personality foibles go both ways. The developers I’ve had the pleasure of working with have also had to put up with my early-morning cognitive failures and occasional grumpiness. And it has to be said that product managers can step outside their expertise and make the mistake of micromanaging development. There have been many occasions when I’ve strayed too far from specifying what we need and why, and into how I want it to be delivered. And if you’ve ever been told how to do your job by someone who only vaguely understands what you do, then you’ll appreciate how immensely annoying that can be.
When it comes down to it, most developers share a desire to work on interesting, stimulating projects and to be recognized in the way they would like for their good work, just like every other person. Keeping this squarely in mind in your interactions with them will go a long way toward helping you cope with the irritations. Try to become sympathetic to the many sources of their own frustrations.
One development team I worked with was still largely Waterfall in approach and prioritized features by the MoSCoW method, which is short for Must have, Should have, Could have, and Would (or Won’t) have. Their quality control procedures required them to provide time and effort estimates for all items designated as Musts and Shoulds, and I’ve yet to meet a developer who enjoyed creating estimates. In the context of a large organization that was trying to manage the availability of a limited number of developers across multiple projects competing for their time, this seemed to management to be a sensible approach, but in practice the process of estimation often took as long (or longer) than it would have taken to just fix the problem there and then.
So on one project, in which we were primarily going to be squashing software bugs, I turned to my assembled developers and suggested conspiratorially that I would make every single product requirement a Could, providing they agreed to work from the top of the priorities list downward in order until they ran out of time. This meant they didn’t need to waste their time on creating estimates that were bound to be wrong, and instead could concentrate on fixing bugs, which they did in quantity. Everyone was happy except for the senior development managers, who were a bit miffed that we had subverted their lovely quality control process. But the team got the job done. Sometimes developers are just looking for permission to operate in another way because they’ve been micromanaged into inefficiency.
Developers also like to be free to exercise their creativity, which can lead to great things. However, creativity can be a double-edged sword. While a bit of lateral thinking can neatly sidestep an obstacle, it may also lead a project off track. So though you don’t want to second-guess their every move, if your team is stumped by a particular problem, you should work through the obstacles with them. One thing I’ve learned to do in that event is to get them to explain their assumptions. You may find that they’re working hard to preserve the function of something in your product that is no longer very important, and once it’s taken out of the equation, the way forward is much simpler for the developers. Again, it can boil down to the rules they feel compelled to follow; if you’ve previously told them not to break existing product features, then they’ll do their utmost to respect your wishes. You just need to remember to tell them when they’re allowed to make an exception.
In some cases, creativity can also lead to a “science project” where a left-field, convoluted approach is chosen over a more straightforward choice because it’s cool or difficult or has never been done before or will demonstrate the developers’ Jedi prowess. This can result in tech for tech’s sake, and developers sometimes need to be reminded that the fact they can do something doesn’t mean they should. Always keep an eye out for science projects—if the proposed solution seems overly complex, get a second opinion and rein things in.
Developers can be wary of people in suits who tend to disrupt the development team’s peace and routine with unreasonable and unexpected requests. Product managers may occasionally have to wear suits, but you should really try to avoid being categorized by development as a suit. It’s very easy for your developers to perceive you as just another disturbance that’s going to make their lives more difficult for a while, lose interest or fail, and then go away. So for them, ignoring you can be an effective strategy. Particularly if you’re new to the company, you may have to work quite hard to disabuse them of this impression. You need to become a black-belt expert on your product, its quirks, and its undocumented features (read: bugs) and penetrate the obfuscating technical jargon that may be keeping you from understanding things fully. Only at that point will you be able to prove your worth to the development team and earn their respect. Once you get there, the benefits of a working relationship based on mutual respect are boundless.
THE DESIGN DUO
Design is a mystical art to me. I appreciate good design when I see and feel it, but I’m simply not wired to do it well myself, a fact readily apparent to anyone who’s seen one of my homebrew presentations—they’re so garish they can induce seizures even from a distance. So to me, a good designer is a magician who can conjure into my mind the instant understanding of what a product is and how it should be used, and I’m always slightly in awe of those who can do this. (Just keep that between you and me.)
In working with designers it helps to appreciate that they tend to be schooled in design principles, which generally matter a good deal to them. One of those principles that I’ve come to appreciate in the same way is the mandate for simplicity. Aziz Musa is an all-around product good guy who delivered a fantastic talk at the Mind the Product conference in London in 2013 on what he calls “pure products.”2 A pure product is one that combines profound simplicity with beauty. Musa explains that “profound simplicity is not merely the absence of complexity, it is the exquisite mastery of it.” A product that has been stripped down to a single capability is superficially simple because it can do only one thing, whereas a product that remains simple to use despite its inherent complexity is profoundly simple. Think of those old Palm Pilot personal digital assistants that only really had a calendar, a to-do list, and an address book (superficially simple) in comparison with an iPhone that is a communication device, a camera, a portal to the Internet, and a library of your entire music and book collection and yet remains simple enough to use without recourse to a thousand-page instruction manual. And it happens to have apps that provide a calendar, a to-do list, and an address book. That’s profound simplicity.
Beauty, Musa continues poetically, is a matter of more than just aesthetics; it’s that indefinable stirring in one’s soul on seeing something truly beautiful. Shakespeare eloquently describes the same feeling in Ferdinand’s speech to Miranda in The Tempest:
… Hear my soul speak:
The very instant that I saw you, did
My heart fly to your service; there resides,
To make me slave to it3
Good designers can take the complex and make it profoundly simple. Great designers will also stir your soul and bewitch you with the beauty of their design.
But like developers, designers can be difficult, and again, they come in several flavors. You’ll be most likely to encounter a particular design duo. The first half is on the more creative range of the spectrum. Visual (or graphic) designers create all sorts of hard-to-discern items, such as mood boards, and gather other eclectic and eccentric sources of inspiration that may seem alien if, like me, you don’t have a visually creative bone in your body. Visual designers combine psychology and symbolism with colors and imagery to evoke the desired feelings with their designs. Give them some time and space and you’ll be astonished by what they create. It may not be remotely practical, but it will probably be beautiful.
At this point you can start to bring to bear some of your user-centric, analytical thinking, which you should do with a good dollop of tact. The initial visual designs may turn out to be bat-shit crazy, but there’s usually a kernel of brilliance in there somewhere that will resonate with the user. Acknowledge and appreciate the designers’ creation, but then work with them to focus and iterate on the part that’s relevant. There’s always a temptation to get swept up in the process of creating beautiful things and digress off the track of combining form and function. If you work with designers in a spirit of appreciation, they will usually value that you’re keeping at least one foot on the ground for them.
User experience (UX) or interaction designers are the other part of the duo, and they’re a somewhat different breed. While the visual designers are the ones creating snapshots of particular aspects of the product to illustrate the colors, typography, iconography, and layout, the interaction designers are the ones who detail how users move from one snapshot to another in practice. UX designers also bring consistency, the intelligible system of visual clues that users need in order to understand how to use the product. These people should be some of your greatest allies, as they, like you, are meant to focus on the needs of the users and the ways in which those users experience the product. UX designers take the product’s purpose (to allow a user to complete one or more specific tasks) and design the ways in which the product will help the users achieve their goals.
In interacting with UX people, I’ve generally found that they’re largely in sync with product managers, but there are some pitfalls to watch out for. One is that UX designers may want more time to do user research, build prototypes, and test the product than the development budget allows for. They may want to add some features, like cool new interfaces, that you don’t have the time or budget for the developers to program. You may also clash with them regarding what’s really in the users’ best interests. For one thing, UX designers are specialists in determining that, so they may claim bragging rights. But as with developers, there is always a danger that UX designers will fall back to designing for themselves rather than the target user. The research you yourself have done about users will help avoid this and provide a basis for discussing user issues in the UX designers’ own terms. Take the time to come to agreement about the user personas, which UX designers also work with, and to carefully consider any user research they’ve conducted. You may well be failing to appreciate the ways in which the design they’re proposing really will enhance the users’ appreciation of the product.
One of the most important ways in which you’ll be working with the design duo is by adjudicating between them and the front-end developers, who take the largely theoretical or mocked-up work of designers and render it as a working interface. The practicalities of implementing a design in code will sometimes necessitate compromise in the designs, and this is where you can be especially helpful in smoothing things out. Most visual designers still come from a print media background, which is arguably more forgiving than digital media these days. In print, a designer had to think about a relatively small number of possible levels of detail, whereas in the digital world, he has to take into account the various resolutions and screen sizes of all the different devices available, ranging from the smallest smartphone display; to desktop monitors of varying age, size, and clarity; through to the intensely high-resolution displays sported by the Apple-endowed. In print, designers never had to worry about pixel alignment to ensure their designs were clearly rendered or contend with readers attempting to resize the page. This gulf in complexity between print and digital design is one reason there can be clashes between designers and the developers.
A welcome trend that may circumvent this disconnect is the emergence of hybrid front-end developer-designers. Ordinarily a developer who claimed to be a front-end designer would be deluding himself. Just sneak a look at the screen of your local coffee shop next time you visit. The blocky, Windows-looking software styled from circa 1997 running on the point-of-sale device may be functional, but it sure ain’t pretty. And I’ll bet the baristas’ souls don’t exactly sing when they use it, either. However, there is an increasing number of developers who have legitimate design credentials as well as the technical know-how to write code. Hopefully there will be many more of them in the coming years.
MARKETING MAGIC AND MAYHEM
In many aspects, marketing and product management are similar; you could even say they’re codependent. Both involve two-way conversations with the market to understand its demography and needs and to make the people in your target niche aware that there is now a valuable solution to their specific problems. The research that marketing undertakes and distills should be of immense value to you as input into the creation and direction of products. Similarly, their specialist understanding of the most effective ways to communicate information back to the target market, in terms of channels, media, content, voice, and tone, should ensure that the hard work that’s gone into the product is not wasted because your organization is unable to tell anyone about it effectively. In addition, if you’re working in a business-to-consumer (B2C) company, you’ll be less likely to have an in-house sales team, so you’ll probably be selling direct through your own website, a marketplace, or an affiliate network, in which case the “selling” comes from the effectiveness of your advertising, search engine optimization (SEO), and product copy—all of which are the domain of your marketing team.
Then there’s the care with which marketing manages the brand, both of the company and the product (as the two may have distinct brand identities). Brand identity can be an immensely powerful asset as, over time, it becomes a shorthand for a desirable collection of qualities and feelings that customers associate with the company or product. As Wally Olins, the late, great chairman of Saffron Brand Consultants, put it:
A brand is about having a unique idea, personality and style and demonstrating it in everything that you do, in your products, in the way your people behave, in your communications, advertising and other promotions, and in your environments, your offices and showrooms. A brand is not a logo, it’s a presentation of who you are and what you stand for in everything you do and to every audience with whom you deal.4
When you think of Rolls-Royce cars, you perhaps think of British refinement, elegance, and opulence. When you think of Volvo, you probably think of solid build quality, middle age, and passenger safety (and probably not raciness). But brand perception is another double-edged sword. Negative associations with a brand can be extremely difficult to change. Take the case of luxury electric-vehicle manufacturer Tesla Motors, which had to fight a PR rearguard action after the press published photos in 2013 of Tesla’s cars on fire at the side of the road.5
A good marketing team can be just as magical as a talented design team, but marketing people can also sometimes be vexing. Market research, communication, and brand management are all specialist disciplines intrinsic to the success of a product, yet some of the marketers I’ve worked with failed to understand the importance of developing expertise in these disciplines. In fairness, some were saddled with having to market a lackluster product that hadn’t changed significantly since the previous millennium in a fiercely competitive market. Despite their best efforts, they were never going to achieve great success. But time and again in different companies I see the same dysfunctions cropping up.
At Zeus Technology, marketing’s solution to seemingly every problem was an expensive yet extremely subtle “rebrand”—by which they actually meant just changing the logo colors and fonts. Looking back at the archives of the website, I counted at least seven logo changes in ten years. For a while, the logo was changing every year. The design agencies must have been laughing into their Pantone mugs when they heard us coming.
On other occasions, style would overtake substance (and common sense). During a recruitment campaign, the marketing team seized upon the idea of enticing individual candidates with the message: “We won’t keep your brain in a box.” So they mailed out white twenty-inch-square presentation boxes (which looked like they should contain luxury chocolates), each with a shelled walnut half glued to the center. The walnut was meant to resemble a small brain. And apart from the slightly mixed message of not wanting to keep, and yet actively presenting, brains in a box, the impact was further undermined: first, there was the note enclosed saying the glued-in walnut shouldn’t be eaten for health reasons; second, because marketing had failed to apply the correct postage, the lucky recipient had to pay for the privilege of receiving a massive box containing an inedible nut resembling a mouse brain, all as an enticement to join a forward-thinking software startup.
Another dysfunction occurs when marketers believe that market research means exclusively focus groups and parrot back every sound bite from a focus group as the gospel truth without delving any deeper into the findings. “Eight out of ten customers we interviewed said our products were too expensive, so we need to reduce our prices.” With qualitative feedback such as this, it may in fact be the case that the products are overpriced; however, it’s equally possible that customers are not realizing the full benefits or value of the product, or that the product is not suited to the market segment targeted (and hence is not valued), or that the canny customers are simply angling for a discount. It could even be that the interviewer inadvertently introduced bias when conducting the research with a leading question: “Do you think our products are expensive?” Without further research into the product’s value and pricing within its intended market niche, it’s not possible to say for sure whether products are overpriced.
A good deal of research has shown that focus groups can lead to mistaken conclusions. One glaring example is that of the focus group response to a new sneaker design Reebok was considering. As Gianfranco Zaccai, founder and president of Continuum, the design group that devised the sneaker concept, recalls:
When Continuum pitched an idea to Reebok for a new basketball shoe that would use inflated air to better support the ankle, thereby reducing injuries, the brand manager for basketball shoes said he wasn’t interested because he had never heard about a need for that from a focus group. When we proposed the idea to a high school basketball team, the response was even worse—the players openly laughed at the concept.
But when the team members actually used an early “experiential model” of the shoe during practice, they were won over by how cool it was to have a shoe form-fitted to their feet. Over time, they were even more enthusiastic as they realized they could play more confidently without fear of injury. Like that, the Reebok Pump was born.6
Marketing teams may favor qualitative market research because it’s relatively easy to conduct and seems to yield useful results. However, interviews and focus groups are also susceptible to various research biases, particularly moderator acceptance bias (interviewees may try to give the answer they think the interviewer is looking for rather than an honest response) and sensitivity bias (focus group participants may not wish to admit weakness or a personal failing in front of their peers). I’ve found that these two biases crop up particularly often in usability tests, themselves a form of qualitative research.
In 2013, I was moderating some usability tests on a data visualization prototype in Rwanda with government employees. In that country, at least in the ten or so government departments I visited, there was a very strong management hierarchy. Employees showed great deference and respect to their managers, to the extent that their desire to impress their bosses (and outshine their peers) clearly biased their behavior and responses. For this reason, to allow the interviewee to feel comfortable enough to make “mistakes” in the usability test and give honest feedback, I had to ensure that I ran the tests strictly on a one-on-one basis (a good idea generally), meaning that I’d sometimes have to shoo the interviewee’s manager and colleagues politely but firmly from the room.
Similarly, a dominant voice on a focus group panel may cause other participants to follow the leader (dominant respondent bias), or in other situations a herd mentality may emerge (social acceptance bias). As an illustration of these peer-driven effects, Tom Webster from Edison Research described how researchers at the University of Glasgow once observed different results depending on whether individual interviews were conducted before or after focus groups:
In 1994, Daniel Wight, a senior researcher at the University of Glasgow, studied the opinions of adolescent boys as they relate to the opposite sex. In individual interviews, the boys expressed sensitive, sympathetic portraits of their opinions on girls, while in subsequent focus groups their opinions exhibited considerably more “machismo.” In contrast, a second group began with focus groups first, again expressing fairly chauvinistic views, and ended with individual interviews, in which they maintained the macho views expressed in the focus groups.7
On the positive side, it’s good that some companies are at least going out to listen to their markets, but as we explored in the previous chapter, customers can be unaware of some of their most important needs, so they’re not necessarily going to be able to articulate them in a one-on-one interview or focus group. To use the clichéd quote attributed to economist Theodore Levitt, “People don’t want to buy a quarter-inch drill, they want a quarter-inch hole.” Also, relying solely on these qualitative techniques for market research will at best provide only general insight. This may allow researchers to form a hunch (or hypothesis) of where the market has an unmet need, but it will not provide enough detail to allow them to really home in on how the product should meet that need. This is why it’s still necessary to supplement the qualitative research with quantitative testing, using the Kano method introduced in the previous chapter or other data-driven techniques. Simply parroting back what the market says it wants verbatim, without reading between the lines, will rarely uncover latent needs.
A particular bugbear I have with some marketing people is that they are seemingly incapable of communicating without jargon. Strangely, for a group of people whose role necessitates frequent communication with their market, it is too often the case that they fail to communicate clearly. B2B companies seem to be particularly susceptible. Surely not all business products need to be described as “leveraging synergies” between one thing and another, or “lowering the total cost of ownership.” My theory is that marketing people who resort to this nonsense are simply throwing up a smokescreen, whether consciously or not, to obscure the fact that they have failed to grasp what the product is, what it does, and how it benefits customers in their target market.
Sometimes this lack of knowledge is readily apparent. There was a startup called Splashpower operating out of the office next to ours when I was at Zeus that was a pioneer in wireless charging pads that would recharge the batteries of mobile phones and similar devices placed upon them. In a possibly unwise move, without consulting the engineering team, its marketing team boldly claimed that the company would soon be able to produce a room-sized charging pad that could charge devices while they were still in people’s pockets. Had they bothered to check with engineering first, they’d have established that a charging device of this size and power would essentially microwave the occupants of the room.
Another pitfall is that marketing teams sometimes end up at the beck and call of the sales team and are pigeonholed into spending all their time generating ever-increasing numbers of customer leads for sales to pursue. This can be a particularly pernicious setup, because the fact that the sales team has delegated (read: shrugged off) responsibility for finding their business opportunities may indicate that they don’t understand the product or target market (or perhaps are just too lazy). Marketing teams are often given a corresponding financial or conversion rate target on the leads they generate. This would be reasonable if the sales team could be relied on to sell the product competently, but it’s tricky if sales doesn’t understand the product and market. Meanwhile, the marketing team is likely neglecting other valuable parts of their job.
Whether because the sales team’s conversion rate of leads to sales is dropping or there is a revenue shortfall in a particular month or quarter, the poor performance of sales may result in the marketing team being forced to run more and more knee-jerk campaigns to an increasingly irritated market base. In other words, sheer demand for sales leads will sacrifice quality of marketing for quantity. Instead, it might be more prudent in this situation to examine the underlying causes of the dropping conversion rate. It could be the result of poor quality of leads in the first place, the inability of the sales team to convert the high-quality leads they’re being fed, a mixture of both, or something else entirely. Rather than simply generating more low-quality leads, a more considered marketing approach would be to take a step back and identify who in the target market would be more likely to need the product and how best to let them know the product exists.
This is where you, the product manager, come in. In the previous chapter, we looked at how important it is for you to step into the shoes of your target market and understand the needs and pains of the various user personas you define. Whether you’re gathering this market research single-handedly or with the assistance of dedicated market researchers, you should be involved firsthand. Your goal should be to involve the marketing team and share with them as much of this valuable research as possible. This will help them keep their sights on the needs of the market rather than the needs of the sales team. By highlighting to marketing the segments that you anticipate will be more interested in certain products or features over others and explaining how and why the product features solve the users’ problems, you will help them communicate effectively with each segment. Even if your product is complex or technical, you should always be able to explain or demonstrate its concept simply and succinctly to nonexperts, and by helping marketing do so as well, you will forge a strong relationship and reduce the potential for counterproductive clashes.
HARD SALES
Many business-to-consumer (B2C) software products are sold directly to customers from a website or app store, but you may also work for a company with a dedicated sales team such as Oracle, SAP, or IBM that sells enterprise products like database systems and supply chain software. If you’re managing these kinds of business-to-business (B2B) products, you’ll probably be dealing quite a bit with the sales group. Times are changing, however, and more B2B companies are now selling their products directly, like B2C products. Take FreeAgent, an accounting web application, for example, and MailChimp’s success in offering self-service email marketing.
If you do work with a sales team, you’re likely to find that salespeople are by nature shy, retiring types who need constant reassurance. Well, not quite. Salespeople generally work on a commission basis, and, frankly, this can make them somewhat loony. Some of them are so aggressive they probably found the movies Glengarry Glen Ross and Wall Street to be instructive guides rather than cautionary tales. Salespeople can annoy customers by constantly pressuring them to buy, so much so that customers may resort in desperation to buying something they don’t really want on the off chance that the salesperson might then leave them alone. That is not exactly what we’d call a healthy customer relationship.
It’s part of the natural order of things that salespeople will want product management and marketing to create every conceivable product document, crib sheet, presentation, one-pager, and demo but will never read them. It seems with some salespeople that on the day they join the company, they learn some patter to describe what the product does, probably from an equally ill-informed colleague, and keep using it for years, regardless of how much the product changes.
There are, of course, some great salespeople, and the best of them can be an important source of customer feedback and product ideas. But there’s no denying that others are boors, have undergone a dual empathy and common sense bypass, or are genuinely lovely people but lack the pushiness to close deals well. As a product manager, you’re going to have to learn to cope with both good and bad salespeople if you want your product to be successful in the long run. So here’s a quick guide to the fine art of sales team relations.
There are three broad types of bad salespeople: demanders, strugglers, and inventors. Demanders will not take no for an answer. One of the product managers on my team once told a particular sales guy—let’s call him Todd—that he wasn’t permitted to sell a product to a customer because it was sensitive, highly regulated, and was to be sold only to government agencies. Shortly afterward, Todd’s manager turned up to harangue me with a line that may become familiar to you: “Why is your team standing in the way of my sales team? They pay your salary.” After pointing out that selling the product in question would mean the managing director would go to jail for breach of the UK’s Data Protection Act, I left him to consider his next move while I went to make tea.
In contrast with the overt aggression of demanders, strugglers feign ineptitude to attract people’s sympathy and appeal to their helpful nature. Strugglers turn up at customer meetings and ask to borrow pens and paper from the client because they forgot to bring any themselves, or ask you to help them with a customer demo “because you’re so good at it.” Before you know it, you’ve pitched the product, overcome the customer’s objections, and closed the deal for the salesperson, leaving him to rake in the commission while you wonder what the hell just happened.
Then you’ve got the inventors, the ones who take two or more unrelated products, amalgamate them into a single (nonexistent) entity during a customer pitch, and sell their new “creation.” Then they blame you when you break the news to them that not only does this chimera product not exist (surprise, surprise), but the two legitimate products don’t play nicely with each other, and getting them to do so would cost several times more than they’ve sold the invented one for. That’s the product’s fault, they contend, so it should be the product manager’s problem to fix.
I’ll be the first to admit that sales makes an easy target for product managers and that deep down, we quite enjoy having a token bad guy to be exasperated by, particularly when we’re venting over a postwork beverage. Salespeople can drive you crazy, but just remember that in B2B companies they are primarily responsible for getting your product out there and that they have the stamina to do the hard selling that we would not enjoy. For every customer who says yes and buys, the salesperson has had to brazen out twenty or more rejections. Salespeople live by the sword and die by the sword, with generally low basic salaries and most of their income from commission. The system is set up for them to do everything they can to make deals.
So in working with them, put yourself in their shoes. Try to forgive them for being a little caught up in where their next commission check is coming from. Think about how you could demonstrate to them that their success rate will improve if they listen to what you’re saying. Work to understand their selling process and find ways to supply them with the product information they need, when they need it and in a form they can use more easily and quickly. I quite liked one enterprising product manager’s approach of having drink coasters printed with some product sound bites and leaving them on the telesales team’s desks. Another approach I’ve seen work well was to encourage an underperforming sales team to attend short (less than an hour) workshops with their peers and the product manager. When we opened up the challenges to the group, the more successful salespeople would share their tips because they loved to talk about their own successes, and the rest would be more likely to take advice from peers than from product managers.
It can be tempting to think that you can sell the product better than sales, so I recommend that you have a try. You may be shocked—selling is hard. Always keep that in mind when dealing with salespeople.
MANAGING UP
Until you’re running your own company, you’ll always be reporting up to someone. Unless, that is, you work for one of the few firms that have tossed out hierarchical management. Valve, the software company behind ridiculously successful game titles such as the Half-Life and Portal series, defies convention by having an entirely flat organizational structure, which will have you either reaching for your résumé or recoiling in horror at the apparent anarchy of it all. Valve’s employee handbook states:
Hierarchy is great for maintaining predictability and repeatability.… We want innovators, and that means maintaining an environment where they’ll flourish. That’s why Valve is flat. It’s our shorthand way of saying that we don’t have any management, and nobody “reports to” anybody else. We do have a founder/president, but even he isn’t your manager. This company is yours to steer—toward opportunities and away from risks. You have the power to green-light projects. You have the power to ship products.8
I think it’s safe to say that this style of management will take a long time to catch on widely, if it ever does. Most of us are going to have a higher-up, and if you’re lucky, that person will be someone who understands what your role is; leaves you to get on with it; supports you when you need support; occasionally runs interference for you; and diplomatically steps in from time to time in order to nudge you in the right direction, allowing you to fulfill your professional potential. If you’re really unlucky, you could end up with an incompetent cretin who’s only looking out for number one and whose very presence stifles team productivity and reduces morale. Your manager will sit somewhere along the spectrum between these two extremes, though hopefully toward the more supportive end. And bear in mind that those you must manage up to include other corporate higher-ups in addition to your immediate boss, such as the heads of sales and marketing and the CEO.
When dealing with higher-ups, always think about their needs and challenges; they’re probably time-poor and have several other concerns competing for their attention. Fundamentally, they need to understand from you whether you’re handling everything satisfactorily or whether they need to intervene. Consider the relative importance of your product in the context of everything else that’s going on. If your product accounts for 75 percent of all company revenue, and it has a problem that may adversely affect that revenue, it’s probably worth bringing the problem (and some ideas to solve it) to the attention of the management, starting with your boss. Highlighting how many bugs you fixed in the latest incremental update probably shouldn’t be treated as front-page news.
As you would when thinking about your user personas, assess how each of your higher-ups prefers to give and receive information and tailor your approach accordingly. Say the head of sales gives you a regular slot to present at the monthly sales meeting: Keep it brief and enthuse them. Always be clear and as definite as possible, but never be afraid to say you don’t know something. Just make certain you know the answer for next time. As many professional storytellers recommend, when presenting, show, don’t tell. Illustrate the point you’re trying to make as engagingly as you can, whether it’s by showing video excerpts from user tests highlighting the problem you need the funding to fix or by demonstrating a prototype that shows succinctly how you’ve successfully solved a problem in the product. When you’re finished, you may also wish to leave a summary or some further reading for people to review at their leisure. (I suggest not giving it to them at the start, as then they will be paying attention to it rather than you.) Enliven any hard statistics with infographics that make the point clear at a glance. Be sensitive to what Nobel Prize–winning economist and psychologist Daniel Kahneman calls cognitive ease (literally making text easier to read by improving its visual contrast). You always want to use the simplest, most direct visuals and language you can. Keep in mind a finding by UCLA professor Danny Oppenheimer that Kahneman writes about in his book Thinking, Fast and Slow. Oppenheimer found that using unnecessarily obscure or complex words actually reduces credibility and is considered a sign of low intelligence.
Despite the stereotypes, managers are rarely simpletons, but if they’re only going to give you their undivided attention for five minutes a month, make it memorable and easy for them to consume the information. You want to instill in them the sense that you’re in control and are a safe pair of hands. If you do so, you’ll become someone they’ll really listen to, and they’ll look forward to hearing from you, even if the news isn’t always good. After all, you never know when you might need to take advantage of their goodwill for a favor.
When I joined Experian in 2008, the routine in our business unit was that the product team had to request any significant budget needed to work on our products, and this request required a business case. And like the development estimates on which they were based, our business cases were typically wrong, regardless of how much effort we expended researching and creating them. There were simply too many assumptions and variable elements all stacked up on each other. Nevertheless, no business case meant no funding, so we knuckled down and did the best we could to predict the future. Our problem was that each business case took someone two to three weeks to pull together, yet most were rejected by senior management. This was a colossal waste of time for all concerned, so we attempted to improve the process.
What we came up with was a one-slide, five-minute pitch with the single goal of determining from the management team as quickly as possible whether it was worth devoting the time to a full-fledged business case. The pitch answered the following questions about the proposed product or feature: What is it? Who’s it for? And what’s it worth? We made no attempt to speculate how much the development would cost, as we didn’t yet know, and we’d cram three or four pitches, including taking questions, into each month’s time slot. The ideas were either shelved, given the go-ahead for a full-blown business case, or in some cases green-lighted for immediate delivery there and then. This approach had three effects: First, the “lightning pitch” aspect was lively and far more engaging. Our product pitches actually became a welcome diversion for the management from their normal agenda. Second, we saved lots of time by pushing for an early decision on whether to pursue or ditch each idea by weeding out the ones that would never have been approved. Third, we could use the time we saved to generate, research, and propose more ideas than before, allowing us to be more innovative.
MANAGING DOWN
If you’ve ever worked for a boss who was a micromanager or a seagull—one that swoops in unexpectedly, makes a whole bunch of noise, and craps on everybody—you’ll know the experience is not pleasant. Try very hard to avoid adopting these management styles. My own first attempt at line management was an abject failure. Very early in my working career at Zeus, the company was growing so rapidly that pretty much everyone was able to recruit an underling. Despite being just the guy responsible for the websites at the time, I somehow ended up with a direct report.
“Jenny” (to spare both our blushes) had been hired to help with the corporate website. The consultancy, training, and product teams were all churning out new content that needed to be pushed onto the website. In the absence of any real clue about how to manage people, I fell back on the closest analogue I had: the military approach of barking orders. Wrong, wrong, wrong. In addition to coming across as a complete douchebag, I’d fallen into the trap of thinking that Jenny would instantly understand the website, its information architecture, and our publishing processes and would automatically work in exactly the same way I did. It hadn’t occurred to me to give her sufficient time to settle in and understand what I needed her to do, and I was so unreasonably expecting such a high standard that her slow progress was bound to disappoint me.
This is decidedly not the way to manage someone. For starters, not only is barking orders a terrible approach in management, I’d forgotten that it’s a pretty awful approach in the military as well. Even if you have the authority to order people to do what you want, you’ll still achieve a better result if people choose to do what you suggest rather than being forced to do so. If people neither respect your authority nor agree with the request, there’s always scope for them to drag their heels; they will feel no incentive to go the extra mile and will likely be overly literal, complying only with the letter of the request, not the intent. As many wise people have observed, true leaders serve the people they’re responsible for and encourage them to fulfill their own potential. But don’t mistake this humility for passivity—a leader is no pushover. Good management requires both understanding and resolve.
An approach I’ve found instructive in becoming a more personable manager has been the concept of situational leadership, introduced by business experts Paul Hersey and Ken Blanchard.* As a manager, you need to figure out which stage of learning each of your team members is in and adapt your approach to managing them accordingly. Bear in mind that people might be at different stages for different tasks—someone may be absolutely fine running usability tests but may need coaching to become better at presenting.
Hersey and Blanchard’s theory holds that when you start a new job or acquire a new skill, you go through different stages of learning with different associated levels of enthusiasm and stress.
1. Unconscious incompetence: Also known as the Woohoo stage. At this point you’ll be saying to yourself, “Of course I can do this, I’ve done [insert completely unrelated activity here] before, so this can’t be that hard, right?” Enthusiasm will be high and stress will often manifest as “butterflies” in the stomach.
2. Conscious incompetence: Also known as the Ice-Cubes-Down-the-Back Wake-Up Call or the Trough of Realism, in which enthusiasm plummets and stress rockets. At this stage, you’re thinking that the job is a lot harder than you envisaged, you’re not entirely sure why you decided to do it in the first place, and you’re seriously considering handing back the scalpel/hazmat gear/riding crop and saying you’re probably not qualified to do the task. This is where you show your true colors—if you can knuckle down and persevere, you will start to improve. Don’t listen to the voices in your head telling you to give up.
3. Conscious competence: Also known as the I’m Getting the Hang of This stage. You’re beginning to master the new skill, the bruises are no longer showing, and the various lawsuits have died down. You still have to think about how to do the task right, but it’s getting easier every time, so your enthusiasm and stress levels are stabilizing.
4. Unconscious competence: Also known as the Look Ma, No Hands! stage—minimal stress, maximum enthusiasm. This is where you don’t really have to think about the task anymore; you feel how to do it, like a Zen master. You can slow down time and dodge bullets, but it’s still advisable to look where you’re going to avoid it becoming the Look Ma, No Teeth! stage.
You can be fairly directive in your approach with newbies, because they’re generally enthusiastic but have no clue what they’re doing (unconscious incompetence). You can just tell them what you want and how you want it, and doing so doesn’t take up too much of your time. But as they acquire a bit more competence, they hit the Trough of Realism and their commitment takes a big hit, so you need to devote more of your time to coaching them. This should involve a combination of telling them what you want and being more supportive to help them figure out how to do it for themselves. Then, as their confidence and competence improve, their enthusiasm will return, but it will still occasionally take a knock. So you should move into a mode of relying more on their judgment of what to do but still helping them when they get stuck. Be sure not to neglect these more competent team members. They can still require you to spend a reasonable chunk of your time providing support and reassurance. When they finally achieve mastery and their competence and commitment are both high, you can simply delegate work to them with the confidence that it will be done well, and the time you spend directly managing them will decrease.
Whatever happens, always have time for your team. If you have to work late because the needs of your team came first, so be it. The time, effort, and support you put into your team will more than pay for themselves.
ADAPTING YOUR APPROACH
The trick to adjusting your style lies in understanding the needs and the level of involvement in your product of each of the groups of people discussed in this chapter and adapting your approach to suit.
One way to think about this is to map out your product’s various stakeholders on a grid similar to the stakeholder map shown. You’re not trying to map out absolutely everyone here, just the main players. By meeting with each one, you’ll start to assess how influential and interested they are in your product, and whether they’re likely to be advocates, detractors, or on the fence. You’ll then need to devote more time and effort toward managing the people with more interest and influence, whether they’re supporters or critics. What may be surprising is that the more-senior managers in your organization may not all end up in the top-right quadrant. Your company’s board of directors, for example, would clearly be highly influential, but may not need frequent updates, so would probably sit in the top-left quadrant. However, you’ll need to manage more closely the board member to whom the product team ultimately reports, so that they can act as an advocate and supporter of your product on your behalf.
Plot the people involved with your product on a stakeholder map. (Image concept courtesy of General Assembly)
In contrast, the person running your technical support team is likely to be very interested in the progress of the product, but not necessarily directly influential on it, so would sit in the bottom-right block. However, if you’re beginning to notice that everyone in your organization seems to be both highly interested and influential, you’ll have your work cut out for you. That situation sounds suspiciously like design by committee, and you’ll have an immensely difficult job reaching consensus to move the product forward. An even bigger challenge will be to gently negotiate some of the stakeholders into positions of lesser influence, freeing you to assert more control over your product and make decisions more easily. This is where good communication can make all the difference.
BETTER COMMUNICATION
Right at the beginning of this chapter, I mentioned that poor communication is responsible for much dysfunction within organizations. If people aren’t exchanging information with each other well, how on earth can they expect to coordinate their efforts? With that in mind, it’s always a source of bewilderment to me that we rely so heavily on email to communicate. Emails taunt us in our inbox, begging for attention. They follow us on our mobile devices. There is no respite. Most importantly, they’re categorically not suited to all situations. So come a bit closer—I have some important advice for you: you can also talk to people.
As a general rule, product managers receive about four hundred to five hundred emails per week and respond to roughly half of them, which takes up about a third of their working lives. I bet a significant proportion of these emails could be avoided if the sender just picked up the phone or wandered across the office for a chat. Some people choose to hide behind emails as a way of avoiding unpleasant human interaction. If this is your view, I hate to be the one to point out that product managers are expected to speak to people occasionally; it comes with the territory. Emails aren’t just addictive, they can lead to inefficiency. According to one study, each time we allow one to interrupt us, it takes more than a minute for us to recover our train of thought.9 Dr. Tom Stafford notes in a 2008 article in The Guardian:
Both slot machines and email follow something called a “variable interval reinforcement schedule,” which has been established as the way to train in the strongest habits. This means that rather than reward an action every time it is performed, you reward it sometimes, but not in a predictable way. So with email, usually when I check it there is nothing interesting, but every so often there’s something wonderful—an invite out, or maybe some juicy gossip—and I get a reward.10
Similarly, Pulitzer Prize–winning journalist Charles Duhigg writes in his book, The Power of Habit:
When a computer chimes or a smartphone vibrates with a new message, the brain starts anticipating the momentary distraction that opening an email provides.… (On the other hand, if someone disables the buzzing—and, thus, removes the cue—people can work for hours without thinking to check their inboxes.)11
Here’s why I’d be overjoyed if product managers all broke the email habit.
Emails Elongate and Confuse Discussions
Have you ever seen news reporters trying to interview someone with a satellite delay? That can be pretty confusing with just two correspondents. How badly do you think a similar lag between question and response would affect a discussion among a group of people?
When I’m Annoyed, I Read Emails with the Angry Voice in My Head
The absence of any visual cues (body language, facial expressions, etc.) means that a perfectly innocent email can suddenly take on a completely unintended tone, perhaps pointed, dismissive, sarcastic, rude, or the like. I believe this is called projection.
Emails Can Easily Be Taken out of Context
You don’t actually know when someone is going to read your email, so sometimes the vital contextual link is lost in the intervening time between writing and reading. This doesn’t contribute to ease of understanding.
Despite Years of Practice, I Still Cannot Type Faster Than I Can Speak
Emails waste my time. Phoning or speaking to someone in person is generally quicker, easier, and more effective. This is also why I shun instant messaging and will continue to be a refusenik.
Some People Expect an Immediate Response to Emails
Someone sends an email. They assume the recipient will see and open the email immediately, and so when they do not receive an immediate reply, they also assume they’re being pointedly ignored. In reality, the recipient might just be doing something else.
Email Can Be Useful (Sometimes)
To be fair, email does have its uses. It’s great for forwarding documents or factual information (dictating a document over the phone would be insane) and broadcasting a message to a large number of people. Sometimes you’ll be conversing with someone whose first language is not English, and their written English may be better than their spoken English. And with some of your colleagues, both inside the company and out, it may be important to get communications in writing so you have a record. But generally, I recommend that if you can, go and speak to people. Get everyone in a room for fifteen minutes if you have to. You’ll not only conclude the discussion more quickly, but you’ll also get some lovely exercise by moving from your desk. And you’ll get the benefit of seeing how people feel about the topic as well as listening to their reactions. Of course, you have to be selective, otherwise you’ll end up in meetings all day. But failing to have face-to-face discussions leaves a great deal of potential communication unexpressed. Even a video call doesn’t give you all the visual cues you get from physical presence.
SAYING NO
Most product managers hate saying no. It’s not in our nature to disappoint people. We’d much rather give a nice, cooperative yes that makes everyone happy and leaves us feeling warm and fuzzy. The problem is that saying yes to everything creates manifest chaos. Whatever passed for a roadmap is effectively torn up and thrown out. You’ve made a commitment to deliver everyone’s requests, which is a practical impossibility because some of them are almost surely conflicting or baseless.
Your role as a product manager is first and foremost to guide and shape the success and growth of your product. Being responsible for a product’s strategy means that you have to make choices simply because attempting to do everything results in an unfocused mess. Just remember how companies succumb to “feature-rhea” because they think that more features equals more value. Product managers are duty bound to say no regularly, and what makes your response palatable here is the justification you offer. For parents, “Because I said so” may be an acceptable—or the only possible—retort, but it’s never a good response for a product manager. Expect to point out the things that would have to be jettisoned to accommodate some shiny new flourish and how much additional budget and time you would need. Don’t begrudge this approach; it’s usually very effective. Even if people initially go off in a huff, the practicalities will eventually sink in. Also, when you have to say no, do so firmly, politely, and unambiguously. You may have to repeat yourself nonetheless, but the firmer you are the better. If you leave the door open even a crack, some people will try to bludgeon right through it.
MIND YOUR MANNERS
My folks brought me up to remember my manners. I concede that as a Brit I may take this a little too far. I sometimes find myself apologizing to people who have just barged into me on the streets of London. But manners and humility are vital for a product manager. Always remember that your success relies on the help of many others, and any one of them might do a great deal to derail the product, and thereby derail you.
Think of all the things people do for you: developers and designers have to guess what you mean in your user stories (short descriptions of the product features you want them to build) because often some context has been left in your head, and YOU ARE NEVER AT YOUR DESK. Marketing has to understand all the cool new things your product does and find the people who’ll actually give a damn. The sales team has to penetrate all your product’s technobabble and marketing fluff to find the trigger that will part clients from their cash. Finance has to figure out how your clever multitiered pricing model works to ensure that they’re chasing the right clients for the right amounts and not breaking several impenetrable accounting rules. And tech support has to field calls from dozens of confused customers because a small but crucial feature has changed its behavior without any advance warning from you.
Product managers are by definition generalists across a broad spread of disciplines. It’s essential that we rely on the depth of our team members’ expertise; as much as we may know about sales, marketing, finance, user interface design, programming, or the latest technologies, we’re not the experts. We’ve got to find a delicate balance between delegating to people who know much more than we do about the details and keeping on top of what they’re doing and steering it. So be grateful for any help you receive from others. Thank them sincerely whenever you can, even if they’re “just” doing their job. You will always need to call on them again, because you can’t do your job without their help.