As much as I worship the Cranky Product Manager from afar, I have a slight disagreement with her in this recent post. Her latest target, a perky PM plebe named Scott Buchanan, is not what I'd call a product manager. But Her Crankiness overlooks something important: at Microsoft, where Scott "Sparky" (not his real middle name) Buchanan works, the people who do the product management function are called "program managers." In Microsoft argot, "product managers" are really product marketers.
The most mature part of the technology industry may be the console and PC game vendors, who pitch their wares at the least mature audience. These companies matured the hard way, by surviving not just technology challenges, but having to master business techniques that many other technology companies have yet to learn. Here are a few examples:
Find out what it means to product managers in the long awaited research document about the the job of product management. Here's the link.
In it, you'll find the interesting survey results about the difference between what product managers do, and what they think they should be doing. You'll also see some other important demographic information, such as who makes product decisions, where PM fits into org charts, and most interesting of all, what challenges PMs face. (Spoiler alert: They struggle with their own organizations far more than the challenges of the outside world.) The document also provides some recommendations on how to better respect the most important work of product management, and how to better organize and run a PM department.
Coming very soon is another article on a related subject, what makes the technology industry special. The extremely short version: By necessity, technologists talk a lot about innovation and competition, but what's missing from this conversation is the "A"-word.
[Click these links for the first and second posts in this series.]
There's no way around discussing features. Every release, you're going to add some piece of functionality. You can come up with academic-sounding names, or cute nicknames, but at the end of the day, you're talking about a feature.
However are features the right place to start? If you had to invest your time in documenting what customers want, is it better to describe a use case or a feature? Or, to use other language, should you be writing a story, or a vignette that fits into the larger story?
Increasingly, technology companies are putting more emphasis on stories, a.k.a. use cases. (Yes, I know, many people prefer to keep stories distinct from use cases different. However, for sake of this post, I'm going to blur these differences.) That's a very good thing, but not without its costs.
Looking at the choice between (a) a use case, and (b) a list of features, there's almost no contest between them. Use cases have several immediate advantages:
Certain words in the technology industry lexicon are so unspecific that they obscure more than they describe. Customization is one such word. Another is customer.
Who needs your products and services? Not General Motors. Not McGill University. Not the US Department of Labor. Instead, the collection of people, procedures, and problems that constitute a project define who the "customer" really is.
I learned the importance of this distinction by way of customer references. Everyone wants to have a Name Brand Customer as a reference. However, notoriety has nothing to do with customer success. A Big Name Manufacturer had less success, due to internal politics, than Dinky Manufacturer. Of course, dazzled with the glamour of working with Big Name Car Manufacturer, we wasted a lot of effort on trying to help people who, in all frankness, didn't really value our help, because they weren't ready to receive it.
Readatwork is certainly one of the cleverest sites I've seen in a while. You can read a few short stories on line, in an interface that looks like the standard Windows desktop and PowerPoint. Now, it just needs more content.