Product Management is not a magical talent — it’s a Craft

I’ve been a product manager for over 20 years, although during most of that time it wasn’t called Product Management. Today the role of Product Manager is as ubiquitous as that of Engineer. It is also almost universally misunderstood, even by many who practice it. Some see it as a kind of technical project manager, others as a brilliant creative innovator of the next great idea (the myth of Steve Jobs has done a lot to perpetuate this). Still others see Product Management at the intersection of technology, design, and marketing.

None of these ideas are completely wrong per se, with the exception perhaps of the Steve Jobs myth, but they both oversimplify and make abstract what are a concrete and definitive set of skills — skills that can be taught and assessed. Skills that, when learned, practiced and perfected, constitute a craft, like that of a master carpenter (a carpenter who has mastered the many sub-skills and specialties of carpentry).

For those Product Managers who understand the craft, the ignorance that so often surrounds them, especially in start-up culture, can be at a minimum frustrating, and at worst harmful:

• Harmful to the PM because she isn’t getting the coaching she needs to grow;
• harmful to the company because a lack of good product management means a lack of data-informed decision-making, resulting in poorly executed software;
• harmful to users, who find themselves on the receiving end of seemingly random and nonsensical product changes that fail to address their needs.

Crazy People Don’t Know They’re Crazy

One of the biggest challenges this problem poses is that those who don’t understand product management are seldom aware of this blind spot. As an example, recently I had a start-up founder who self-identifies as a “product guy” say to me he didn’t see the value in instrumenting features or defining metrics to measure success and drive iterations because he “just knew what to do next.” A roadmap to him was a list of the features he wanted to implement. User experience research, market analysis or customer service logs he viewed as a waste of time and money. He just knew.

It was at this same company that during my day long interview process I wasn’t asked a single product related question. “We prefer to conduct interviews like conversations,” they said, “so we can really get to know the person, at a genuine, authentic level.” That’s cool. I get it. But I need to hire whip-smart contributors and managers from whom I can learn. People who clearly know how to do their job better than I know how to do mine. Folks who are passionate about what they do and do it exceptionally well. And the only way I can assess this is to learn as much as I can about their skills and expertise: their cognitive ability, communication skills, capacity for listening and learning, their personal motivation, how they lead and motivate teams, their values and the methods they employ to find answers to tough questions. I certainly don’t expect them to know the answer to my current set of challenges, and if they claim to know the answer they are likely demonstrating the kind of arrogance and ego-driven lack of self-awareness I try to avoid.

Bend to your Environment, or it will Break You

I’d like to stress that the ideas here don’t represent the processes, values or philosophies of any of my past employers. These thoughts do not represent the Google way of Product Management, nor are they based on something I read in a book. Although my opinions are of course heavily informed by my experiences (both good and bad), and by what I learned working at Google and other companies, this piece is mostly a compendium of the various approaches I’ve taken that have consistently yielded the best results. In actuality, I’ve read few business books and even fewer on product management. If I had, perhaps I would have saved myself a lot of painful failures, but ultimately the painful failures have been the most valuable of learning experiences.

But even if I had wanted to, I couldn’t have gone about things any other way. I’m a textbook autodidact. I learn by doing and have an innate distrust of the status quo and the figures of authority who defend it. I question everything, and in so doing I often catch myself talking too much in an attempt to elicit, through dialogue and debate, the underlying truth hidden behind the veneer of superficial posturing.

Mostly I’ve learned the craft from the teams I’ve worked with, and primarily from those who work “for me.” Oddly, with a couple of key exceptions, I’ve learned surprisingly little from my managers. Mostly because my managers have been, more often than not, ego-driven deciders, not PMs. Career managers who have lost touch with the craft, or never knew it. Managers who have hidden behind a false corporate persona for so long the mere notion of authenticity has become an alien concept.

This experience is likely why my leadership style has evolved into what is often described as “bottoms up.” I put trust in my teams and try to build an authentic culture of constant learning and feedback. A culture that celebrates individuality and neuro-diversity. I see myself as both a teacher and a student. I believe people perform best when they are confident, focused, devoid of fear and self-doubt, are aware of their biases and the biases of others, and practice non-attachment to ideas, especially their own. Which is to say they are neither fear nor ego driven, caring only and obsessively in delighting users and achieving their goals through product excellence.

