Of donuts, doubt, and customer meetings

Frittering away the time with an experiment
All experiments involving donuts are worth doing, so here's one you might try. Tomorrow, bring a box of donuts to work, and leave them in the kitchen. At the end of the day, go back to the kitchen and count the number of donuts that people have taken.

Next week, pick a meeting-filled day, and bring a new box of donuts to all of them. Don't leave the donuts in the kitchen--the point is to keep it visible at all times. At the end of the day, count the number of donuts consumed.

Chances are that the number of donuts consumed in Week One is greater than the number consumed in Week Two, for an obvious reason. People behave differently when they are observed. We like the donuts, but we don't like being seen taking a donut (Homer Simpson excluded).

The crueller truth about customer meetings
While that principle seems thuddingly obvious, it's also easy to forget it--like, say, when product managers are using customer meetings to further the collection and analysis of product requirements. Most PMs naively assume that customer meetings are 100% reliable sources of information. You ask your customers straightforward questions like, "What enhancements are important to you?" You take the answers at face value. What could be simpler, or more reliable?

Unfortunately, you're deluding yourself if you trust the information you collect from customer meetings without reservation. Here are a couple of reasons for skepticism:

• The recency effect. Since you probably don't meet with a particular customer all that often, their list of demands will be skewed towards the issue du jour. Unfortunately, what you're hearing may consist more of the urgent issues of that day, instead of the important issues of the entire year.
• Time limits. "Features" are really a set of capabilities in a larger system with other moving parts, both technological and human, collectively designed fix a set of business problems. Understanding the entire context of a few key requests may take more time than that hour meeting you scheduled.

A few other reasons for skepticism have their roots in the Donut Visibility Principle (more famously known as "the observer effect"):

• The boss in the room. Individual members of an organization have their own particular roles, interests, experiences, skills, and opinions. Without outside influence, they'll arrive at a particular list of enhancements they want from you, for reasons that fit their view of the world. The brash young developer and the old, crusty DBA will say something different, however, if the CIO is also attending the meeting. They'll naturally temper what they say to fit their boss' opinions, and they won't necessarily be as acerbic as they are sometimes on calls with Support. The "customer" is an organization constructed from individual human beings, not some monolithic meta-person.
• The tech vendor echo chamber. Let's be honest: your company goes to a customer meeting wanting to hear certain things. Maybe you want validation that your next Big Idea is as brilliant as you think it is. You might also want to convince the customer that your recommended workaround is genuinely going to address one of their problems. Being the well-intentioned goof that you are, you ask questions designed to elicit your preferred response, and you selectively listen to the answers.
• The implicit negotiation. Customers view the conversation with you as a negotiation. They won't get everything, so they need to focus on what they can get--which involves not only enhancement requests, but other business issues beyond the technical ones. Therefore, customers won't always be totally honest with you, if they feel that, by giving ground on Issue A, they'll make progress on Issue B.

All three of these reasons to doubt the absolute veracity of what customers tell you arise from the same observer effect. If you read the secret diaries of the people sitting in the conference room, you'd get a much different picture of what the people in that organization want from you.

Sprinkles of information from other sources
The observer effect has two profound effects on product managers:

• Use Web 2.0 sources of information whenever possible. In discussion forums, blogs, Wikis, Facebook communications, and tweets, people are still aware that they're being observed. However, the power of the observer effect is decreased. (Need proof? Just remember how many people you've met over the years who seem reasonable in person, but mutate into the Tasmanian Devil in e-mail exchanges.) You're more likely to hear honest opinions in a third-party, Web 2.0 forum (think of it as the electronic Barcalounger in the Internet's rumpus room) than in customer meetings.
• Sharpen your journalistic skills. Reporters don't take what they hear at press conferences at face value. They also don't trust everything they hear on deep background, since any source may have a hidden agenda. As a product manager, you face a similar challenge in getting to "the real story" behind the customer meeting. For example, if your CEO and the customer's CIO are the bestest of friends, you should have strong suspicions about what you hear in a meeting that includes the CIO. The project may still crash and burn for reasons that aren't discussed properly in that meeting.

