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

Categories:

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.]

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

Categories:

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.]

Categories:

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

Categories: