In Fairness…

I’ll end this section with a bonus characteristic. In fact, it’s the most important characteristic of a product manager — the one that rules them all. I once had a discussion with a colleague in our development team about the new product development process we had rolled out a few months before. One of the words he used to describe the new process is fair.

It was a passing comment and I didn’t really think much of it at the time, but since then I keep going back to that conversation, and the importance of fairness in the product management profession. All the characteristics I just talked about are great, but above all, fairness is the one that a PM simply cannot do without.

Let’s look at one definition of the word fair²³, and what it means in the context of product management:

fair. adjective. free from favoritism or self-interest or bias or deception.

Free from Favoritism

One of the fastest ways to become ineffective in a PM organization is to start playing favorites with a particular internal group, product line, or user base. As soon as people sense that you are not looking at all ideas and input equally and fairly, a lack of trust inevitably follows. And without trust, you’ll have to work a lot harder (and longer) to bring people along for the ride on your roadmap.

Free from Self-Interest

If you start doing things purely with reasons like “because I want to” or “because I’m being measured by this metric,” that same lack of trust grows very quickly. You cannot be effective by nursing your own pet projects and ignoring all the other needs around you.

Free from Bias

This often happens when PMs receive news they don’t want to hear, especially from the user research or analytics teams. If something doesn’t test well, don’t make up reasons why you are right and the users are wrong. Do the right thing and realign the design.

One of the hardest skills for a PM to learn is to take their own emotions and feelings out of the equation when it comes to decision-making. Yes, a lot of gut feeling goes into a product vision, but that cannot be based on personal preferences or preconceived ideas. This is much easier said than done, but something to strive for and be aware of at all times.

Free from Deception

This one seems obvious, but you see it often, especially when it comes to metrics and assessment. Don’t ignore or distort negative data, or make a problem someone else’s fault. The PM’s job is to own a product — and this means owning its successes and its failures. You’ll gain trust and respect if you not only claim the successes, but also acknowledge the failures and commit to do it better next time.

The PM role is often referred to as “the great diplomat,” and with good reason. It is our responsibility to balance a variety of needs from inside and outside the business, and somehow turn that into a roadmap that delivers business value as well as meets user needs. A focus on fairness accomplishes that goal.

•Fairness to users. Approach users with respect, openness, and transparency. Understand their needs, and explain to them when you’re doing something that makes it more difficult for them to meet those needs.

•Fairness to the business. Do everything you can to understand the needs of marketing, merchandising, customer support, and the rest. Pull them into the planning process, be clear about how projects are prioritized, and help them adjust to that process so they can define their project goals in the right way to get on the roadmap.

•Fairness to technology. Don’t force the development team to make the technology do things it’s not capable of doing. Understand the technical debt in the organization, and work actively to make those improvements part of regular development cycles.

A lot of this comes naturally in good product managers, but we need to be conscious of it every day. Fairness is a minimum required characteristic for an effective product manager. If you do it right, the real work of building great products can begin. But if you don’t, you’re dead in the water, working with a team that has no reason to trust that you’re doing the right thing.

Where Product Management Fits Into An Organization

Here’s some bad news. It doesn’t matter how well PMs fit the ideal characteristics of the role, if they’re sidelined in crucial discussions they just won’t be effective. So another common question about product management is where it should fit into an organizational hierarchy. PMs are often described as mini-CEOs of their products, which should give a good indication of the appropriate hierarchical level PMs require to operate effectively.

Product management cannot sit within the marketing or engineering organizations — which unfortunately sometimes happens because companies aren’t sure where to put it. To be effective, product management needs executive-level representation. In startups with one or two PMs, this means that they report directly to the CEO or COO. In larger organizations it means that the product management team is led by an executive-level person. In recent years, this has evolved into a new C-level role called the CPO (chief product officer).

The labels and job titles aren’t as important as what this implies, though — which is that the product management team collaborates with fellow decision-makers in the company. Hiding PMs within an organization with very specific goals and agendas (like marketing or operations) defeats the purpose of developing and executing a holistic product vision and strategy.

I don’t really like talking titles and hierarchy, so don’t misunderstand this as a personal agenda to elevate PMs to godlike status. Instead, as you’ll see throughout this book, PMs need to be at a decision-making level — whatever that is called in your company, and whether you have ten employees or ten thousand — in order to make the best possible products for the company and its users. That’s all there is to it.

A Prerequisite For Success

There’s one last topic we need to address before we get into the details of what PMs do day to day. An organization can hire the best product managers in the world, and implement the best development processes, but still fail if one non-negotiable prerequisite for success is not met. That prerequisite is this:

For product managers to succeed, there needs to be an executive mandate and company-wide understanding that even though everyone gets a voice, product decisions ultimately reside with product managers.

This is a hard one to swallow for many companies — and another reason why I just argued that PMs need to have executive-level representation. When I mention this part in product management training courses, the mood in the room often changes. This is where people start complaining that even though they see the value in the product manager role, it will never work at their company, because leaders aren’t willing to give up that ultimate control over the product. We’ll discuss strategies to deal with this throughout the book, but for now here’s a reminder of what Seth Godin reportedly once said: “Nothing is what happens when everyone has to agree.” The product manager is there to make sure things happen — the right things.

Executive teams and individual contributors have to buy into this role. If they don’t, product managers become impotent and frustrated bystanders to a process that continues to spiral out of control. And they’ll end up going somewhere they’re appreciated for the value they bring.

Coming Up Next…

In this chapter we covered a bunch of what might be considered soft issues in product management: what PMs are like, how they work with other people, what differentiates the good ones from the bad ones. It’s tempting to skim over these issues to get to the how — the processes and day-to-day activities that make up the PM role. But that would be a mistake. I haven’t seen a product development role that relies more on these kinds of soft skills for its success than that of the product manager. A PM can have the best strategy, and be brilliant at execution, but without the ability to work well with people and get them to rally around a common cause, they will fail. So if you’ve skipped over any of the sections in this chapter, now is a good time to go back and read them thoroughly!

Now that we have this foundation in place, it’s time to move on to how product managers spend their days. We’re going to break this into two sections: product planning (how to prepare for and prioritize product changes); and product execution (how to ship those changes).

—

1.“Product/Market Fit” – http://smashed.by/market-fit

2.Behind Every Great Product – http://smashed.by/product-manager

3.“Who Needs Product Management?” – http://smashed.by/pmanagement

4.“Managerial Representations of Competitive Advantage,” George S. Day and Prakash Nedungadi, Journal of Marketing 58 (April 1994): 40.

5.“Innovation Calls For I-Shaped People” – http://smashed.by/ishape

6.A loose English paraphrase of Antoine de Saint Exupéry’s French poem Dessine-moi un bateau (Make me a boat), found in Citadelle (1948) – http://smashed.by/makemeaboat

7.“New MailChimp: Collaboration by Design” – http://smashed.by/collaborationbydesign

8.Isaacson, Walter: Steve Jobs.

9.“The Process Myth” – http://smashed.by/process-myth