Postscript: A constant theme in this blog is, "Product management is a profession that requires specific skills and experiences." Therefore, whenever I post something that fits that theme, you'll see the brand-new Professionalism tag applied to it.

Blah blah (Tom speaks) blah blah

2009 might be, in the Chinese calendar, the Year of the Ox, but January feels like the Month of PowerPoint. I've been doing a lot of speaking lately, including last week's great session about Lean and Agile in San Diego. (And thanks again to Rober Pryor of the San Diego Software Industry Council for the invitation.)

Coming up:

• A Forrester teleconference, "Agile Adoption Changes Tech Company Operations," which includes some preliminary results from the "Agile company" research.
• A small presentation to some Forrester clients about the state of the technology market, including where the opportunities lie, from a geographic, vertical, and solution perspective. Plus a few tips on how to emerge from the downturn a stronger company.

I don't know about you, but January has been a busy, busy month for me. Companies are definitely not sitting on their hands, waiting to see what happens to the economy in general, and the tech industry specifically. According to the latest PriceWaterhouseCoopers report, total venture capital for software was down sharply, but was larger than the VC money going to any other single vertical. And the news from technology vendors continues apace, such as the latest progress report on Windows 7 beta.

Busy, busy, busy. The economic news of late 2008 may have been a shock, but people seem eager to continue working. The biggest problem, of course, seems to be figuring out where to put your time, effort, and money during these challenging times.

Love gets you twisted

I've been enjoying Christopher Cumming's product management blog, Product Management Meets Popular Culture. His most recent post, "Product Managers: Can You Reject Narcissism?" deserves special attention.

Most product management aficianados opine, at some point, about the importance of product passion. You need to love your product. You need to embrace it, nurture it, defend it, extol its virtues to other people. If your product fails, maybe you didn't believe in it enough. (You probably killed Tinkerbell, too, you unfeeling bastard.) If the product succeeds, you can bask in the afterglow, and then maybe have a cigarette.

If that sounds a little creepy, maybe it's worth re-evaluating your relationship with your product. I'm exaggerating for effect, but that's only because the word "passion" is vague, and exhortations to have product passion often sound pretty overheated.

That's what makes Cummings' post worth reading. Passion can easily mutate into something ugly, which can have bad consequences for the product manager, the object of the product manager's affections, and the company.

For example, if you've worked in a big company, you've no doubt attended at least one cross-group meeting in which PMs fight for their products' interests. These discussions can be constructive, but they can also turn into the tech industry equivalent of a child beauty pageants, with the passionate PMs playing the role of the stage mothers. No one wins in this arena, least of all the PM who may have just destroyed any chance of working productively with other PMs. Organizations change, PMs move between groups...Who knows who your co-worker, or your boss, will be, two or three years from now?

Product management is inherently political. Books that drive home that point, such as The Art Of Product Management, are worth reading. So, too, are like-minded blogs like The Cranky Product Manager.

Therefore, perhaps we should pick a different metaphor for product management. Instead of lovers, PMs need to be patriots. Both lovers and patriots feel strong ties and obligations. Both risk letting their emotions run out of control. The important difference is, while we understand and forgive lovers who give into these urges, we expect a bit more sangfroid from patriots.

Alternative energy doc published

One of the documents which I most enjoyed writing, "Emerging Energy Technologies Open Opportunities For The Technology Industry," just appeared on the Forrester web site.

Forrester analysts, Chris Mines in particular, have been publishing no small number of studies about Green IT. What was missing, I thought, was where the technology industry fits into one of the few parts of the economy that's likely to grow over the next couple of years. Public investment will accelerate growth in this market, but there won't be one big Manhattan Project-style program. Therefore, if you're not familiar with this market, it might be hard to figure out where to start.

Hereditary conditions

