LITMIR.BIZ

Скачать книгу

have international, as just a few examples.

      Product Operational Knowledge

      This topic really should be obvious, but I can't tell you how often I meet a product manager who doesn't actually know their own product beyond how to give a basic demo. But hopefully it's clear that a product manager must be an expert user of her own product in order to be trusted.

      For consumer products, it is not usually very hard to become expert on the product's use, but for products for businesses this can be much more difficult—especially when the product manager lacks the domain knowledge.

      Coming up to speed on this typically involves reading whatever user or customer documentation exists, taking whatever training classes may exist, spending time with customer service staff, and if at all possible, using your own products on a daily basis (this is known as dogfooding).

      As a clear litmus test, if an important industry analyst were to offer to come visit your company to discuss your product, either the product manager would give the briefing herself, or at a minimum she would be spending significant time preparing the person who would be giving the briefing (usually the product marketing manager).

Process Skills and Techniques

There are countless process‐related skills and techniques, and new techniques are always emerging. The main objective for those of us responsible for coaching product managers is to make sure the PM is knowledgeable about techniques that are suitable for the tasks at hand.

      Product Discovery Techniques

      At a minimum, the new PM must understand the four different types of product risk (value, usability, feasibility, and viability), the different forms of prototypes to tackle these risks, and how to test those risks qualitatively and quantitatively.

      There are many online resources and training classes, and the book INSPIRED goes into detail on these product discovery techniques.

      When I coach PMs, I typically have them read the book, and then I like to make sure they understand the techniques by describing different scenarios and asking the PM how she would address them. I'm looking to make sure she is thinking about risk appropriately, and that she understands the strengths and limitations of each technique.

      Product Optimization Techniques

      For products that are in production and have significant traffic, there are important techniques referred to as product optimization techniques that the product manager needs to understand and know how to effectively utilize.

      This typically involves learning one of the commercial tools and then running an ongoing series of A/B tests—mostly to optimize the product funnel, but it could be used for other purposes as well.

      Product Delivery Techniques

In general, product delivery techniques are the focus of the engineers on the team. However, it's important for the product manager to understand the delivery techniques that are being used (e.g., continuous delivery), and in some cases—such as release planning—to take a more active role.

      For example, for certain large product changes, a parallel deployment may be called for. The product manager needs to know what these techniques entail—especially the additional engineering costs—to make suitable decisions regarding delivery.

      Product Development Process

      The decision as to which development process the engineers use to develop and deliver software is up to the engineers and engineering leadership. However, the PM does play a role in the process, and she must understand what her responsibilities are.

      Most teams use some form of Scrum, Kanban, and/or XP (Extreme Programming) techniques. Often, teams use a blend of these.

      I usually recommend that the new PM take a CSPO (Certified Scrum Product Owner) course if she has not already done so. That simple and short course will explain her responsibilities as the product owner for the team.

      Most companies have also standardized on a tool for managing the product backlog, so the new PM will need to learn this tool as well.

      Note that I have long complained that too many product managers have only had CSPO training, and then they don't understand why they fail as a product manager. Hopefully it is very clear at this point that the CSPO responsibilities, while important, are just a very small subset of the responsibilities of the product manager of an empowered product team.

People Skills and Responsibilities

      Thus far, we have mainly discussed areas (product knowledge and process skills and techniques) where just about anyone who's willing to put in the time and effort can succeed. And I would argue that, without that foundation, nothing else matters.

That said, the difference between being just a competent PM, and a truly effective PM, is often their skills with people.

      There has long been a debate in the product world about whether these people skills can be effectively taught or coached. In my experience, for most but not all people, you can significantly improve and develop their people skills. But they do have to want to improve.

      If the person is not good at these skills, and shows no sincere interest in improving, then that's when the manager needs to help the person find a more suitable job.

      Team Collaboration Skills

      Modern product management is all about true collaboration between product, design, and engineering. This begins with ensuring the product manager is knowledgeable about the real contribution of product design and engineering.

      The PM does not need to be personally skilled in either design or engineering (most aren't, although many PMs believe they're great designers), but they do need to understand and appreciate their contributions to the point where they understand that what design and engineering bring to the table is just as essential as what the PM brings.

      Next, the PM needs to establish the relationships necessary for true collaboration, which is built on trust and respect.

      In my own coaching of PMs, once they've learned the basics we've discussed above, most of the coaching I do has to do with collaboration.

      When I sit down with a product team to talk about a problem they're trying to solve, I rarely spend time with just the PM. Almost always, it is with the PM, the product designer, and the tech lead.

      Again, that's just the nature of product today. But during these sessions, I am witness to countless interactions. And afterward, if I've observed something, I often pull the PM aside and try to point out how her interactions during that meeting either helped or hurt her efforts to build trust.

A one‐hour meeting discussing a problem or objective will usually yield many good examples I can use as a coaching opportunity for the PM. How engaged is the rest of the team? Are they acting like they are empowered to solve the problem, or are they acting like order takers? Is the designer and engineer bringing potential solutions to the table or just pointing out issues with whatever the PM proposed? Are they spending too much time talking (e.g., planning) and not enough time trying (e.g., prototyping)? How are they resolving differences of opinion?

      Stakeholder Collaboration Skills

      Many of the points regarding team collaboration skills also apply to stakeholder collaboration skills, but it's actually easier to build trust and relationships with your own teammates (e.g., your designer and engineers) because you interact with them every day—focused on solving the same problem.

      There are additional dynamics at play with stakeholders.

Скачать книгу