The Heretech

Against a grand theory of PM, part 2

[You can find part 1 here.]

Most fields of study start with classification. The important precursor to any theory, middle-range or grand, is putting what you're studying into conceptual buckets that help organize the topic in meaningful ways. That's where the study of product management and product marketing started, and that's where it has stayed for the last several years. (For more discussion on that point, click here.)

Those conceptual buckets are important, for a variety of very practical reasons. For example, any theory of PM needs to exclude things that are not PM-related. As any of us who have been in the PM profession knows, defining the boundaries of PM has been difficult. The specialized consulting firms, such as Pragmatic Marketing and Sequent, have done a good business helping their clients sort out what their PMs should and shouldn't be doing.

It's a long stretch, however, from classification to grand theory. It took centuries for people studying the natural world to figure out that the classification of matter into four substances (earth, air, fire, and water) wasn't leading to any great insights into physics and chemistry.

On the other hand, when classification hits on something important, it can lead to important insights. The Victorian world's passion for sending researchers to distant lands, to add to the catalog of botany and zoology, led to Darwin contemplating the variation among finches in the Galapagos Islands, which led to the theory of evolution.

However, Darwin's short path from classification to theory is the exception, not the rule. In the PM world, it's important to recognize that someone needs to focus on requirements, and product managers, not product marketers, are the right people for that task. But how much work is necessary to do requirements well? What are the risks of doing a sub-par job with them?

And those are just the obvious questions. Here's a less obvious one: Is there a single correct template requirements? If so, PMs are just experimenting with different collections of content, until they collectively discover the equivalent of double-entry bookkeeping, the format on which all accountants standardized.

On the other hand, requirements might be a medium of thinking and communication that organizations use in whatever way makes sense to them, much as they treat e-mail. Some companies prefer to use e-mail sparsely, keeping more detailed discussions out of the message threads. Others like being chatty in e-mails, and expect their employees to contribute generously to these conversations. In the same fashion, some tech companies prefer detailed product plans to define the contents of the next release, while others create more minimalist documents, with other details to be found elsewhere (or not written down at all).

The answer to that question has profound consequences for the efficiency of development teams, the accuracy with which they guess what customers really want, and the larger organization's ability to bring new products and services to market. Peering into any periodic table of PM responsibilities, or roles, won't reveal the answer. That classification scheme, as useful as it may be, also does not how to measure PM's essential contribution to the company, which impediments put that contribution at risk, and how to resolve these issues.

[Next: So what kind of insights should we be trying hardest to achieve?]

[Cross-posted at The Forrester product management blog.]

Vote for the On Product Management blog

One of the best PM-related blogs around is On Product Management. I link to it frequently, I read it regularly--in short, it's Heretech-approved.

On Product Management is also nominated for the Canadian Blog Awards 2009, in the category of work-related blogs. If you share my high opinion of that blog, go here and vote for On Product Management. (Not that I mind another Canadian blogger getting an award...)

More info on Cisco's myPlanNet

Here's some more information about the topic of this week's Heretech podcast, myPlanNet, Cisco's simulation of running an ISP:

• The download page for myPlanNet.
• A slideshow giving more background on it.
• A Facebook fan page.

The Heretech, episode 30: Cisco's myPlanNet serious game

Stephen Liu and Petra Neiger of Cisco explain how their serious game, myPlanNet, illustrates Cisco's 25 years in the networking business. And it's an amazingly successful marketing tool. Plus, a quick pointer to a site that suggests how to get lots and lots of user-generated content. (c) 2009 Tom Grant.

Anti-social CRM

Using your community as a technical support resource may be a tool for good...Or eeeeeeeevil. Sure, their are plenty of healthy examples of vendors who have learned how to support their community as an adjunct to their regular support. Have a question? Post it on the forums, and someone, either from the community or the company, will answer.