Many product managers who work with or within Agile teams have told me how they've felt left in the dust during the early phases of the Agile implementation. "We've sighted our target persona!"the development team exclaims. "Champagne for everyone!"

Unfortunately, they forget to invite to these festivities the very person who will, beyond this sighting, provide ongoing intelligence about that role--and the use cases, and whether that's the right role for the product, and what the competition is doing to serve that person, and whether there's a market for all this technology in the first place. A good product manager also has mad skillz in collecting and analyzing this information, something that even the most wunderbar of Wunderkinder doesn't necessarily have right out of the womb.

Shane Hastie at InfoIQ describes the same problem facing business analysts, the cousins of product managers in IT organizations.

There is a gap in much of the literature about Agile software development practices, and on many Agile teams. This gap is the role of Analysis in Agile projects - who does it, what is the use and value, and how does it change? The implied (and I have heard stated at least once) attitude is "we don't need no stinkin' analysts" - needless to say I feel this is WRONG!

Hastie's advice for the business analyst echoes suggestions I've heard for product managers. The analyst is a pro at business requirements. You can get economies of scale in tasks like user story development if you have one person do it full-time, instead of lots of people trying to squeeze in the necessary time. Business analysts are often good parents, model citizens, and loving pet owners, too, so why not extend the hand of eternal chumship to them? And so on.

As well-intentioned as this argument may be, perhaps it's the wrong approach to make. Perhaps the burden of proof should fall on the shoulders who think that they can do the business analyst's job and their own without committing grievous errors.

I'm a pretty smart person. Over the years, I've read a fair number of mystery novels, and enjoyed a sizeable number of detective shows (Columbo, the many-headed Law and Order hydra, the excellent BBC Sherlock Holmes series with Jeremy Brett, etc.). However, I don't feel obliged to take over the task of investigating crimes from my local police department--especially given the risks.

We see police detection as a profession--just as we might see business analyst, or product manager, in the same way. We just don't see the harm in doing a bad job of requirements collection and analysis. Perhaps in an economic downturn, the higher cost, for technology vendors, of making bad product decisions might change that perception.

Agile company survey launched

Our survey about Agile's effect on the structure and operations of technology companies is now live. If you're interested in participating, here's the link. If you have questions or technical problems, please contact Zachary Reiss-Davis.

Who should take this survey? Since we're interested in the ripple effects outside of the development team, practically anyone in a company that has adopted Agile. The broader the sample of different roles, the better. Please forward the link to anyone who might have something to say on the topic. Affected or unaffected, happy or unhappy with the results, we're interested.

Also, my colleague Dave West is running a different Agile survey. In his case, the topic is limited in focus to development teams, and not just within the technology industry. if you're interested, please contact David D'Silva.

Swearing in public

I'm growing fond of Twitter, particularly since it's a great tool for overhearing what's on the minds of people involved in a particular line of work--including, oh, say, product management. This morning, I followed a Twitter-posted link to Brian Lawley's "Product Management Manifesto." If future historians wanted to learn about the product management profession, both the good and the bad, the Manifesto might be a key piece of evidence.

That's not a good thing. The "Manifesto" may reflect the current state of product management, but it's a bad manifesto.

What Is And Isn't A Manifesto
For people reading this blog, the word manifesto probably conjures up two main examples, Agile and Communist. In both cases, the manifesto is intended to be a plan for collective action. Today, we follow a long-term development plan. Tomorrow, we start using a more adaptive process. Today, we work on the assembly and hope our lives will improve will get better. Tomorrow, we march on the factory owner's office, or the tsar's Winter Palace.

The "Product Management Manifesto" is really a personal oath. Statements like, "I refuse to settle for mediocrity," or, "I believe that Product Management is one of the toughest, yet most rewarding jobs in the world," sound more like personal statements of dedication, bordering on professions of belief.

Here's some text excerpted from some other oaths, just to drive home the point further:

• "On my honor, I will do my best to do my duty to God and my country, and to obey the Scout Law." (The US version of the Boy Scout Oath.)
• "Thirdly, I believe with equally firm faith that the Church, the guardian and teacher of the revealed word, was personally instituted by the real and historical Christ when he lived among us, and that the Church was built upon Peter, the prince of the apostolic hierarchy, and his successors for the duration of time." (From Pope Pius' Oath Against Modernism.)
• "It is right that those who offer to us unbroken fidelity should be protected by our aid." (Typical language from a feudal oath.)
• "Be tasteless, rude, and offensive / Live in a swamp and be three dimensional / Put a live chicken in your underwear / Get all excited and go to a yawning festival." (Steve Martin, "The Grandmother Song." I added it to see if you were still paying attention.)

Doing More Harm Than Good?
So what's the harm in having a product management oath? Perhaps nothing. On the other hand, it may reinforce the weakness and ambiguity of product management in many technology companies.

The word "manifesto" drips with political connotation. That's good, in a product management context, because product management is inherently political. Product managers are persuaders, by necessity. Product managers also find themselves in the thick of nasty political struggles. The politics of product development are sometimes structural and unavoidable, such as the persistent tension between development teams and salespeople over the promised contents of the next release. Others are somewhat avoidable, but all too common, such as the power struggles that erupt between SPITRs and product managers over who really knows which features are really important.

However, it's bad to raise the expectations of resolving a political problem, only to retreat immediately into personal declarations of good intentions and right actions. The problems with product management today are not personal, but institutional. There's no point in swearing to "further my professional status by attending training courses, becoming certified and reading books, blogs, and newsletters to learn best practices," if my employer wont' pay for classes that will help me hone my PM skills.

In fact, some of the elements of the "Manifesto" border on self-loathing. I haven't met a product manager who didn't want to be "an expert in all areas regarding my products." The problem, of course, is finding the time, when you're already racing to answer the latest urgent request from Sales or Support, or you're spending way too much time in meetings. What's the point, therefore, of swearing to do something that you already think is important, other but you don't really have a good chance of doing it? Unless, of course, you need to remind yourself, like a medieval flagellant, of how lowly and wretched you really are.

Implicitly, oaths state an individual's subservience to a particular organization or creed. I swear to you, the Grand Master of the Knights Templar, the country in which I am about to become a citizen, or the Cub Scouts of America, that I will loyally comply with your principles, laws, and directives. In contrast, product managers don't need to swear undying fealty as a subordinates. They do need to establish a stronger, clearer role within technology companies.

Perhaps the product management profession needs a manifesto. ("A spectre is haunting the technology industry--the spectre of bad product decisions.") Unfortunately, this particular "Manifesto" ain't it.

A good month for crankiness

The Cranky Product Manager has been posting up a storm lately, with several excellent ones in the last month. For personal self-interest alone, it's worth digesting what she has to say in her post about being the CEO of your own career. Plus, there are the results of her poll on PM certification. Go read.

Sales enablement survey

The vast majority of people who read this blog are undoubtedly involved in some aspect of sales enablement. I'm tempted to add, "Whether you like it or not," but most PMs enjoy that part of the job, even though they might do a little too much of it.

Therefore, we'd be grateful to hear what research we have planned for the future would be most helpful to you, the sales enablers...Er, the PMs who help enable sales. Forrester takes the "Client Choice" channel of communication with the outside world very seriously. We want to keep producing research that answers the most pressing questions on your mind. Click below to state your preferences.

Blue helmet blues

Saeed's recent post on the triumvirate of Sales, Marketing, and PM contains laudable suggestions for how PM can work better with these other groups. When he starts talking about the rocky relationship between Sales and Marketing, I worry that some hapless PM might read this post and think about playing peacekeeping force between these warring factions.

My frank advice: don't try to be the hero that ends the frictions between these two groups. At some point, they might ask you for help in some project that might help settle their differences. However, as in all troubled relationships, they must want to change for this sort of activity to be worthwhile. PM has enough challenges of its own, and it has little leverage or no over either of these organizations.