10.Politics, Philosophy, Culture: Interviews and Other Writings, 1977–1984, Michel Foucault. (http://smashed.by/foucault)

11.“Moving from Critical Review to Critique” – http://smashed.by/critical-review

12.“How to give and receive criticism” – http://smashed.by/berkun

13.Crucial Conversations: Tools for Talking When Stakes Are High, Kerry Patterson, Joseph Grenny, Ron McMillan and Al Switzler. (http://smashed.by/amzn-1)

14.“Better together; the practice of successful creative collaboration” – http://smashed.by/better-together

15.“Why Design-By-Committee Should Die” – http://smashed.by/design-committees

16.Undercover User Experience Design, Cennydd Bowles and James Box. (http://undercoverux.com/)

17.“Curiosity Required” – http://smashed.by/curiosity

18.“Design like you’re right…” – http://smashed.by/you-right

19.Design Is A Job – http://smashed.by/design-job

20.“Schlep Blindness” – http://www.paulgraham.com/schlep.html

21.“Technology Is Useless If It Doesn't Address A Human Need” – http://smashed.by/useless-tech

22.Wicked Problems: Problems Worth Solving – https://www.wickedproblems.com/

23.Definition of fair by the Free Online Dictionary, Thesaurus and Encyclopedia – http://www.thefreedictionary.com/fair

Chapter 2 Uncovering Needs

“If I had asked people what they wanted, they would have said faster horses.” Far too often, we hear those words (supposedly spoken by Henry Ford) as a way to justify rushing headlong into executing a so-called innovation before the idea is tested with users. It’s worth noting that not only did Henry Ford probably never speak those words, it also turns out that kind of thinking resulted in “a catastrophic loss of market share from which [Ford] never recovered¹.”

The lesson we should take from this story is that it’s extremely dangerous to execute ideas without first identifying and testing assumptions about the value of those ideas. We shouldn’t jump to a solution before we understand the problem. And that’s what this section of the book is about.

I’ve already alluded to the two main elements of product management that we’re going to discuss: product planning, and product execution. It’s now time to expand on the product planning part. Below is a diagram of the framework we’ll use to discuss the planning activities PMs are responsible for.

The primary steps of the product planning process, from identifying needs to developing a strategic and flexible roadmap

We’ll start by looking at the different inputs into the product development process. The starting point is — always — needs. Not what we assume would be cool, but what users or the business need to be successful. Different inputs into this process include:

•User needs. The PM must have a good understanding of the market, the company’s customers (existing and potential), and their behaviors and attitudes. PMs should never be caught off guard by questions about the product’s target audience. We’ll look at different sources of user input, including market research, user experience research, site analytics, and customer support.

•Business needs. The “putting users first” mantra too often neglects the fact that a product exists to make money. Having revenue goals is not an excuse for bad design, though, so we’ll look at the difference between bad revenue streams and good revenue streams.

•Technical needs. Development needs get ignored much of the time in favor of the more tangible front-end and business requirements. Developers know the limitations of the product; they know what needs to be fixed, and they know what technical debt needs to be paid. We’ll discuss the mechanics of the all-important relationship between developers and PMs.

All these different needs feed into a process called product discovery. Once again, there are different definitions of this process, but I use the term here to refer to:

Defining the problem you are trying to solve for users, the business opportunities that exist to solve the problems, and the core competencies that will help you make the solution a success.

The outputs of the product discovery process can vary — just like how long it takes can vary between anything from two to three hours to several weeks. In general, the product discovery process for larger projects produces outcomes like problem frame diagrams, personas, and customer journey maps — all of which we’ll discuss in detail. These artifacts feed into the strategic product plan: a document that summarizes what the product is about, who it’s for, and the plan to make it a success.

Once the strategy is set, the PM leads a process of idea generation (coming up with lots of different approaches to solve a problem) and iteration (quickly narrowing down those ideas to the best ones). This is followed by customer validation (testing ideas with target users) as part of a larger process to prioritize which ideas are worth pursuing. All these activities feed into the mighty product roadmap. There’s quite a bit of controversy around the value and legitimacy of roadmaps, so we’ll discuss that in detail (hint: it’s not all bad).

Once the strategic product plan and the initial roadmap are in place, execution can start. Right now you’re probably tempted to skip this section and jump straight to execution, but don’t do it! One of the biggest dangers of product development is jumping to execution before an appropriate planning cycle has been completed, so we need to give planning the attention it deserves.

Let’s start with gathering user needs.

User Needs

The first thing we need to clarify is the difference between needs and features. We often make the mistake of equating product features with user needs. If you’ve ever used a household appliance you’ll know that this isn’t the case. Have you ever used more than one or two of the preset cycles on your washing machine? And how many different ways do you need to toast your bread? The evolution of household appliances is a perfect example of what happens when features are equated with value. We don’t need more ways to wash our clothes. We might need faster or quieter ways, sure. But as we know, more isn’t necessarily better. And that’s when users sometimes take matters into their own hands.

Source: Reddit “My buddy dad-proofing his remotes²”

When the first reviews and usage statistics for Facebook Home³ started appearing, John Gruber used a phrase that stuck with me⁴: “It’s a well-designed implementation of an idea no one wants.” Hyperbole aside, this is what happens when features (cover feed, friends filling the screen, chat heads, app launcher…) are mistaken for user needs (why would people want to replace their phone’s operating system with an app?). The distinction between features and needs is important, and sometimes difficult to spot. That’s where user research comes in.

Research methods for gathering user needs are powerful because they rely more on observation and deduction than gathering answers to a bunch of predetermined questions. But before we get into the different methods we can use to make better products, we need to take a little detour to define some basic research terms.

First, we need to distinguish between quantitative research and qualitative research. With quantitative approaches, data tends to be collected indirectly from respondents, through methods like surveys and web analytics. Quantitative research allows you to understand what is happening, or how much of it is happening. With qualitative approaches, data is collected directly from participants in the form of interviews or usability tests. Qualitative research helps you understand how or why certain behaviors occur.

We also need to make a distinction between market research and user research. Both are important, but they serve different purposes. Market research seeks to understand the needs of a market in general. It is concerned with things like brand equity and market positioning. Attitudinal surveys and focus groups are the bread-and-butter tools for market researchers. They are tasked to figure out how to position a product in the market. Surveys and focus groups are very useful to understand market trends and needs, but they won’t help you very much when it comes to the design of your product.

User research, on the other hand, focuses on users’ interactions with a product. It is concerned with how people interact with technology, and what we can learn from their wants, needs, and frustrations. Those are the methods we’ll focus on in this section.

So, with those definitions under our belts, let’s look at some of the most common user research methods available to us. We can generally classify methods in three different buckets.⁵