Air Cover

As a product leader, my job is to articulate a vision, set clear goals, contribute to the strategy for achieving them, empower my teams and provide them with the guidance and support they need to do their best work. This means spending a lot of time with other teams, sharing our plans, soliciting feedback, and most importantly, defending my team’s agenda from the potentially debilitating effect of outside influence and leadership “asks.”

This involves establishing solid cross-functional relationships and earning the trust to effectively negotiate on behalf of my team. Negotiations that often take the form of “we can’t build this for you this quarter, but how about we have a shared goal next quarter to get this done together. By the way, how many engineers did you say you could commit to the project?”

The main purpose of this dance is to shield my team from encroaching armies. Not only must I protect them from going to battle, I also need to shield them from knowing that the battle even occurred. It sounds a little duplicitous, and keeping people in the dark doesn’t come naturally to me, but it’s better to be kept in the dark then to be distracted and anxious.

Invariably, if my team isn’t performing to their full potential, it is because I haven’t established the air cover required for them to do so, or created a safe and comfortable environment for them to be themselves. They need to trust me, but more importantly, they need to know that I trust them.

One Size Does Not Fit All

It’s also worth noting that while my basic principles have remained constant, what worked well last time invariably doesn’t work as expected the next time around. So, I am continually evolving my approach based on the unique characteristics of the current environment. The size of the company, the culture, background and biases of the founders, the strength of the existing PM culture, the skills and motivation level of the engineers, and the maturity of the product, all play a part in shaping the nuances of what I am describing.

Intellectual Transparency

When a strategy begins to take shape, I share my thinking early and often, soliciting feedback and points of view from as many people as possible, irrespective of their seniority. In the end, the strategy is a collective one. Nothing has a bigger impact on moral and productivity than a shared sense of ownership and a clear mission. Engineers no longer feel like they’re working on random features. They are implementing a plan they helped to shape. A plan they genuinely believe in.

What is Product Management?

The best place to start in defining the craft of product management is first to dispel a few widely held misconceptions. While vision plays an important part in product management, it is not primarily a visionary role. In many cases vision comes from the CEO (or it should).

Above all else PMs are computer and social scientists. Product Management is about orchestration, communication, and leadership. It’s not about having the answer; it’s about knowing (or, more often, figuring out) how to best go about finding the answer.

To establish credibility a PM’s every decision and point of view must be data informed. Which is not to say that PMs shouldn’t use instinct and creativity to form a hypothesis — they should, but their time shouldn’t be spent pondering the next big thing or how to disrupt X. It doesn’t work that way. Disrupting X is a by-product of focusing one’s attention on quantifiable problem sets and customer pain points. Most importantly one must go about validating one’s instincts with humility and detachment, a well-articulated user journey to humanize the use case and make it clear to all stakeholders, and metrics based success criteria to measure progress and improve upon it through rapid iteration. User Experience Research (UXR) plays a pivotal role in each of these, so there needs to be a tight partnership between UXR and Product. It’s equally important that Product understands the importance of, and how to best utilize their expertise.

You’re Not Steve Jobs

Every PM has heard the quote, “If Henry Ford had asked the people what they wanted next they would have said a faster horse.” Although Mr. Ford never said this, the meaning of the quote is clear. People don’t know what they want until you give it to them, and if you make your decisions based on customer feedback, you’ll never come up with the iPad.

This misconception is a by-product of modern start-up culture and it misses the point entirely. Ideas and solutions come from the minds of creative and problem focused people. But it is foolish to think that one’s hypothesis will work without first taking the time to validate it outside the often reality distorting confines of the office. That would be analogous to theoretical physicists foregoing experiments and proclaiming their theories as facts just because the math works out on their whiteboard. Why build the Hadron Collider when one is positive their theory is sound? Sounds crazy doesn’t it? And not at all scientific. But this is often the norm in tech companies and why one so often hears engineers and PMs complaining that “we’re doing too much” and “we’re spread too thin.” It’s also why countless hours are wasted at the executive level arguing about the validity of this idea or that. Guess what? It doesn’t matter what you think. All that matters is what your users think. So why not ask them?

