Product Management in Practice

Introduction

Why I Wrote This Book: My First Day as a Product Manager

I never felt more prepared for anything than I did for my first day as a product manager. Ever the eager student, I had made a point of reading up on the basic tenets of user experience, sharpening my programming skills, and learning about product development processes like Scrum and XP. I could recite the Agile Manifesto by heart, and knew about the industry-standard bounce rates for comparable web properties. After settling in at my new workstation, I approached my boss—who was not a product manager himself but had worked with enough of them to know the type—with the overconfident swagger of a young person who had read a lot of books very quickly.

“I’m so excited to really dig into this work,” I told him. “Where’s the latest version of the product roadmap? What are our quarterly goals and KPIs? And who should I be talking to if I want to better understand the needs of our users?”

He gave me a weary look and took a deep breath. “You’re smart,” he said, “Figure it out.”

Aside from a very generous assessment of my intelligence at the time, my boss gave me the greatest gift a new product manager can receive: a grim but resolute understanding that guidance would be very, very hard to come by. For all the books that I had read and all the methodologies that I had studied, the only thing I was left with when I sat back down at my desk was, “What the hell am I supposed to do every day?” If there was no roadmap, how was I supposed to manage the roadmap? If there was no product development process, how was I supposed to oversee the product development process?

Early on in my career, I chalked much of this up to the fast pace and loose job definitions that come with working at a startup. But as I began to do more consulting and training work at organizations of different sizes and types, similar patterns began to present themselves. Even in highly process-driven enterprise organizations, much of the actual work of product management seemed to be taking place on the margins and in the shadows. Product ideas were being hashed out over coffee breaks, not planning meetings. Highly prescriptive scaled Agile frameworks were being bypassed by savvy politicking. Subterfuge, backchannels, and influence reigned supreme. And those same questions I had asked myself on my first day as a product manager were still being asked by product managers at organizations large and small, at cutting-edge technology startups and slow-moving enterprises, by new and experienced product managers alike.

Product management in practice is very different from product management in theory. In theory, product management is about building products that people love. In practice, product management often means fighting for incremental improvements on products that are facing much more fundamental challenges. In theory, product management is about triangulating business goals with user needs. In practice, product management often means pushing relentlessly to get any kind of clarity about what business “goals” really are. In theory, product management is a masterfully played game of chess. In practice, product management often feels like a hundred simultaneous games of checkers.

To that end, this book is not a step-by-step guide to building great products, nor is it a list of frameworks and technical concepts guaranteed to bring you Product Management Success™. This book is intended to help you through the challenges that no tool, framework, or “best practice” can prepare you for. This book is about the day-to-day practice of product management with all its ambiguity, contradictions, and grudging compromises. Simply put, this is the book that I wish I had on my first day as a product manager, and many, many days thereafter.

Who This Book Is For

Product management is the glue of modern organizations—the role that connects user needs with business goals, technical viability with user experience, and vision with execution. The connective nature of product management means that the role will look very different depending on the people, perspectives, and roles that you are connecting.

To that end, even defining what is and is not “product management” can prove infuriatingly nonlinear. For the purposes of this book, “product management” refers to the entire nexus of product and product-adjacent connective roles—which might be “product manager,” “product owner,” “program manager,” “project manager,” or even “business analyst,” depending on where you work. For some organizations, a “product manager” is the person responsible for defining a product’s strategic vision, whereas a “product owner” oversees day-to-day tactics. For some organizations, the exact opposite is true. I worked with one organization in which a team of “business analysts” woke up to find themselves magically transformed into “product managers” by executive fiat, with no clear sense of how their day-to-day responsibilities had changed, or why.

Titles, like software tools and product development methodologies, are one way to provide some kind of structure and certainty to a role that offers precious little of either. Successful product management is much less a question of titles, tools, or processes than it is of practice. I use this word the same way one might refer to a yoga practice or a meditation practice—it is something that is built up with time and experience, and cannot be learned from frameworks and instructions alone.

This book is for anybody who wants to develop their practice of product management. That could be somebody with a “product manager” or “product owner” or “program manager” title. It could be a startup founder struggling to connect the fast-moving pieces of their fledgling company. It could be a software developer who is feeling isolated from the user-facing impact of their work. Long story short, if you are in a role in which you are making connections between and across people and roles, I think and hope that there will be something for you in this book.

How This Book Is Organized

Each chapter of this book is organized around a particular theme, but these themes necessarily blur and blend into one another. Some of the concepts introduced in the first chapters of this book are referenced in later chapters, and some of the ideas explored at length in the later chapters of this book are set up toward the beginning. To get the most out of this book, I’d recommend treating it more like a novel and less like a reference. In practice, product management often feels more like a series of interrelated novellas than it does a neatly organized textbook.

Note that this book does not get into great detail about any particular roadmapping tools, Agile software development methodologies, or product life cycle frameworks. There is no shortage of very useful information out there about choosing a platform for bug tracking, a development methodology for product teams at medium-sized startups, or a framework for estimating user stories. The goal of this book is not to address the specific tools you might choose in your product management practice, but rather how to set up your product management practice to get the most out of any tools you choose to use.

