By Tobias Kahn, @Tobitronkahn
product development environment, yet the specific attributes of what makes a
great PM, and how to measure their success remains murky. If a product manager
leads a failed product does that mean they’re
bad? If a product succeeds, does that mean the PM leading the charge was
the cause? Not necessarily in either case, and therein lays the challenge.
to communicate quickly emerged as a key attribute. The PM needs to be the hub,
synthesizing information from other experts to paint the big picture. It’s
essential for a product person to be able to communicate in stories. Not just
user stories (the documentation used for feature requirements in agile software
development), but the overall story and goals of the product. If you aren’t
clearly defining what’s important, it’s hard to get people to understand.
Buy-in from engineering and other departments is essential, and story telling helps
to achieve this.
Another key thread discussed was the importance of
domain knowledge and experience *as* the customer. There’s multiple sides to
the argument here: on the one hand, domain knowledge gives you insights to
subtle details of a customer’s experience, and this is particularly important
in complex systems like healthcare. But too much passion or an “I know how it
is” sensibility could restrict a PM’s thinking to one path. Similarly,
experience having been the customer could be blinding. One customer doesn’t
represent the entire customer base, and perhaps the customer you have isn’t the
customer you want! In any case, the antithesis of a good PM is someone who
simply does what the customer said they want. The ability to extract the need
from the want is a skill set any PM should have, regardless of domain knowledge.