Velocity is Not Measured by shipping Frequency

Another side effect of this non-scientific approach to computer science is that all too often costly engineering hours are spent building nonviable Minimum Viable Products because they believe the hip thing to do is ship quickly and “fail fast.” What they fail to recognize (pun intended) is that one can fail fast before a single line of code is written.

A more detailed and well researched product brief will result in fewer projects getting staffed, which will reduce the roadmap and allow for more wood behind fewer arrows. I’ve found that even in the process of writing a good brief, a PM may see the issues and kill the project before it even gets started. In the end, a company’s velocity should be measured not by the amount of software it ships, but by its ability to reach and exceed company goals.

So what are the skills a PM needs to learn? There are essentially 5 pillars to product management:

• Evidence-based decision making;
• Communications;
• Operational & product excellence;
• Influence & leadership
• Innovation

Innovation != Invention

The nature of innovation is widely misunderstood. Innovation is rarely pure invention. Usually, it is a better iteration of what has come before it. Let’s not forget that Apple didn’t invent the MP3 player or the smartphone. They didn’t even invent the mouse or the windowing UI. David Bowie didn’t invent glam rock. Google didn’t do the first web search engine, and Elon Musk didn’t invent the electric car. In all of these cases (and there are countless others), they took something that already existed, and did it better.

This is what product excellence is all about. A great product is the sum of all its little, seemingly unimportant or trivial details. There is nothing I dislike more than someone saying, “let’s just ship it. It’s just a little thing that no one will notice.” Bullshit. They may not be able to pinpoint the flaw, but it just won’t feel right. Details. Fit and finish. Don’t ship it until it’s fucking awesome. It doesn’t need to be perfect, but it must be great. And greatness is the sum of countless elegant and beautiful details.

Ok, so what is innovation if not pure invention? Innovation is about leveraging your unique assets and strengths to solve a problem in a new and novel way.

To achieve this stop thinking about features and start thinking about problems. You may even go so far as to erase your laundry list feature roadmap and just list out the three or four biggest problems that face your users. Now think of how your company, and only your company could solve those problems. Make big bets. Stop obsessively reading your competitor’s release notes and start thinking about how you can solve the problem, but in a different way.

Here’s an example: let’s say you’re in the e-commerce space and you keep losing deals because your competitor has a more feature complete point of sale system. Don’t play whack a mole by filling feature gaps. Take a step back and think about today’s technology, what’s possible and where the puck is inevitably heading. The answer is right there: Low energy Bluetooth and NFC enabled, location-aware mobile devices plus beacons and geofencing means frictionless payments. Don’t make a better POS. Make the POS entirely obsolete. Congrats, you’ve just made shopping suck a whole lot less. No lines, no cash registers, no swipes. Not even any taps. Just walk in, grab your stuff and leave.

That’s one example of a potential innovation that would make people’s lives better and put your competitors out of business and your customers competitors out of business. All that, and not one new invention. Just taking what’s already there and applying it to a problem with a dash of ingenuity.

Product Excellence & the Leadership Trifecta

Product excellence requires in equal parts a deep understanding of user need and company values, graceful and intuitive user experience, and top quality, high-velocity engineering. An organization that is weak in any of these areas, or favors one over the other, will ultimately fail to realize the full potential of their mission. Without good product management, goals and the means of measuring and achieving them will be poorly defined. Ineffective engineering teams will be plagued by inertia and a lack of motivation, and without great UX, there is nothing to hold it all together and guide the user through an intuitive and delightful experience.

The strongest teams I’ve worked with have all had this in common: adequately staffed and outstanding UX, engineering and PM teams. What’s more, leadership and authority were equally shared among these disciplines. They weren’t engineering, UX or product led organizations, they were genuine functional partnerships, where each discipline highly respected the value that the others brought to the table.