For simplicity’s sake, I have described the people for whom you are building products as “users,” not “customers.” Not every product is paid for directly by the people who use it, but every product is used by someone or something. In some cases, such as enterprise B2B software sales, you might have a “customer” who is different from your “user,” and you can find yourself having to understand and connect the needs of both. If you’re interested in reading more about this distinction and the ramifications it can have on product design, I would recommend checking out Blair Reeves’s article “Product Management for the Enterprise”.

Also note that this book is not intended to be a high-level introductory glossary of product management terminology. If you encounter an idea, a concept, or an acronym that is new to you, take a moment to look it up.

Stories from Working Product Managers

There’s often a knowing, conspiratorial tone to conversations shared between working product managers—like we’re all in on the same secret. That secret, for those of you who are wondering, is that our job is widely misunderstood and really, really, really hard. Product managers are much more likely to share “war stories” than “best practices,” and are more likely to talk about the mistakes they’ve made than the meteoric successes they’ve achieved.

In the hopes of bringing this kind of conversation to people who might benefit from it, I have included stories from working product managers in this book. Most of these stories started with the question, “What is one story from your work that you wish somebody had told you on your first day as a product manager?” As you will see, most of these stories are about people, not frameworks, tools, and methodologies. Several of the product managers I spoke to provided multiple stories which, taken together, paint a more comprehensive picture of the distinct-but-related challenges a product manager is likely to encounter over the course of their career.

Some of these stories are directly attributed to the folks who told them, some are anonymized, and some are composited from multiple sources. But they all represent the messy, complex realities of product management in the field. I have learned—and continue to learn—a lot from these stories, and I hope that you will, too.

Templates

Throughout this book, I have included templates that you are welcome to adapt and customize for the specific needs of your role, team, and organization. I am a big believer in templates, especially for managing contentious issues like organizational process changes and “emergency” feature requests. Templates codify organizational goals and values into an impartial set of prompts and questions, and have immense power to depersonalize emotionally charged disagreements. When used consistently and transparently, templates become an immensely useful organizational mediator.

To get the most out of these templates, I would suggest that you begin by using them to structure your own ideas and suggestions, and then requesting that others follow suit. Templates can be a critical instrument of rigor and discipline—but only if you are willing to subject yourself to that same rigor and discipline.

“Your Checklist”

Every chapter of this book ends with an actionable to-do list called “Your Checklist.” Product management can be heady and abstract stuff, and my primary goal with this book is for it to prove useful to working product managers. Each item on “Your Checklist” serves as an action-oriented summary of an idea that was explored at more length within that chapter.

O’Reilly Safari

Note

Safari (formerly Safari Books Online) is a membership-based training and reference platform for enterprise, government, educators, and individuals.

Members have access to thousands of books, training videos, Learning Paths, interactive tutorials, and curated playlists from over 250 publishers, including O’Reilly Media, Harvard Business Review, Prentice Hall Professional, Addison-Wesley Professional, Microsoft Press, Sams, Que, Peachpit Press, Adobe, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, and Course Technology, among others.

For more information, please visit http://oreilly.com/safari.

How to Contact Us

Please address comments and questions concerning this book to the publisher:

• O’Reilly Media, Inc.
• 1005 Gravenstein Highway North
• Sebastopol, CA 95472
• 800-998-9938 (in the United States or Canada)
• 707-829-0515 (international or local)
• 707-829-0104 (fax)

We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at http://bit.ly/product-management-in-practice.

To comment or ask technical questions about this book, send email to [e-mail].

For more information about our books, courses, conferences, and news, see our website at http://www.oreilly.com.

Find us on Facebook: http://facebook.com/oreilly

Follow us on Twitter: http://twitter.com/oreillymedia

Watch us on YouTube: http://www.youtube.com/oreillymedia

Acknowledgments

Thanks to Mary Treseler, Angela Rufino, Laurel Ruma, Meg Foley, and everybody at O’Reilly Media for turning a pitch about a “very voicey and opinionated book about product management” into a real thing.

Thanks to everybody who provided both formal and informal feedback along the way.

Thanks to Roger Magoulas for bringing me into the fold.

Thanks to every product manager who shared their stories with me. And, special thanks to those who helped me streamline the process of gathering these stories. (Product managers, amirite?)

Thanks to everybody whom I have had the pleasure of working with through the ups, downs, and literal and figurative tears of my own product management career. Your patience and generosity will always mean the world to me.

Thanks to Josh Wexler for the best coffee meetings ever.

Thanks to Andy Weissman for taking a chance on me way back when.

Thanks to Sarah Milstein for getting this all started.

Thanks to Jodi Leo for an exceptionally well-timed gift of encouragement.

Thanks to Tricia Wang and Sunny Bates for showing me the power of true partnership.

Thanks to mom for not obfuscating the message.

Thanks to dad for a grudging but unshakeable love of learning.

Thanks to Joan for everything, every day.