Next Wednesday, May 5th, fellow product management/product marketing blogger and Informatica PM Saeed Khan and I will be having a conversation, live via teleconference, about the two sides of PM metrics:
Metrics by PM. What are the important metrics about a tech vendor's business and technology that should PM maintain? This question strikes at the heart of PM's core responsibilities, making sure that a tech vendor's products and services help its business, and vice versa.
Metrics about PM. Want to start a lively conversation? Ask product managers and product marketers about the metrics used to measure their performance and contribution. These metrics do more than just point PMs in the direction of quarterly goals. They also communicate within the company the value of what PM does.
Saeed always has sharp insights on these sorts of topics (which is why you should be a regular reader of the On Product Management blog, by the way). This call is a real conversation, not a one-way blabfest, so we're definitely looking for your questions and comments during the call. Expect a mix of observations about the state of PM in the tech industry, as well as best practices developed through hard experience.
While there might not be a single correct formula for fitting product management into an Agile setting, there's one inescapable rule: Prepare to have your PM skills put to the test.
Recently, I was speaking with Barry Paquet of Quantum Whisper, a small firm that has a tool designed to help PMs with these Agile-related challenges. To the right, you'll see one of the slides from Barry's presentation. The message is pretty self-evident: if your company is going to take the "voice of the customer" part of Agile seriously, PM must keep a lot of plates spinning. Feedback loops in Agile development don't run themselves—someone has to be on top of the collection, analysis, validation, communication, and review. With Agile, these activities are happening nearly constantly.
While any PM who has a passion for building good products should welcome this change, it also can be a little scary. In my own research and advisory work on Agile adoption in tech industry companies, I've heard some PMs express no small anxiety about this new model. In part, they're worried that the company might not support or even understand this process fully. However, they also experience some dark nights of the soul about whether the have the skills and experiences needed to play that sort of role. Here are a few common concerns:
Agile adoption requires a change in values, not just a change in process. That's the message of the Agile Manifesto, and everything we've learned in the year since the Manifesto's publication has only expanded and emphasized it. We might not have all the specifics on how that relationship works (for example, does an "Agile culture" automatically dictate Agile practices?), but the correlation is definitely there.
In technology companies, these values are critically important, since technology does not just improve the business, it is the business. Agile changes how teams develop and deliver technology. In a technology company, delivery includes practically everyone outside the development team—marketing, sales, support, consulting, partners, you name it. Beyond the janitorial staff, it's hard to think of someone who won't be effected when a tech company goes Agile.
Consequently, product managers and product marketers, sitting on the border between the development team and everyone else, are simultaneously the agents and targets of Agile transformation. For example, when monolithic releases crumble into many smaller iterations, people throughout the rest of the company have obvious questions, such as, When can I tell a customer to expect the enhancement they've wanted for the last two years? When is the next time we're going to have to do sales training? When will we have delivered enough new value to merit a product launch? PMs facing this situation will have to make adjustments to their own work, such as building and communicating the product roadmap.
In the first and second parts of this series, I argued that people who write about product management and product marketing should be circumspect in their choice of topics. A field that's as young as PM in the tech industry isn't fertile ground yet for a grand theory of what the profession is all about. Categorizing the PM function was a good first step; now, we're in the middle of building "middle-range theories" about PM. A good set of field-tested guidelines for researching requirements, doing market opportunity assessments, or crafting the right marketing mix would be pretty darn good, thank you very much.
Aristotle beats down Plato in no-holds-barred epistemological cage match
In fact, middle range theories are an essential precondition of a grand theory. Big, unifying ideas, such as special and general relativity, don't come before the observation of the real world. (Sorry, Plato: the people who spend a lot of time in caves get prison pallor, not "actionable insights.") They always come after, when a set of hypotheses that seemed to work pretty well, until you noticed that the planet Mercury wasn't in the right place, made hash of them. Then, someone fretted over the inadequacies of these tenets, and after a fair amount of head-scratching and hair-pulling, came up with the big unifying idea.
Advice to PMs about how to do their jobs better is valuable, up to a point. Inspire PMs to be stronger, better, faster. Delineate all the important contributions they might make. Arm them with advice on how to make these contributions. None of this guidance will have any substantial effect if PMs don't have the backing of their employers.
A prime example is PM's role in innovation. PMs are usually better positioned than anyone in a technology company to answer critical questions about innovation such as, Is this a good idea? If so, what's the market for it? Can we operate in this market? And so on.
Unfortunately, opportunity and reality don't always meet. Maybe the PM raises these questions, but can't get the answers. Or, the PM has the answers, but the organization isn't inclined to listen. Frequently, the innovation process—or, more accurately, the lack of process—doesn't give the PM the opportunity to ask and answer these questions at all, particularly as an idea gets momentum in the development cycle. (For instance, try pulling the plug on a CTO's pet notion, once development is underway.)
Leadership doesn't just happen, just as innovation doesn't just happen. Just look at the history of the US highway system.