Personally, I aspire to lead and empower teams built around this trifecta principle and work to foster a culture of mutual respect, deferment, and humility among these disciplines.

My pursuit of this goal has profoundly influenced my management style, as it has required a “bottoms up” leadership approach that includes sharing work early and often to solicit feedback from a wide array of perspectives, providing team-level autonomy with a focus on the goals rather than the means of achieving them, practicing non-attachment to my own ideas and striving to coach others to do the same.

When discussing this approach or philosophy, the most common critique I hear is that every team needs one person to be ultimately held accountable. In principle, I agree, but have found that this happens organically depending on the project. Inversely, an overemphasis on singleton accountability runs counter to fostering a high achieving team that functions in lock step as a genuine partnership. If there is an engineering issue, the eng lead is held accountable. If there is an issue with product / market fit, Product is held responsible, and if the user experience is sub-optimal, it’s the responsibility of UX to fix it.

This approach directly addresses the schisms and dysfunction that plague so many tech companies. Some of the most common include:

• Engineering isn’t being brought into the product discussions early enough.
• Product lacks discipline and is wasting valuable engineering resources by pursuing every idea they think of without doing the legwork to validate it first
• UXD is being treated as a second-class citizen, coloring by numbers under the direction of pixel focused product managers
• UXR isn’t valued or understood, yet plays perhaps the most important role in ensuring that early ideas are validated before resources are put to work.

Basic Team Structure

While there are nuanced variations to this generalization, most software companies have two types of product teams:

Feature teams — These are the teams tasked with adding and maintaining end user facing features.

System or Platform Teams — These folks work on the core plumbing of the system, including data pipelines, and the APIs and SDKs used by the feature teams to build user-facing products. Their primary mission is to provide the functionality and tools to enable the feature teams to quickly build scalable, highly performant and easily localized features.

In my opinion, the fundamental unit of a feature team should consist of the following:

• PM Lead
• Tech Lead
• UXD Lead
• 2–10 engineers

A systems team likely doesn’t have the need for UXD, but their requirements and priorities are often informed by the needs of UXD. They do however need a technically adept PM to help with prioritization and orchestrate requirements from various constituents.

Team Leads

While one should endeavor to create a culture of partnership and shared accountability among the UX, eng and PM disciplines, each project needs a named leader. This will happen organically, given the following assumptions

• Customer and buyer facing features will more than likely have a PM leader
• Core and systems projects that are entirely technical in nature and do not have a front end will in most cases be led by an eng lead
• Design-centric projects, such as UX system creation or UX system-level redesigns will be championed by the UX lead

QA

Automated and unit testing should be core to engineering efforts, but QA itself is ultimately the responsibility of the PM. I have not had good results with dedicated QA engineers or teams. In my experience engineers become sloppy, knowing that another team is responsible for bugs, and PMs fail to test their own products since it’s “someone else’s job.” Removing the QA function in my experience results in a higher quality of software and greatly reduces inadvertent regressions.

UXR

A UX researcher may work with a handful of feature teams. They work closely with PM to conduct early market research and help to quickly validate an initial hypothesis or idea. In addition they stick around through a product’s lifecycle, helping to test ideas for improvement.

The basic goal of the PM/UXR partnership is to ensure that you are focusing your people on the projects that further the goals of the company. If velocity is measured by how quickly you achieve your company goals and not by how much software you ship, then the various types of research and user studies employed by UXR/PM don’t slow you down, they speed things up by reducing the number of doomed projects before they even get started. In doing so they free up more people to work on the projects that have the biggest impact, and to ensure that the roadmap is prioritized with low-effort / high-value projects at the top, and high-effort / medium-value projects further down the list.

Further, folks often lose sight of the compounding effect of each new feature. Systems grow more complex, impacting productivity and increasing the likelihood of introducing new bugs and functional regressions. And each new feature needs to be maintained, impeding team and individual mobility, often resulting in decreased moral and professional dissatisfaction. New features have a cost, and new features are forever, so it behooves a team to ensure that each feature released delivers more lifetime value than its lifetime cost.

Data & Analytics

