Tell me lies

Christopher Cummings' latest entertaining and insightful post is worth reading:

Think about the last time a salesperson at a retail establishment asked what you were looking for. How honest was your answer? And how
complete was it?

Exactly. Product teams often don't realize how misleading information coming straight from customers can be:

Read more

From the cradle to the grave

During the last couple of month's worth of conversations with product managers and product marketers, the following questions popped up with conspicuous regularity:

  • What's the difference between an offering and a product?
  • How much do service offerings need to be treated as products, meaning that they need real product management?
  • How do you know when something is ready to be called a product?
  • How do other companies handle "productization"?
  • What best practices do other vendors use when defining the product roadmap?
  • Should we put our product into maintenance mode?
  • Realistically, when can we cut off support?

The order in which I've placed these questions is no accident. They're the cycle of birth, maturation, old age, and death that all products face.

Read more

Calling all PMs: Sample requirements documents

What we're doing
The research into a research piece on best practices for requirements documents is underway. As anyone who has ever been responsible for requirements knows, there are two sides to this question:

  • The requirements process. The overt part of requirements is the process of writing them. The subtler part of the process is figuring out the information needed for the audience. Development (including QA and documentation) might be the primary audience, but they're hardly the only ones.
  • The work product. In other word, the actual requirements document. Or, in many cases, documents. For example, while there might be a template for feature requirements, it may link to related or supporting documents (personas, customer feedback, etc.)

How you can help
As with any type of research, the larger and more representative the sample, the better. Which means that you, Dear Reader, can help make this research project all that it can be. In this case, we need your help with that second aspect of requirements, the work product.

Read more


Agile, social media, and requirements

Speaking of social media, one of the two research documents now in the editing queue looks at using social media as a source of product requirements. Using Forrester's POST* methodology as a starting point, how can product managers harness the enormous amount of potentially useful information transmitted in the clear through blogs, forums, Wikis, and similar technologies?

The other document in editing is the "Agile company" piece, covering the results of the survey and interviews we conducted to understand how Agile development changes technology companies. To foreshadow the results, I had to divide Agile adoption into two stages. To date, Agile aficianados have focused on the first, Agile within the development team. Clearly, for the story of Agile adoption, that's only Chapter One.

* In this approach, the steps for analyzing social media involve people, objectives, strategy, and technology (POST).

[Cross-posted at The Heretech.]

Social media and buying habits

Forrester colleagues Laura Ramos and Oliver Young have posted some initial conclusions from the big "Social Technographics" survey for this year, which details how social media inform and influence people buying technology. You can read about the survey on Oliver's blog and Laura's blog.

Needless to say, this is fascinating stuff. The survey looks at each kind of online behavior (content creation, critiquing content, joining groups, etc.), and then tells you how much people in different segments of the population engage in these behaviors. Here's an example:

For product marketers, these data tell you how to reach your target audience. For product managers, the same information is critical for tapping social media as a new source of requirements data.

Here are a couple of important links:

Read more


Your attention is required

One of the hot topics during my visits with Forrester clients this week was requirements. How do other people do them? How do they change when development teams go Agile? Why is it so damn hard to re-use the information written for the development team for other purposes, such as training the salespeople? And so on.

I'll be starting some research on requirements in a month or so. Meanwhile, as busy as my writing agenda is, I can't help but ponder the topic. To complete the distraction, I was also reading some of Tyner Blain's recent posts on the topic, such as this interesting discussion about user stories and use cases.

To a large degree, requirements have to conform to the peculiarities of an organization. While there might be some Platonic ideal of requirements, manifested incompletely in this imperfect world of ours, there's no escaping the regular back-and-forth between the authors of requirements and their readership. Development teams have their own preferences for information, both quantity and format. You'd be a very bad product manager (and probably not employed for too long) if you were to ignore that reality.

Read more

The damned die hard

During his press conference about the stimulus package the other night, President Obama sounded tired. The source of his fatigue didn't seem to be the size of the bill he was proposing. Instead, Obama sounded burdened by the changes to American society that were required to make $800 billion worth spending. Here's a representative quote:

We are going to have to work with the banks in an effective way to
clean up their balance sheets so that some trust is restored within the
marketplace, because right now part of the problem is that nobody
really knows what's on the bank's books. Any given bank, they're not
sure what kinds of losses are there. We've got to open things up and
restore some trust.

And later:

Now, maybe philosophically you just don't think that the federal
government should be involved in energy policy. I happen to disagree
with that; I think that's the reason why we find ourselves importing
more foreign oil now than we did back in the early '70s when OPEC first

Read more

Getting to no

A popular topic among product management bloggers is, How can I say no to my customers? Christopher Cummings has the most recent musings. The Cranky Product Manager and Jeff Lash have also written about the topics--along with practically every other PM blogger out there.

Obviously, it's important to handle customers deftly when you can't comply with their requests. You'd like to keep the conversation friendly, but sometimes, the situation gets confrontational. Your diplomatic skills will face their toughest challenge.

All politics is local
I might have been unusually blessed with reasonable, understanding customers, but I never found the "foreign policy" part of saying no to be that difficult. The real headache, at least where I've worked, was "domestic politics"--what happens within your own company when you have to say no to a customer.

Read more


Proving the value of better requirements

Ever since I did the research on tools for product managers, I've been diddling with an ROI calculator for improved product requirements, which can come from two sources: (1) hiring another product manager; and (2) implementing a specialized requirements tool.

Here's the final product. Really, this is a way of demonstrating the value of product management. Product managers and PM tools are just the tangible manifestations of that business function.

[Cross-posted at The Heretech.]


The world turned upside down

Saeed asks a great question: Why not have Development report to Product Management? PM is supposed to own the business argument for what Development is doing. Why not, therefore, make the development team formally accountable to the people who are supposed to give thumbs up or thumbs down to what the developers are doing?

Saeed is asking about the pros and cons of that arrangement, but undoubtedly he's urging us to question the unquestioned assumptions about technology companies. Provocative language like this has an old vintage. For example, a couple of centuries ago, the Enlightenment thinker Denis Diderot, trying to get shake up his readers' attitudes about the divine right of kings, said, "The arbitrary rule of a just and enlightened prince is always bad." Zing!

I urge you to read the comments section of Saeed's post. Here, I'll add a few thoughts of my own:

Read more