Take responsibility for what, not how

If you want to be a bad product manager, focus on how your product’s requirements should be implemented. You need to make sure that not only the right features get implemented, but that they get implemented in the right way. If you don’t specify it, someone else will decide how to do it and their decision might be wrong. Make sure to put plenty of detail into your requirements so the other members of the product development team know exactly what they’re supposed to do.

If you want to be a good product manager, focus on what requirements should be in the product in the first place. Product managers are responsible for what the product should do and other roles are responsible for how the product should do that.

So why do product managers often spend a lot of their time on how the product should work? A few reasons:

• If no one else is specifying or is available to specify “how,” product managers will need to do it.
• Product managers may know they should not be specifying “how,” but for whatever reason do not trust other roles to do it.
• Product managers may not realize that they should be focusing on “what” and not “how.”

Some feel that a product manager should be specifying how a feature should be implemented, and to that I ask: then why are all the other people on the project? Why do you have a user experience designer if the product manager is specifying the details of the design? Why do you have a software architect if the product manager is specifying the database technology that should be used?

While it may be easy to accept this concept in theory, in practice it is more challenging. Here’s an example:

• The web site must allow users to find all CDs under $10 (WHAT)
• The web site must use faceted classification to allow browsing to CDs within specific price ranges. The links should be displayed in 12 pixel Verdana and have no underlines. (HOW)

This is a fairly clear example but there can frequently be some ambiguity. It can be helpful to analyze your “what” to see if they are really describing business or customer objectives. “Finding CDs under $10″ is an objective, while “using faceted classification” is not.

In his post on What versus How, Roger Cauvin discusses “how difficult it can be to distinguish between requirements and design.” (It’s hard to summarize his comments and insight here, so I’ll just recommend you read his insightful thoughts.)

The SCRUM approach to story writing (“As a ________, I want to _________ so that I can __________.”) is a great way of understanding whether something really is a “what” or a “how”.

e.g. As a bargain shopper, I want to see all CDs under $10 so that I can find music within my budget.

“I want to” is a great lead in to “what” and a lousy lead in to “how” — it would be obviously too much detail and forced if it read:

As a bargain shopper, I want to select from a dropdown menu with an indented heading reading “CDs under $10″ so that I can find music under $10.

Also, attaching an explicit benefit makes sure that everyone on the product development team understands why you are building the specific feature. What is the value to the customer? Does it leave room for designers and developers to come up with various solutions that allow them to create that value, or is it so specific that it’s essentially describing a specific solution?

Understanding the distinction between “what” and “how” is one of the most challenging aspects of product management. As a product manager, you need to clearly understand what your product must do and communicate that clearly to the product development team. You also need to trust the judgement of the professionals you work with to come up with the best solutions for how the product can accomplish those goals. Learn to balance these forces and you will be well on your way to being a good product manager.