The Data & Analytics team plays a critical role in both results measurement and helping to harness the corpus of data to deliver innovative new features.

Like UXR, the data team functions like an internal agency with multiple internal clients.

The data team partners with Product early to help define feature success criteria and consults with the engineering team about how to instrument the feature to best capture this data. To make this data useful, they provide the tools and support to the PM leads to build dashboards to visualize and monitor key performance indicators.

Technical Program Managers

The purpose of this role is often confused with product management, but in actuality, it is quite different. As systems grow more complex so do their dependencies. Good TPMs serve product teams by ensuring the right sequencing of events, optimizing for quality, efficiency, and speed. They have a thorough understanding of the big picture. They know when requirements need to be completed, how work should be sequenced given intricate dependencies, when design docs and UX specifications need to be finalized, when and if legal, marketing and PR needs to be involved. Their job is release management, and they are the masters of operational excellence.

Product Lifecycle Summary

Each quarter the product teams should endeavor to create or re-evaluate the company’s priorities and goals, reprioritizing or updating their current roadmap to increase velocity towards reaching company goals.

Velocity should be measured not by the number of features shipped, but by the rate at which company goals are achieved.

Company goals

A useful exercise in evaluating current company goals is to ask youself the following four questions:

• What is the one thing above all else are we trying to accomplish as a company?
• What does success look like?
• How is it measured?
• What are the roadblocks?

Before roadmap planning begins it is important to understand these fundamentals as each project should be considered the next most important thing you can do to realize these goals.

Quarterly Roadmap planning

Team strategy

Prior to defining projects or potential projects teams should ask themselves similar questions:

• What is your team’s strategy and how does it contribute to the company goals?
• How will you measure success?
• What are the projects you have planned and how do they contribute to your strategy?
• Stack rank your projects in the order of lowest effort / highest value to highest effort / lowest value.

Creative teams comprised of intelligent people have a natural tendency to come up with too many projects, spreading themselves too thin and decreasing their ability to deliver complete, high impact products.

Feature Brief

The first step in evaluating a project and its viability is to create a Feature Brief, with input from engineering and UX.

At minimum a Feature Brief should include the following:

• User Journey
• Target Audience & Market
• Key Personas
• Primary use cases and edge cases
• Problem definition
• Existing solutions
• Proposed solution / Hypothesis
• Market opportunity
• What’s included in the MDP (most delightful product)
• What’s not included in this release but under consideration for subsequent releases
• Unique differentiators
• Success criteria
• Risk factors

Briefs are read by product stakeholders and presented by the team leads. At this review the team determines if the project is worth doing based on UXR study results and project ROI (effort vs. value).

Feature Brief reviews are critically important as they are the point at which a decision is made to pursue a project or not. Given the importance of the meeting I have established the following rules of conduct:

One person will be designated as notetaker, focusing on action items and feedback coming out of the review. Other than the notetaker, all laptops are closed. During the presentations, questions should be written down as each interruption requires a $5 donation to the tip jar.

After the presentation there is a Q&A and a final determination is made as to whether the project should continue or not.

Product Requirements (PRD)

For approved projects a Product Requirements doc is created.The PRD becomes the canonical document for the project. It includes condensed versions of what was in the brief plus new specifics that allow engineering to begin developing the feature per the functional requirements and design specifications:

• Detailed feature descriptions and mocks of the the MDP (minimum delightful product)
• What’s not included in this release but under consideration for subsequent releases
• Eng design specifications
• High-level marketing and PR plan
• Timeline

The PM develops detailed requirements in collaboration with eng and UXD creates mocks (if appropriate). The analytics team works with the project team to define the instrumentation of metrics.

Product leadership reviews mocks and provides feedback. Once approved, pixel perfect specs are created and dev begins.

Reviews and continued user testing happens along the way, feedback is provided and modifications are made until the team is satisfied.

Prior to launch, Analytics works with PM team to build dashboards to view success metrics in real-time. The analysis of that data informs future iterations.

The team scores themselves at the end of the quarter against the goals set out at the beginning of the quarter.

Rinse, repeat.

Rinse, repeat.