That's not a new phenomenon. It's at least as old as the Microsoft forums, or the Oracle Technology Network, or the countless discussion forums that smaller companies use to augment their support capabilities. (Which makes me wonder why people are re-discovering this phenomenon, but that's a whole other discussion.)

Since community support is nothing new, we've seen cases where it has worked, and where it hasn't. Vendors who see good customer service as important will invest in their community to improve the customer experience that much more. Vendors who don't care about customer service might create a community, with the (ridiculous) expectation that it will replace their own customer support.

There must be a minor form of PTSD that horrible customer service can create, because all of us, at one time or another, have flashed back to the moment when customer service turned into an oxymoron. I have recurrent flashbacks to the time, several years ago, when I bought a Gateway computer with a faulty CD drive. Gateway purchased a bad batch of these drives, installed them in their computers, and instead of admitting to the mistake, kept sending them as replacements for identical drives until the supply ran out.

But that wasn't the worse part of it. Gateway compounded the problem with its, er, ground-breaking strategy for tech support. Rather than leaving you on hold until a representative was available, you broke into the call with the rep when you were the second or third person in line. Of course, that meant you had to sit through the conversation the rep had with the people in front of you in the queue.

Why? As one rep explained it to me, they were making it possible for other customers to help each other--presumably because the support person didn't have the answers? Or maybe you could just commiserate with other users about their problems, or feel lucky that your CD drive issue wasn't nearly as painful as the guy with the catastrophic hard disk failure.

Gateway may have had a remarkably silly take on community support (and I haven't even told you about holding the phone next to my PC!), but it was hardly unique in the chronicle of bad uses for your community. Forums where customers wonder aloud if any company representative ever reads posts. Fake customer accounts for posting positive things about the vendor. Threads deleted because the company felt embarrassed by the problems being discussed.

Maybe a few mediocre companies have a road to Damascus moment when they learn, through the community, how their customers really feel about the quality of their products and support. The chances are pretty slim of a similar epiphany in a company that could give a flying fig about their quality of support.

Google drops gears

I hope that Google's announcement that it will drop its own Gears technology is more than a leap of faith that HTML 5 will be an effective replacement. And what do the people who have developed on top of Gears do in the meantime? Unfortunately, the official Gears discussion group doesn't contain any answers for users who have posed that question.

Different presentations on Agile and Lean

Even though I see more than my fair share of PowerPoint slides on a daily basis, I still like skimming through SlideShare to see what people have posted. I liked this presentation by Si Alhir that tries to explain Agile and Lean to people who have no background in it.

However, this presentation wouldn't work for every audience. Sure, the presentation is as comprehensive as it could be, given the medium, but some people don't need a comprehensive introduction. Instead, they need something with a very spare amount of content that they can use to convince people back at the ranch that Agile and Lean are worth further investigation. (Lean, perhaps?)

This presentation gets closer to reaching that objective. It's not necessarily the "Agile For Lean For Dummies" presentation, but the author probably wrote it with a different audience in mind.

Pay now for the searches you hope to make

Since, until today, I've yet to enter a query into Wolfram|Alpha that returned a result, I'm still a skeptic about its ability to redefine search. (And no, user error is not to blame. )

Since Wolfram!Alpha is still just a wolf cub, not yet fully grown, I'm baffled why the company is pushing iPhone users to spend $50 on mobile client application, particularly since the web site worked fine on the iPhone. I'm another order of magnitude baffled by anyone who has purchased the application. Is it really a question of better graphics? Or needing a scientific calculator along with your search box? And are either of those worth $50?

Against a grand theory of PM, part 1

When you're start working in an unexplored field of study, such as PM in the technology industry, it's tempting to propose the Grand Theory Of Everything (GTOE). It's also the worst possible time to develop a GTOE.

Opinion is cheap
Two years ago, when I started this job, I knew I'd have a full research agenda. Very few people took on the job of pundit, arguing for a particular vision of how the PM function should work. Even fewer had any hard data on how it actually does work, in practice. Before making any sweeping statements about the profession, I needed to fill in some big empirical holes.

How diverse is the PM job description, across companies? Which sort of requirements do PM teams give priority? Does moving from an on-premise to a SaaS model have an effect on the PM role? Moving at an Agile pace must have some effect on the rest of the company—but what is it? Without answering these questions, it's next to impossible to give advice.

For example, some aspect of technology companies has made the PM job description different across teams. Unless you understand the forces that have conspired against a consistent job description, there's little point in telling PMs what they should and should not be doing. It's almost as useless as your doctor telling you, "If you're not feeling well, just get better."

Research is hard
Nevertheless, as you're doing the research, you can make important observations specific to the topic that you're currently investigating. Sometimes, the answers are obvious. For example, when I was researching social media as a new source of customer and market intelligence, it was pretty obvious from the start that there was real work involved in using social media in this capacity.

Other times, it's harder to find the patterns. Sorting through the reasons why PMs in one Agile teams is the product owner, and in another team the PM and PO are two different people, took a lot of head-scratching.

You also discover that your initial hypothesis can be completely wrong. I had expected that the companies that invest in requirements tools would be bigger and older, and therefore relatively more capable of affording the purchase and implementation. Unfortunately, the opposite was the case: on average, it's the smaller, newer companies, who feel they can't afford not to invest in these tools, that lead adoption.

Important conclusions are still possible
Consequently, anyone trying to figure out how to make PM work in the tech industry is going to be working primarily on middle-range theory, not the GTOE. If middle-range theory doesn't sound important, it's worth remembering the significant role that this level of work has played in the hard sciences. Observations like, Gravity bends space-time, or, These hitherto unnoticed chemical sequences are the reason why you're a human and not an antelope, are major steps forward in our understanding of how the world works.

If someone can figure out why even the most meticulously written and reviewed requirements don't stop some tech companies from making products that their users don't like or can't understand, that's a big contribution to our little field of study. Best to have more middle-range theory before even thinking about the GTOE.

Next: The difference between theory and classification.

[Cross-posted at The Forrester product management blog.]

The Heretech, episode 29: Marie Kalliney on an innovative PM teamThe Heretech, episode 29: Marie Kalliney on an innovative PM team

Our guest, Marie Kalliney of Ultimate Software, describes their innovative PM team structure that just makes sense. Plus, some quick news about the PM open house and upcoming research. I also ponder a curious omission in some corners of the blogosphere. (c) 2009 Tom Grant

Upgrading customizations, by the numbers

Here's a common conversation in the tech industry:

Customer: We'd really like a fix for this issue.

Vendor: We've fixed the problem in version 11.0.8.7. If you upgrade, your issue will disappear.

Customer: Um, maybe you're not aware of how big a deal an upgrade can be.  We have customizations, and it takes time to upgrade them, not to mention the infrastructure components that need to be upgraded and tested...

Vendor: Not to worry! In a few weeks, we'll be releasing version 11.0.8.8 SDK, which will include productized versions of some of the functionality that your customizations provide. You won't need to maintain these extra bits of code!

Customer: Really? I can quote you on that?

Vendor: Sure. As long as you read the small print absolving us of any responsibility for functionality we don't deliver.

Customer: What did you say?

A recent CIO Magazine article on the difficulties of ERP implementations got me thinking about this issue. One of the chief villains in this story, according to the CIO Magazine writer, is customizations. Upgrade the system, and you also need to upgrade the customizations. In a system as complex as an ERP system, upgrading the customizations never goes smoothly.

So who's really to blame here? Do we point the finger at the vendors, who make products that require customizations in the first place, and who don't prioritize the feature Make upgrades easier highly enough? Or are the customers paying for their laissez faire attitudes towards customizations, some of which may not have been strictly necessary?

To do a decent job of answering these questions, real research is necessary. Meanwhile, we can do some informed speculation. Even if the overall calculation can't be accurate, even a back-of-the-envelope estimation might reveal which aspects of the upgrade process matter the most. And by matter, I mean, will cost the customer time and effort during the upgrade. Identify the critical factors, and you also can tell who bears the greatest responsibility for whatever problems exist.

As with any such exercise, there are plenty of variables that you might consider, but only a few you can consider. We're only making a rough guess at something, so complexity, beyond a certain point, doesn't add anything. We want to arrive in the neighborhood of the truth, not build something so complicated that it never gets out of the garage.

Here's the list of variables I used for my own seat-of-the-pants calculation. Again, we're only considering the customizations, not all the other aspects of the upgrade:

• Number of existing customizations. This variable represents the customizations that the customer had the opportunity to discuss with the vendor.
• Number of new customizations. To be fair to the vendor, we have to acknowledge that customers are always thinking up new customizations. To be fair to the customer, the world changes (new business processes, new technology components that must be integrated, etc.), which compel them to write new customizations. Even if, during their last meeting, the vendor acquired perfect knowledge of the customer's set of customizations, that set is likely to have grown since their last conversation.
• Average time, per customization, to upgrade. I haven't decided to count customizations by feature points, function points, story points, or something else. I just know that points are involved.
• New functionality in the next release that replaces some fraction of the customer's existing customizations.
• Risk that the vendor will not deliver this new functionality (customization relief?) in the next release.
• Additional functionality in the next release that does not make customizations obsolete, but which do add overhead to the customization. The "You didn't ask us for it, but here it is" problem is commonplace in the tech industry.
• Average ease of upgrade, per customization.
• Average time, per customization, to handle additional overhead (change management stuff, such as training). This variable applies to all new visible functionality, whether the customer asked for it, or not.

Plugging some sample numbers, representing a fictional ERP implementation, into the calculation gave me a baseline. From there, I started cutting each value (number of customizations, difficulty of upgrading, etc.) in half, just to see what would be the effect of simplifying each element.

At this point, if I haven't said it enough, I'm just thinking aloud, so for God's sake, don't quote me. However, it seems as though the variables that matter most include:

• Average time per customization to upgrade. While customers might get better at doing customizations, vendors can invest in ways to simplify them. (If you've ever had the agonizing experience of seeing customers struggle to preserve customizations to a badly-designed web UI, you've seen at least one possible area of improvement.)
• Risk that the vendor won't deliver promised functionality that will replace customizations. Yes, customer complaints about the vendor's roadmap are justified. Vendors think in terms of releases, which are either fantastic, or slightly less fantastic than promised. Customers think in terms of projects, which will take either X weeks, if you believe everything the vendor tells you, or X plus some unknown number, if you want to look at vendor claims with a justifiably skeptical attitude.
• The number of customizations. On the other hand, it's definitely fair for vendors to push back on the number of customizations. How many of them represent something that the customer felt was important earlier, but nobody uses now? How many of them filled a genuine gap, but did so in a clunky way that's hard to maintain?

Again, real research is required to go beyond just an educated guess. Still, a little bit of math does sometimes help narrow the list of factors that probably do matter the most.

Open house on tech industry Agile adoption this Thursday

Welcome back from your long weekend of tryptophan-induced torpor! This Thursday, December 3, we're hosting our second open house for product managers and product marketers at Forrester's office in Foster City, CA. These are monthly informal discussions in which the usually blabby analysts take more of a supporting role, kicking off the discussion and dropping, where appropriate, insights from our research on the topic du jour.

This month, the topic is Agile adoption in the technology industry. Specifically, we're going to discuss the effect that Agile adoption in the development team has on the rest of the company. A few examples of the questions that we often hear include...

• How will QA need to adopt?
• Do we need to re-think product launches?
• What's going to happen to the structure, content, and schedule for requirements?
• How do Sales, Marketing, Support, and other customer-facing groups stay apprised with the product roadmap?
• What is the product roadmap, really?
• Will executive management's role in the development process change?

WHEN: Thursday, December 3, from 4:00 to 5:30.

WHERE: Forrester's office at 950 Tower Parkway, 12th floor, in Foster City, CA.

WHO: You, and anyone else you think might be interested. I'll be leading the discussion this month.

HOW MUCH: Free.

AGENDA: Before and after the official discussion, we'll have some time for informal conversation, getting to know your peers from other companies, etc.

RSVP: Not required, but it's nice to know who's coming. If you have a minute, drop Marsha Versen (mversen@forrester.com) an e-mail to let her know that you're attending.

FUTURE TOPICS: I'll be posting a preliminary schedule in the next few days. We live to serve, so it's important to tell us what you want to discuss. Here's a survey that we're leaving open indefinitely, so that you can indicate the topics that interest you the most.

Look forward to seeing you this Thursday.

[Cross-posted at The Forrester product management blog.]