Product Management Journal

A product manager has to be demanding. Literally: It's part of the job to demand that the product be built properly, in a timely manner. Tactfully and politely, of course. Open to suggestions and negotiation, certainly. But you still have to be demanding. Of course, it's nicer to request than to demand. At least, that's what my mother taught me, and it's certainly a lot more comfortable. Since the members of a development team usually don't report to the PM, then it's important to be on comfortable terms with the team. But that doesn't mean that demanding results isn't appropriate. A product manager is in-between groups that want timely results (management, Marketing and Sales), and groups that have to produce the results (Engineering, QA). Sometimes these relationships can become stressed, or even adversarial, if development has trouble meeting expectations. Product management, being in the middle, is often in the best (or only) position to resolve

Long ago I studied architecture by designing and constructing buildings for my college. It was a unique program, and, in retrospect, it was an agile development process. Building design is normally a classic waterfall process, so it's interesting to look at what happened... Each project was run by a professor-architect . We began with a plan that included the building program (requirements) and a basic framework for the design, with few details. Every few weeks we would get together and agree on the next part of the project, craft the details, and begin what we might now call a sprint. Every morning we would meet (our scrum): the crew of students, the faculty architect (analogous to the product owner), and our professional contractor (our scrum master). In the summer, we would meet on the site; in the winter (this was Vermont) we would meet in a small construction shack around a hot woodstove, and draw on the walls (which we would paint over periodically). Our designs were increm

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

Product Managers need to spend time with customers. On-site, where they can be observed. Alone and in groups, so that they can talk in confidence and have free-ranging discussions with each other. There's no better way to discover the customer's problems and identify product opportunities. Typically, a PM will visit customers and summarize the findings in a report or presentation. These findings generally find their way into a Market Requirements Document, and may even be read by the development team or executives. Or not. Isn't there a more effective way to share this information? How about taking team members along on customer visits? Sure, everyone's busy, and visiting customers isn't their primary job, but you may find that it's worth the effort. I've found that bringing including team members accomplishes two very important things: First, it gives them a firsthand, visceral understanding of customer problems. Listening to a customer describe th

Customers often do not say what they mean. A product manager's success depends on the ability to understand what customers really mean, and it's sometimes very different from what they're saying. Case in point: Microsoft customers frequently asked for easier ways to access and edit their Word documents, requesting numerous new Word features. Word was (and still is) a pretty complicated word processor, and overlaying a new set of features would have made it more so. But when product planners at Microsoft began to understand the actual problems that the customers were facing, it became clear that the solution wasn't at all what the customer were requesting. Instead, a new application tailored for quickly taking notes and organizing them was born: OneNote. It's been a big success among the customers who thought they wanted more Word features. I learned how to listen to customers while validating a product concept in meetings with groups of customers at 28 companie

Have you ever used a web site or service that "wasn't all there?" Maybe it looked good and did something useful, but it required that you go elsewhere to finish what you were trying to do. Travel-booking sites didn't used to have integrated maps. (Hard to believe...) Then some clever person (probably a travel-site product manager) realized that customers had a problem locating the motel they were booking, and that they were plugging the street address into Mapquest or Google Maps. Pretty soon every motel listing had a link to pop up a map, and eventually the maps were embedded into the listing itself. The product was more "complete", and it solved the customer problem more effectively. Likewise, one of the hazards in developing packaged software is the failure to make a "complete product." Simply put, if the product in the box does the whole job, then it's complete. If it requires the user to go elsewhere to do part of the job, then it'

Product managers have a lot to do - from learning about customers to working with development teams to planning business strategies. So should PMs be based in Marketing, Engineering , or "none of the above"? I've worked in all three types of organizations, and while each can work, one is better. "Traditional" consumer products companies put PM in Marketing, under the rationale that Marketing is the customer-facing part of the company. That works well for consumer products, but when frequent interaction with a development team is required, it breaks down. When based in Marketing , there's often an expectation that the PM will have significant "outbound" marketing responsibilities. Product marketing is a big, important job, and it's too much to expect a true product manager to have primary responsibility for product launches, collateral creation, advertising and the many other tasks that marketers do. There just isn't enough time left for

I had no idea what a Product Manager was until someone pointed out that I was one. In the dawn of the PC age, I discovered a program called AutoCAD. Hardly any other architects (I'm a licensed architect) seemed to realize that PCs were about to change the profession, so I wrote a book called "The Architect's Guide to Computer-aided Design" - the first book about using PCs in architectural practice. Computers were still fairly primitive, and much of the book was about how architecture could be changed by using PCs. Likewise, the columns and articles that I began writing for trade magazines explained how PC applications should support the profession. I had inadvertently taken a role as "the voice of the customer," and I began getting calls from Autodesk, their competitors, and entrepreneurs who saw opportunities in some of the topics I wrote about. One of these was a venture capitalist who wanted to develop software tools that would revolutionize building