Product Management Journal

The First Law of Priorities: Raising the level of one priority requires lowering the level of one or more other priorities. Otherwise, it requires changing the schedule, adding new resources, or compromising quality. This law is often very unpopular. Many managers would love to repeal it. Here's a typical scenario: The Product Manager has identified "installation user experience" as the number one priority for the next sprint. Meanwhile, Sales meets with a top customer who says he "must have" a new printing feature "immediately." Management decides that this should be added to the top priority list for the release. Obviously, something has to give. Extend the schedule? Add people for design, programming and QA? Or jam it into the existing schedule, using existing resources, and overlook the fact that quality will inevitably suffer? Unfortunately, the last choice is often the road that's taken. Why? Well, sometimes it's hard to say no. When mana...

Everyone has a different idea of what's "good enough." What's the best criteria? Getting quality right is important: products (and whole companies) have failed because a product was not good enough, or, because it was good enough and didn't get to market while it was being "perfected." It's the Product Manager's job to identify the appropriate level of quality for a product, and to see that this gets to market promptly. I once built furniture and cabinetry with a guy named Robert. He was a terrific craftsman, and had very high standards. Our woodworking shop was next to a river, and whenever Robert made a mistake, he would go outside and throw the less-than perfect piece into the river. Robert was good enough that not a lot of stuff went into the river, but he threw away things that other people would have used. And his finished work was gorgeous. I learned a lot about making things from Robert. I learned that sometimes there is a right way and ...

Quality is an issue that can never be far from a Product Manager's mind. Quality is a nebulous idea that is hard to define, let alone create. Yet a PM's approach to quality can be a key factor in the success or failure of a product. Decades ago, a computer manual writer named Robert Pirsig wrote a book about quality. Zen and the Art of Motorcycle Maintenance is the most widely read philosophy book ever written (and also has the distinction of having been turned down by more publishers - 121 - than any other best-seller in history). It contains an important insight that helps explain why product managers need to cultivate multiple, seemingly contradictory perspectives regarding their products. Using the example of maintaining a motorcycle, Pirsig explains how some people view the world through a "romantic" lens of experience - how something feels in the here-and-now. Someone with this attitude judges whether something works in a pleasing or effective way, not why . T...

What do you do if your development team can't finish the product? This is not a question that anyone wants to have to answer, but it happens. The last time I ran into this, I had taken over a new product whose development team was spinning its wheels and unable to make meaningful progress. Each iteration of the product raised new problems that seemed to slow things down further. Something had to be done, quickly. In this case, the product was in the design/prototype stage. Early-stage paralysis can be caused by several different problems: - The team doesn't understand the customer need/problem well enough - The functional requirements or design aren't clear enough, or - The team lacks sufficient design experience/talent (it's usually more tactful to call it "experience") First, make sure that the PM information is sufficient, clear, and prioritized. Go over it with the team until you're certain it's understood. Talk about the Vision too. If the team...

Product managers have plenty of responsibility, but they often have very little authority. Rarely does anyone report to them - engineering, product design and marketing are usually in separate organizations, or have different managers. So how does a PM influence product decisions? Persuasion. Persuasion isn't just a matter of being nice to people and saying please and thank you, though that doesn't hurt. It's an art that's built on several skills that can be cultivated. Articulation Information is the product manager's best friend. Data from customer research, market analysis, sales, product support, and finance is key to shaping smart policies, and then persuading others that they make sense. Opinions may make for good conversations, but facts persuade. Persuasive data comes in all shapes and sizes. Certainly a quantitative survey can provide a solid foundation for a recommendation, but so can an informal conversation with a customer if it is set in a context that...

When you have to explain something to people, you may automatically whip out PowerPoint. And you may load it with bullet points, ready to shoot the audience into submission with facts. If only effective presentations were so easy... We've all seen too many awful presentations. Boring all-text presentations. Clipart-infested shows that had no real purpose. These things happen often because PowerPoint makes it so easy to create really bad presentations. You have to work hard to avoid this trap. Gauging the Situation While there are several wrong ways to present, there's no one right way, because different situations call for different types of presentations. Your presentation style needs to adapt to: - The audience (i.e. colleagues vs. industry analysts), - The venue (conference room vs. auditorium) - The time available ( a few-minute report vs. multi-hour seminar) - The content and media (no visual content vs. photos, charts, animations or movies). Each combination r...

A big part of a Product Manager's job is to describe the functionality that will result in a successful product. There are a number of formats for doing this, including MRDs, PRDs, Functional Specs, Technical Specs, Backlogs. They're all descriptions of What Is To Be Done. And they all too easily end up on a shelf, while something else is done. What requirement documents are really necessary? As I'll explain, it's the process, more than the name of the product, that really matters. First, let's look at the intent of some of these documents: A Market Requirements Document (or Customer Requirements Document) is intended to describe what is necessary to successfully compete in a given market, and describes that market in detail. A good MRD is focused on the customer and the competition, and defines the business opportunities that a product might address. In defining market segmentation and size, it may include aspects of a business plan. It may describe the high...