Product Management Journal

The Hub

2011-05-18T10:53:00.000-07:00

The role of the Product Manager is unique in the business world, particularly in technology companies. No one else is responsible for working with so many different disciplines - Engineering, Marketing, Sales, Support, executives, and others - on a daily basis. The role is really the hub of the product organization, and the strength of the hub is the key to how well a wheel rolls.

I've seen Product Managers perform in very different ways, with different results for the organization. Some of these include Reactors, Coordinators, and Initiators.

A Reactor is a PM who waits for balls to be thrown his way, juggles them as they arrive, and returns them or passes them along as quickly as possible. A reactive PM is often overwhelmed by demands from different directions, and is rarely able to inspire new strategies or lead new initiatives. PMs tend to fall into a reactive role through a combination of overwhelming external demands and difficulty prioritizing them.

It's important for a Reactor to get out of this mode. First and foremost, it requires determining what projects and tasks are most important to the business, and focusing on these. This sometimes means taking a difficult stand regarding less important roles and tasks - some of which may be considered urgent by their owners. It may be necessary to say "no" to a Sales request, and then make sure that both the requestor and the PM's manager understand why, as well as when the request might be addressed.

Unfortunately, it is common for PMs to be given responsibility for multiple products or very large/complex teams. The multi-product PM becomes the hub for several wheels - maybe even all the wheels - and must find ways to keep things rolling. The more balls that a PM has to juggle, the harder it is to make good decisions about each one. This may mean reducing the number of products each PM is responsible for, or prioritizing them.

Only by focusing and getting out of reactive mode can the overwhelmed PM succeed.

A Coordinator is a conduit for passing information, opinions and decisions from one part of the team to another. Typically a Coordinator PM has (or exerts) little authority, and often works within an Engineering or Marketing organization. This PM can play a valuable role of propagating a vision that's developed by management, by ensuring that Marketing and Engineering are in synch regarding product plans and expectations, and most importantly, by gathering and communicating customer requirements. The Coordinator role is most effective when the PM is able to effectively interpret between the players, explaining Engineering's schedules to executives and clarifying/ prioritizing customer requirements. It's also appropriate when an executive is a visionary and/or market expert, which is common in many start-ups.

The most effective Coordinator PMs act as a facilitator between teams, actively resolving conflicts and solving problems. In this role, the PM serves as a hub that constantly monitors the spokes of the wheel, making adjustments as needed. This is where the real potential for great product management begins: The PM is the only person who is truly in a position to see what is going on in every area that affects the product, and is thus the best person to identify and solve problems.

An Initiator goes one step further: this PM is a leader. An Initiator understands the business strategy, the customer requirements, the marketing strategy, and the capabilities of the development team, and synthesizes tactics that take advantage of this broad knowledge. An Initiator PM sees a customer problem, knows that there is no adequate solution in the market, sees how a product concept might fit into the company's business strategy, and recognizes that the development team has the ability to solve the customer problem in an effective way. In this fashion, the Initiator becomes the source of the product vision, and the one who drives it to successful completion. But an Initiator plays this role in many smaller ways that are nevertheless significant. In every team meeting or executive briefing, an Initiator is looking for ways to advance the cause in leaps, rather than in small steps. This PM is the one who sees all the sides to a problem and cobbles together an approach that would not be obvious to someone with the narrow view of, say engineering or marketing. Needless to say, this is the PM who is most likely to be responsible for breakthrough products.

There's a sub-type of Initiator PMs that bears mentioning. Some product managers are sufficiently adept at product planning or product design that they are Inventors. As the source for innovative ideas, they can bring a product from concept to completion by designing it and working with the team to develop the concept into reality.

There are pitfalls to being an Inventor PM. Getting too involved in the details of development can get in the way of the never-ending task of understanding and interpreting the customer's needs. Sometimes Inventor PMs take inordinate pride of ownership, leading to turf wars with development. Nevertheless, a PM who can make significant contributions to the product concept and design can be a valuable commodity.

These different product manager roles are not just a matter of the PM's personality. They also result from an organization's structure and expectations. Each company has a different idea of what the hub of the wheel looks like - some expect a low impact Reactor, while others demand an Initiator. It's important to find the right fit between individuals' capabilities and company expectations. But it's also important for companies to give a good, hard look at what kind of hub they really want on their wheels, and ask whether they are giving their product managers the opportunity to make the wheel as efficient and effective as possible.

Just Saying "No"

2011-04-05T10:41:00.000-07:00

"No" can be the toughest word to say. Nobody likes to hear it. Executives generally hate to be told "no." But sometimes it's the most valuable word in a product manager's vocabulary, especially when it makes "yes!" possible. You can't build all your ideas, so someone has to say no to some of them. That means saying yes to the right ones.

Any good product development organization has more good ideas than it can possibly execute. Sometimes the ideas come from executives, sometimes from engineers, sometimes from customers and sometimes from product managers. It's the product manager's job to understand the company's business, the market situation, the customers, and potential customers well enough to make a case for what gets a yes or no (or a "later"). Each case will involve many factors - business goals, investment issues, sales considerations, competitive conditions, technology opportunities and development resources - and they must be well understood and examined clearly. Strong cases will be made for competing initiatives, products or features. How do you decide to say no?

First, know what business you're in (or what business you want to be in). A decision to move to another market or product type may be appropriate, but sometimes it's outside a company's area of competence, or it's a distraction that can derail an existing business. For example, the landscape is littered with B-to-B companies that tried to move into a direct-to-consumer business, and vice versa. Product decisions have to make sense within an overall business strategy.

Second, know what you're capable of doing. A good idea is worthless if you don't have the resources to do it, or if it forces you to pull critical resources from another key product.

Third, know what you want to do that will make you successful. What makes your company or product special? What makes (or will make) you a market leader? Do that. What problems detract from your strengths? Fix them. Does a product or feature idea seem like a "nice" addition that doesn't reinforce your vision and distracts your staff? If it's not part of your strategy (you do have a strategy, right?) just say no!

This third point is crucial to running a focused company that develops a vision and brings it to market. It sometimes means saying no to good ideas that don't advance the vision. It sometimes means saying no to customers who are ready to pay for something that isn't part of your business strategy or product strategy.

Saying no to a customer who is ready to pay you is a classic dilemma. "If you add these new features, I'll buy one for everyone in my company!" says the customer. Sales is excited. Even though you had previously decided that the features weren't sufficiently important to include in the product, there's now an incentive - cash! - to add them and delay something else. But if your initial decision that most of your market doesn't need the features was correct, you could be letting down other, less vocal, customers, in order to please one who is waving cash in your face. And you may be giving a competitor a chance to pass you while you work on less-strategic features.

Companies that don't know their customers well have trouble saying no. Often they don't know which customers they need to please, from a strategic point of view. Or they just don't know what's really important to satisfying customers, and are unable to differentiate important customer requests from trivial ones.

I learned an important lesson from an innkeeper who is frequently asked to host guests who are in towns for weddings. She has figured out that these guests are often overly celebratory and make other guests uncomfortable. Even though she could book many wedding-related guests, she realized that it makes her inn less desirable to couples who are looking for a quiet getaway, and has a "no weddings" policy. Even though she is turning away thousands of dollars a year in business, she decided that by saying "no" to customers that don't support her business strategy, her business will be stronger and ultimately more successful.

Sometimes "no" is really "not yet." I once developed an online collaboration product that had a carefully staged roadmap, beginning with a rollout to small workgroups and building to an enterprise product over time. The sales force knew that the real volume lay in enterprise sales, and pressured executives to instruct us to release an enterprise product immediately. But we had designed a gradual rollout for good reasons, both technical and marketing. It was important to build a solid, scalable product, and have it succeed in small installations, before taking on large enterprises. We stuck to the roadmap, convinced Sales that it was in their interest to be patient, by saying "yes, but not yet."

A no can lead to new ways of saying yes. When I told an executive that we couldn't start a new project without derailing our current product, we brainstormed what it would take to start a new development effort by taking advantage of some underutilized resources and raising new investment to hire a new engineer and some contractors. I put together a plan and a presented it to our investors, who agreed to an additional investment to get the project started. It eventually led to a new line of business, but it never would have happened if we had not had the discipline to say no to an initial strategy that was doomed.

Knowing how and when to say no applies to defining a business, creating a product strategy, or choosing a feature set: By saying no sometimes, you can say yes! to the things that are really important. And that's really important.

Agile Thinking

2011-03-11T10:11:00.000-08:00

Agile development processes have had a pretty big impact on product management. An agile product manager has to be adept at bringing clear customer requirements into an iterative development context. This can be a terrific opportunity for product management and engineering to innovate during the development process. But I've found that this kind of agile approach can be applied to a more traditional development process, too.

In an agile world, a product manager (often serving as product owner, as well) is responsible for delivering customer requirements in the form of use cases as the team goes through a series of rapid development cycles. The product design may change after (or even during) each of the sprints, so the PM is responsible for restating the customer requirements in the new context, as well as creating new use case examples. All the while, the PM must keep the product vision and goals at the forefront.

In a traditional "waterfall" development process, the PM would create a prioritized list of features, which the team would build over a period of months or even years. The PM's role is then primarily to clarify the customer requirements, as needed, and work with the team to ensure the goals are met. Changes to the specification are generally discouraged. This works well when the design is excellent and the market/competition isn't changing rapidly, but it can be a problem when design or usability issues are discovered, or when a competitor introduces a new release in the middle of a development cycle.

Waterfall development grew up when software was often monolithic and inflexible, and user interfaces were built laboriously. Of course, the internet, HTML, XML, Flash and tools like Ajax and Rails did not exist. The world has changed.

Prototypes can be developed rapidly, and discarded if necessary. Working products can be built in days or weeks. Product design can be tweaked iteratively as a development progresses, based on usability testing. QA testing can be ongoing during development. Customers can use a product long before it's "finished."

This sort of iterative development is discouraged or forbidden during a traditional process where a spec is "signed off" and the product must be built to match the spec. An iterative approach, on the other hand, provides constant opportunities for innovation. A product design can evolve over time and (as in any true evolutionary process) a failure is a valuable lesson that can be quickly corrected.

"Going agile" is one way to achieve this iterative process. But fully agile development, with an elaborate process of scrums, sprints and daily standups, is beyond the capabilities of some development teams. Sometimes the culture doesn't support it, in other cases a distributed, virtual team can not be truly "agile" from multiple locations around the world.

That's OK. By applying agile thinking to a more traditional development process, it's still possible to build products and achieve the kind of rapid innovation that agile development promotes - even on a project that requires a longer release cycle, such as a packaged software product or new web service. The trick to a "semi-agile" approach is to work closely with Engineering to plan development so that there are milestones at which the product is testable, and schedule checkpoints for evaluation and modification.

Here are some key things to focus on:

- Most importantly, the whole team, including management, must buy into the idea that there can (and should) be iteration during development. It's less predictable, can take more time, and it may reduce the number of features that can be built for a release, but the benefit should be a product that is more usable and more robust. It can also be less expensive in the end, because it's almost always cheaper to recognize and fix problems sooner rather than later.

- Specifications must be viewed as flexible documents that can change, rather than as a rigid "contract." In general, the "what" should be fairly stable, but the "how" (especially the user interaction design) may evolve. This requires a high degree of cooperation between Product Management and Engineering.

- For complex projects, functional specifications should identify and prioritize releases that are complete, usable feature sets (rather than just individual functions) that can be built as discrete, testable components. Individual feature teams may be able to develop their own working modules. This will require close coordination with Engineering.

- Describe specific use cases for the product. Prioritize them and create a backlog. Link them to features and feature sets. And update them as the product design evolves.

- Use prototypes. In some cases, the best "spec" will be a working prototype of a feature or component. Working prototypes should be developed quickly by product designers and engineers, and tested on real users (or, at least, on people who are not developing the product). Design iteration should follow.

- At an evaluation checkpoint, the product manager should plan to work very closely with the team to revaluate priorities, decide whether any redesign is required, and revise the customer use-cases if necessary. Sometimes a release may be deemed ready-to-use, but improvements will be identified and put into a backlog for future work.

- The user experience designer should participate throughout the project, especially when a prototype is evaluated.

- Project Management should plan phases and milestones that include "checkpoint, evaluate and redesign" points. If these are not in the plan at the start, they're unlikely to be added - they'll be seen as unacceptable delays, no matter how beneficial. Because iterations can become open-ended, project management is especially important for keeping development on track.

Rapid prototyping, rapid development, and "lightweight" usability testing provide more than opportunities for fine-tuning a product. An iterative development cycle encourages innovation by the entire team, which is less bound by traditional specifications. Success requires the wisdom and discipline to know when to iterate the design and when to move on. It also requires a strong vision and clear roadmap from Product Management.

"Semi-agile" development isn't for everyone. Some organizations are committed to a "spec as contract" approach, with rigid milestones. Other teams are well suited to "full agile" processes, and can realize all the benefits of the "sprint/scrum" approach. But for those in between, "agile thinking" can result in better, more usable products.

Which Customer?

2011-02-09T17:36:00.000-08:00

Everyone agrees that it's good to listen to what your customer wants. But which customer should you be listening to? This can be a surprisingly difficult question to answer, and getting it wrong can have unfortunate consequences.

Most companies have many types of customers. They can be sorted according to purchasing power, loyalty, enthusiasm, early/late adopter, knowledge, purchase frequency, and many other characteristics. You can also add in potential customers, who are often the key to success, but you may not even know who they are yet.

Some customers will let you know what they want. Some are articulate. Some are loud or persistent. Some are brutally honest, while others try to ingratiate themselves by telling you how great you are. Others, you will never, ever hear from.

There are several traps that the most well-intentioned people can fall into. Here are some customers that we're always tempted to listen to, and then try to please:

The squeaky wheel. This is the person who complains the loudest and most frequently. We want them to be happy, and sometimes we want to satisfy them so that they'll be quiet.
The fattest wallet. This is the customer that Sales wants to please, for obvious reasons. But making one fat wallet happy may mean disappointing hundreds of other customers.
The most recent customer. After you (or your CEO) talks to an articulate, thoughtful customer, it's tempting to take her ideas and start working on them. Regardless of whether or not her ideas should really be your top priority.
The most customers. This one's tricky. Let's say you get emails from hundreds of customers about an idea, far more than about any other issue. It must be important, right? Well, it may be safe to assume it's important to customers who write emails, but is that who you have to please to succeed? And does a chorus of agreement even mean that this issue is really the most important issue to these people?

Who do you listen to?

The single most important thing you can do is identify, and remember, who your target customers are. These are the people that you must satisfy in order to succeed. You need to understand their needs, their desires, and even their personalities. Picking your target customers is central to developing any product. There are many factors to consider, including things like customer need, the competitive landscape, readiness to purchase, pricing factors, access to sales channels, geography and culture, etc. It's an ongoing process - customers change, the market changes, and you have to continually readjust your target.

Once you know who you have to satisfy, in priority order, you need to keep this in mind whenever you seek or evaluate customer input. Go ahead and gather information from all kinds of people, but be sure to weigh the results according to your priorities. The most effective thing that you can do, though, is talk to the most important customers in the first place. Your time is limited and valuable - spend it with the people that you need to hear from.

However carefully you plan your research, you will still run into different personality types and people who care about very different things. That's good, as long as you can balance their input wisely. Don't let the squeaky wheel lead you away from the quieter wheels - they matter too. This is particularly important in a focus group or online forum - strong personalities can influence or intimidate less-forceful people, and it's up to you to ensure that these folks have a voice.

It's important to prioritize what you hear. Often, different types of customers will have very different priorities. By asking customer s to rank their preferences in a questionnaire or in-person "$100 test," you'll get a good idea what they consider most valuable. You may find that, for example, your top-priority customer's second highest need is the most important feature for all your other customers, and decide to make that feature your development priority.

No matter who you are listening to, it's important that you, as a product manager, don't take people's words at face value. Don't fall into the trap of doing what the customer says. It's your job to understand what's behind the customer's words and requests, and interpret them. Figure out what the customer's problems and desires are, whether or not they can articulate them. A request for one thing may actually be hiding a need for something very different.

Finding the right customers, then getting inside their heads, is the essence of great product management. Identify. Listen. Interpret. Understand. Then act.

What Business Are You In?

2011-01-22T09:27:00.000-08:00

It's pretty hard to develop the right products when you're not sure what business you're in. Or what business you're not in.

A few years ago I joined a small company and was asked to design a new delivery platform for their content and interactive applications. The platform, which would manage user profiles and transactions over time, needed to be a very sophisticated system that would underlie all the company's products. I diligently began investigating the user requirements and existing products that did similar things.

As I gathered data, I realized what a large undertaking this would be. I talked to the development team and began to get an idea of the resources that would be required, and did some thumbnail calculations. Something was wrong.

The company's strength was in developing interactive content - video and accompanying web-based activities. While a new back-end platform was clearly needed, this was not something that they had experience developing. They could not afford to hire new staff, and moving people to a major new product would have derailed the mission-critical content production work.

I began a series of discussions with the VP of Technology and the CEO. The topic: "What business are we in?"

It took a remarkably long time to answer that question. In retrospect, the question could have been answered in a few seconds, but the execs first wanted to explore the follow-up question: "What business do we want to be in?"

The answer to the first question was that the company was in the interactive content business, in a very specialized niche. The answer to the second question was that they wanted to continue to be in this business, and increase the number of products and customers by doing what they knew how to do well.

A third question was implied: "What business are we not in?" Once the first two questions were answered, we quickly determined that the company was not in the business of developing delivery platforms. Sure, we could do it if necessary, but there were numerous companies already building this technology. Why divert precious resources to something that wasn't in our primary focus?

Fortunately, there were companies that we could partner with to obtain this technology, and my focus shifted to that task. Enormous amounts of effort were saved, and the development team remained focused on producing great interactive content.

It's not always easy to be clear about what business you're in. Everyone thinks they know, but they may actually think different things, based on their perspective - Sales, Engineering, and Management may have different views on the same thing. (Think about the fable of the blind men and the elephant…) Organizations often craft mission and vision statements to forge an organizational consensus, but these are often so general and "inclusive" that they provide little real guidance, particularly in understanding what isn't part of the mission or vision.

Who should make sure that an organization really understands what business it's in? Ultimately, it is senior management's responsibility, but since Product Management's role is to understand the business, the customer, the market, the products, and the capabilities of the development organization, PM can play a key role.

As I discovered, just asking the question at the right time can have a profound impact. And by providing data and perspective to help answer the question, product management can play a vital part in focusing and articulating the direction of the business.

The Vision Thing

2010-12-07T15:30:00.000-08:00

A US president once said he wasn't very good at "the vision thing." (He wasn't re-elected.) Product managers can't afford to be anything less than great at the vision thing.

The product vision is the glue that holds a team together. It's a great tool for herding all the development, marketing and executive cats in the same direction. But it needs to be sound, it must be straightforward and compelling, and it needs to be communicated well and often.

A product vision is pretty much what it sounds like: something that enables anyone to see clearly what the product is, does, and who it's for. Beyond that, there isn't really a formula for defining a product vision - it's the product of good research, clear analysis and, most importantly, imagination.

A good product vision usually seems obvious in retrospect:. Take the iPod:
An elegant-looking pocket music player that non-techies could learn quickly and easily download songs from an online store…and that people would love to use.

The last part is important, since before the iPod, most MP3 players were clunky and awkward to use. Part of Apple's vision was to build a product that would generate passion and loyalty, and they succeeded.

The value of a vision like this should be clear: once it's accepted, everyone on the team, from the CEO to individual engineers, is working toward an identical goal. If, for example, a feature doesn't support the vision (in this case, perhaps making the iPod harder to use), it's not likely to be pursued. A well-defined vision could be the starting point for a marketing plan. And any time there's a question about strategy, the vision provides common ground for decision making.

A sound vision rarely springs fully developed from a visionary's mind. Instead, it's usually based on knowing potential customers really well, learning about their work/play habits, and understanding their problems. It takes into account market conditions: what are existing products like, and how do they succeed or fail (from the customer's point of view). A sound vision is usually based on knowing the potential and limitations of available technology, though some visionaries are unafraid to push these limits and develop new technologies to support the vision.

A sound vision is also based on a deep understanding of a company's business strategy. It may extend the strategy, but rarely does a successful vision start from scratch (except, of course, in a startup company). A company's brands, culture, processes, customers, and sales channel provide the context within which a product vision is cast.

A straightforward vision takes these factors into account, but it isn't a lengthy PhD thesis. Instead, it needs to be extremely concise, boiling down analysis and context into an easily-understood solution statement. No need to explain why customers are having a hard time finding the right song to play - just say that it's going to be simple and fun to do this. There's no need to design the product in the vision statement: you can be sure the iPod's wheel interface was not part of the vision, though it grew from the vision's dedication to simplicity. A good product vision stimulates designers to invent solutions that go beyond the original intent of the visionary.

A compelling vision inspires passion. Explain it to an executive or a new team member, and they should react, "wow, that's great, let's do it!" It's an idea that can be recalled to focus people during a difficult, contentious meeting, by saying, "remember, here's our vision…we're all working toward the same goal here."

Communicating a product vision effectively is the key to building consensus around it. There are many ways to share it, whether a well-crafted "elevator story," or a few PowerPoint slides that use words, graphics and images effectively. Regardless of the medium, a well crafted vision probably contains these items:

- A sense of who the product is for.
- A statement of the problem or need it will address.
- An explanation of why the customer will care enough to want the product.

Sometimes the best way to do this is through storytelling. Tell people how a customer will use the product, what they can do, and how they feel about it. Chances are, a good story will enable everyone to envision the purposes of the product clearly…and that's the point.

In some cases, a vision might also include a preliminary prototype that illustrates a concept. (Mary Cagan calls this a Visiontype.) The idea is to show what a product would do, without implying a final design. It should be framed in such a way that people can say "I get it" without concluding the final product must look or even work like the prototype.

Who, exactly, is the visionary that creates the vision? It may not be the product manager - many companies have visionary engineers, marketers or executives. But it is the responsibility of the PM to clarify and communicate the vision, and to ensure that every team member knows and remembers it.

A clear vision is, most of all, a leadership tool. And if a US president didn't understand this, it's easy for PMs to forget it too. Product management is all about leadership, and you can lead more effectively if you and your team know where you envision going.

Focus Groups, and Unfocused Groups

2010-11-06T10:56:00.000-07:00

Sometimes useful revelations come from focus groups. If you ask the right group of people really good questions, you can validate (or disprove) a theory. Sometimes you can identify customer problems that provide opportunities for new product solutions. Sometimes. The trick is going in with the right expectations, and knowing when alternative methods, such as customer interviews and surveys, may be better.

I've used focus groups to explore customer attitudes, and to validate the viability of product concepts. Careful questioning about "how you do it now" can be useful, especially when the group becomes engaged and discusses their personal experiences. This is where focus groups can work: getting people to open up, describe their experiences and compare notes about current problems. (Important note: Having a top-notch moderator is essential: if you can't shut down a loudmouth, your group will be a waste of time. But it can be hard finding a good moderator who understands - or takes the time to learn about - your business.)

The problem with focus groups is that they can easily distort the participants' opinions while giving the impression that they're being "focused." This happens because a mirrored room full of strangers is very different from real life, and it's very easy to be influenced by a group of strangers who are trying to impress the people who are hidden behind the mirror. One person's well stated opinion can become the groups' opinion, even if it is contrary to the views that the others had beforehand. This is very dangerous.

I once listened to a focus group participant describe how much he liked using a new 3D mouse. He was the only person in the group who had done so, and everyone wanted to hear about it. The moderator treated him like an expert on the subject. After the session, I caught up with him at the sandwich table, and asked him about the software he was using with the device. He didn't know I was one of the people "behind the mirror." He told me "Well, I don't really have one, but I watched a demo at a trade show and I thought it looked cool." He was not the first, or the last, to stretch the truth in a focus group.

There's also a danger in expecting too much from participants. As soon as you start asking "how would you use this new gadget/program/website?" you're asking people to imagine how something that's new to them would fit into their work/home environment, while talking to people whose own circumstances may vary greatly. Speculation in a focus group is rarely valuable. People are usually trying to be "helpful" and they don't want to be seen as criticizing what could be the "next big thing."

A focus group is not a usability test: asking someone to use a product in this environment is often a waste of time. (Getting visual or tactile reactions to a product design, on the other hand, can work in a focus group, with the caveat that many participants are reluctant to disagree once someone ventures an opinion.) Nor is it the place to ask customers to design solutions to their problems - that's the product team's job. If you can improve your understanding of the customers' problems in a focus group, consider it successful.

Web-based focus groups are a new variant. They're like group chat sessions, with a moderator and, usually, a presentation or video. Participants can voice (OK, write) their ideas and opinions, and respond to each other. It's a bit cumbersome, and there's a danger of the fastest typist or most eloquent writer dominating the group. But with well-chosen participants and a good moderator, this can be a useful tool. One big advantage is that it's much cheaper than a live group.

Traditional focus groups are an established marketing tool that can be valuable, but are always expensive (and profitable for providers). If you schedule one every time you need "customer data", you won't get a complete picture of your customers. Don't use them when 1-on-1 customer visits, onsite customer roundtable discussions (with people who work together), surveys or usability tests would serve better. But when you need background information on your customers, want to hear a discussion by a group of people within a market, or when you want to see people's reactions to seeing a product for the first time, a group may help "focus" your thinking.

Final note: I once was a participant in a focus group that watched the pilot episode of a new TV show. The group, including me, hated it. The consensus was that it would be a flop - though the consensus may have been driven by the most vocal participants. The show? Seinfeld. Yup. Was the group a failure? Maybe not, because the show that reached the airwaves was much better. I think they took some of the criticism to heart and changed it. If so, those focus groups were money well spent!

Surveys: You Get What You Ask For

2010-10-18T08:56:00.000-07:00

Recently a product manager mentioned that he was doing a "quick little survey" of his customers. Being the curious sort, I asked "how quick and how little?" and he said "oh, with Survey Monkey I can do a thirty question survey in a couple of days."

I let it go at that, but I could have asked "should you do it in a couple of days?"

Yes, it's possible to post a survey and get results very quickly, especially if you have a pre-identified or captive audience, especially if you limit it to two or three concise questons. But if you whip up a few dozen questions and expect to pop the results straight into PowerPoint, you may be disappointed.

First, asking the right questions is tricky. If you ask too many, or they're too complex, people won't complete the survey. Worse, if you ask ambiguous questions, you'll get answers that may be impossible to analyze, or may even mislead you. It's crucial to use the target person's language, not industry jargon. If the respondent has any doubt about what you meant, the answers are not reliable and should be dumped.

Stick with clearly worded multiple choice, yes/no or "scale" (high/low, frequency, etc.) questions, rather than open-ended or essay questions. You'll get a much higher response rate. It's often a good idea to give an "out" option, such as "I don't know" or "not applicable" - otherwise, people will select incorrect options because they have no other choice.

There's an art to framing concise questions that are easy to answer but cut to the heart of the relevant issues. The key to success is refining your questions down to a the minimum number of questions, while using clear language not asking about more than one data point in any single question.

The wording you use may have a huge influence on the answer. Professional pollsters know that they can slant survey results by phrasing a question certain ways. For example, asking "is the sky blue?" may produce a very different result from asking "do you believe the sky is actually blue?" or "what color is the sky right now?" Do you want answers based on experience, opinion, hearsay, personal wishes, scientific fact, religious belief or some other criteria? It's easy to influence the answer by building assumptions into the question, or by leading the respondent to a specific answer, whether intentionally or not. That may be poor polling practice, but news agencies do it frequently.

Second, it's important to pick the right audience for a survey, and figure out how to reach them. The more targeted your survey is, the more useful it will be. Usually the best audience is your target customers, though it may focus on buyers, system administrators, or some subset of users. If you don't have an easy way of reaching these folks, such as a customer email list, you'll have to go out and find a way. Doing this effectively can make or break a survey - you want a high response rate, but surveying the wrong people can be worse than getting no responses at all.

Third, once you've run the survey on Survey Monkey - the easiest part of the process - you'll have a pile of data to analyze. You can create a set of quick graphs of individual questions using Excel or Survey Monkey's built-in tools, and you can quickly show "how often do respondents use our product?" But the real payoff comes when you do crosstabs - asking things like "how often do respondents who frequently use social networking sites use our products?" This is where you can begin to paint detailed portraits of your target customers. Analysis is, in fact, the most creative part of conducting a survey.

Of course, if you've asked open-ended or essay questions, you'll have to do one-at-a-time analysis and reporting. You'll get the benefit of hearing answers that you might not have thought of, in the respondent's own words, but this analysis can be daunting in a large survey.

Finally, presenting your data is both a challenge and an opportunity. You can choose to communicate everything you've learned and help your audience draw conclusions. Or you can pick the information that you feel is most valuable. As soon as you begin to edit, you become very powerful: the picture you choose to paint will likely have important consequences. If you asked an ambiguous question and choose to interpret it a certain way, you may be bending the truth a bit. Likewise, if you omit responses that don't support your business case or product plan. Choosing what to present, and how to present it, is often the most critical part of the survey process.

The next time I see the PM who's planning the "couple of days" survey, I'll be curious to find out how long it actually took. Thorough surveys usually take weeks to plan, run analyze and present. It can be worth every minute of it, while the results from sloppy surveys are often not worth the few hours spent on them.

Feedback is Where You Find It

2010-10-06T13:26:00.000-07:00

Recently I was talking to a PM from a consumer products company. I mentioned that the feedback for his products on Amazon was pretty good. He looked a bit offended, and said "that's not very scientific - we try not to pay too much attention to it."

There are a LOT of customer comments about his product. The majority are good, some are not so. As a sample of his customers (and possible customers), he's right that it's a pretty atypical group. But worthy of being ignored?

There are two kinds of people who write customer reviews on the web: Those who tried the product and have a really strong opinion, and those who have a really high opinion of themselves and want to share their every thought. Kind of like bloggers and twitterers. And people will review almost anything - software, MP3 players, music, books, deodorant - you name it.

Actually, there's one other type of contributor: People who review their own products or competitors products. But we'll ignore them while noting that they can really skew a small sample.

Customers with really strong opinions may not be typical customers, or even close to typical, but they are worth listening to. If your product delighted (or inflamed) someone enough to get them to write a review, well, maybe you should pay attention to what they're saying. Especially if a number of people say something similar - this is where you know you're getting something really useful. Maybe your product's installation is a bit clunky - you'll hear about here. The key thing is: these are people who might never bother to complain to you, the creator of the product. But they'll post online.

Web forums are similar, and maybe even more useful, since that's where people go to ask questions if they can't get straight answers from your tech support line. Forums have been around forever, or at least as long as most of us can remember. They're a tried and true method of staying in touch with customers, and smart companies not only promote and sponsor forums, but they actively encourage staff to monitor them and answer questions. (Well, sometimes it's important to make sure that the right people represent your product in customer forums - sales people and developers love to talk about the cool things that are coming in the future, and that might not be the best thing to post just now.)

And, of course, your products are being discussed on blogs, Facebook and Twitter. If you're the PM for the iPhone or for Windows, it may be a bit much. But if you're hungry for customer opinions, they're out there. The trick is to keep it in perspective by keeping your target customer segments in mind and not letting the emotional posters carry the day. Sometimes you have to draw lines and say "this fellow has a point, but his problem is not a development priority for us. And next time you run a survey, ask your customers what type of web feedback they have given, if any. Then you can begin to map what you see online to your actual customer segmentation.

Oh, and one other thing: even if you aren't reading this stuff, your sales guys are. And probably your executives. You might want to check it out now and then.

Who Needs a Roadmap?

2010-09-19T14:59:00.000-07:00

Who needs a roadmap? Anyone who's going someplace they haven't been before. And creating or enhancing a product is always a new journey.

A product roadmap explains where you're going, and describes your routes and stopping points along the way. Its purpose is to get you where you want to go.

It's not, however, a list of what you're packing in your suitcase or what you're going to eat at each rest stop.

A good roadmap lists the high level functionality that is intended for each product release, as well as the reason for choosing this configuration. The reason shouldn't just be "we have to build function A before function B", but instead should explain why the release configuration will make sense to customers…and why it will excite them enough to use it, buy it, or upgrade. The roadmap should name the release - not with numbers or code names, but referencing target markets or personas ("the health services release" or "the system administrator release") or feature sets ("the text formatting release").

The roadmap isn't product specification. It's not a multipage spreadsheet. The more concise it is, the better. The feature list for a release can change without the theme of the release changing. It's also not a schedule or project plan: dates can change without substantially effecting the roadmap.

Here are some reasons why every product should have an articulated roadmap:

Product releases - the stopping points on your route - are critical elements of your long-term product vision. If a release is "whatever features are ready to throw in", then you may find yourself stopping someplace where you don't want to be. Or somewhere your customers don't want to be. Better make sure you make the release points worth stopping at.

A roadmap is one tool (among others) for building the product vision. It's something that everyone on the team can refer to when they want to see, at a glance, the
results of your feature-set prioritization.

If every decision maker on the team (and that includes leads from Engineering and QA, as well as executives) has a chance to review and comment on a roadmap before it's finalized, the roadmap becomes a tool for fine-tuning the strategy and for
building and maintaining team consensus.

Routes change. Detours happen. The clearer your map is, the more effectively you can adjust it and create a new route.

Next time you start a project, make sure you've got a map, and don't leave home without it.

Consistency vs. Innovation

2010-08-26T09:59:00.000-07:00

One of the most vexing user experience questions is: When must applications be consistent with each other? When is it OK to invent news ways of doing things that require users to relearn established methods? There is rarely an easy answer, but a Product Manager can play an important role in making these decisions.

Most of us assume that it's a good thing when a mouse click performs the same action in different applications. Few of us miss the bad old days when every word processor had its own conventions, and there were no Windows interface guidelines and web interaction conventions. De facto standards have been created by successful products and suites, such as Microsoft Office and the Adobe suites. If you've learned one application, you've learned most of what you need to know to use another.

But product designers are constantly confronted with opportunities to do things in a better, but different way. Is consistency an inviolable "must", or, as the saying goes, "the hobgoblin of small minds"?

There are enough "standards" in the software world that you can often pick from several. The aforementioned Office and Adobe suites, for example, have very different ways of managing menus, drawing graphics and applying styles. Likewise, web applications often base their user interfaces on toolkit-provided controls and predesigned widgets, which are often inconsistent. Look at the many ways videos are controlled in web-based players, for instance.

When building a new application, there's always the temptation to do things in new ways. It's a natural, competitive feeling: "we can do it better than the competition." Most real innovations start this way, with an invention that improves the user experience. But useless and confusing variations also happen for a similar reason: "we need to be different."

This is where the Product Manager plays a key role. Like so many other product decisions, this one should be based on customer needs and problems. The PM defines the target customers - primary, secondary, tertiary - and every design decision needs to be made in the context of those customers' requirements. If, for example, the target customers have never used a similar product before, there is more leeway for user experience invention. On the other hand, if they have been using a similar product, then it's a good idea to look carefully at where they have problems with the old product, and innovate in these areas. Changing things that are familiar and working satisfactorily is more risky.

Sometimes the customer is acclimated to one way of doing things, but it's creating problems and limitations that the customer may not be aware of. The case of the Office Ribbon is instructive.
(Be sure to watch The Story of the Ribbon, if you haven't seen it: http://blogs.msdn.com/jensenh/archive/2008/03/12/the-story-of-the-ribbon.aspx)

When Microsoft looked carefully at how its customers used Office 2000, it turned out that 1) people knew how to do a small range of tasks effectively, but 2) they were unable to take advantage of many features that they needed, due to problems discovering and/or using the features. The Office team was faced with a choice between continuing to build on top of Office's rickety menu/dialog user interface, or make a radical break. Product designers were able to show huge productivity increases when users could pick from highly visual representations of functions, if these functions were organized in a logical manner. The proposed new design was a new, nonstandard interface, the Office Ribbon.

The dilemma was that the gains in productivity (and satisfaction, too) were most evident among new users and experienced users who made the effort to learn the new interface. There were problems when experienced users (and there are millions of them) tried to just start using the new interface. They were often frustrated and angry. Not good.

Microsoft made a very bold decision to create a new standard. (When you're Microsoft, you can do things like this.) The obvious option of providing "classic" menus was rejected - it would radically slow the transition to the new UI, and add a huge development burden. The result is a mixed bag - some Office customers refuse to upgrade to Office 2007, but most of those who made the move eventually express satisfaction with the Ribbon, and studies in fact show increased productivity and wider use of Office's features.

Product Managers and designers have to make decisions like these every day, usually on a smaller scale. Stay with the familiar? Invent a better way? The tough decisions really come down to assessing the costs and benefits to customers. Here are some of the key questions to ask:

- What is the user problem that a new design is addressing?
- How serious is the problem? Is the user complaining? Is there reason to believe that users are not able to work with the product effectively, even if they aren't aware of it?
- How significant is the improvement offered by an innovation, from the user's point of view? Is it really better? Can you quantify this, ideally through testing?
- Does the improvement require a significant amount of relearning or other dislocation on the part of the users? Will they consider it sufficiently worthwhile to make the effort? Are they likely to feel that it was worthwhile after they have made the effort?

There are two other factors to consider.

First, is there a competitive advantage to be gained, in addition to that provided by increased satisfaction? For example, providing a standardized, integrated installation routine across multiple product may facilitate the creation of a product suite or bundle that supports a business strategy. (Think Adobe's suite strategy.)

Second, innovation is expensive. Even if a new user interface can be developed quickly, there is a cost in testing it on customers (you are testing before deploying, right?) and modifying QA plans. Good ideas are worth paying for; unnecessary innovations generally cost more than they're worth.

Change for the sake of change is rarely a good idea. Innovations that solve real customer problems are usually worthwhile. Distinguishing between the two can be the difference between driving customers crazy (and maybe driving them away) and making them fall in love.

Personally, I prefer it when customers love my products.

Personas: How Many Are Enough?

2010-07-20T10:18:00.000-07:00

Personas provide a great way to focus your efforts on a specific type of customer. Which is why I was taken aback when a colleague proudly told me that he had provided 37 personas to his team.

Focus. That's the point.

Personas are descriptions of archetypical customers - they represent the common attributes of a large number of people. They can provide reference points for everyone involved in the planning and development process. Well-developed personas enable a software developer to say "Harry wouldn't be able to use that feature" or an marketer to say "Elaine needs to be able to justify purchasing the product to her manager." Personas should be a constant reminder of who the target customers are.

For this to happen, Product Management has to create personas that are vivid and few.

Vivid personas provide insight into the customer's problems and motivations; they can begin to convey the kind of gut-level connection that you get when you visit a customer in person. A persona that includes quotes and workplace photos, for example, is more memorable than a dry description, and it will be a lot easier to recall during an intense planning session. However, a concise persona is also more memorable than a multipage portrait that describes the customer's gym habits and family dog.

How few are enough?

A politician once said that it's easy to talk for an hour, but really hard to talk for five minutes. Likewise, it's remarkably easy to come up with 37 personas, and much harder to focus on a half dozen. But nobody can keep 37 personas in their head. And it's really an indication that product management hasn't made an effort to really understand the market.

Here's how to end up with 37 personas: Start by listing the industries or market segments that you're addressing, maybe 5. Then add the roles that are commonly found, such as office worker, executive, system administrator, purchaser. Now you've got a matrix with 15 or 20 slots. Then say that you add another dimension, such as novice, intermediate or advanced user. Suddenly you have a three-dimensional matrix with dozens of customer types.

There's a difference between a list of "types" and a distilled set of "archetypes."

Archetypes are what you get when you examine the commonalities between many different types, and boil them down into a few characterizations that are each representative of several different types. In other words, an archetypical persona includes important and relevant things about a number of different people. The trick is figuring out what's most "important" and "relevant."

On the surface, it may appear that two customers in, say, legal services and construction management have little in common. But perhaps they have similar job descriptions and a similar set of problems in the area of financial planning and accounting, and perhaps these problems are especially relevant to the product you're creating. By combining some of the characteristics of each customer, you can create a generalized description of a customer whose needs fit both of these customers in ways that matter. You may focus on the details of one or the other to "flesh out" the persona, but the fundamental needs of the persona will match both customers fairly closely.

If this composite character is, in fact, a high marketing priority for your project, then you've defined a target customer. (If it's not, then put the basic description in a "low priority" or "we're not addressing this customer" bin, and don't flesh it out.) The persona of the target customer then becomes a Very Important Reference.

How many of these references is enough? Three or four personas are very easy to focus on, and that's a good thing, and it's worth doing a lot of refinement to get to this point. But sometimes your market is just too big: at Microsoft, we had 12 personas for the Office suite…but that was only 12 personas for the entire Office suite. It was a lot, but then we had tens of millions of customers. More would have been too many to track effectively, and fewer would have made the exercise meaningless.

So here's my answer: One persona is almost certainly too few for a commercial product/service, while more than a dozen (especially 37!) is too many. Four to six seems like a sweet spot. The trick is to make sure that the most important problems, needs and buying patterns are represented. Once you've done that, it's just a matter of writing them well and keeping them in front of the team at every opportunity.

Passion

2010-06-22T11:09:00.000-07:00

Someone asked me recently: What's the most important unteachable trait to look for in a product manager?

Passion.

All the skills can be learned. The procedures taught. Business strategy can be picked up by experience (or maybe even in business school). Agile development can be learned on the job. Even leadership skills and public speaking can be coached.

Passion can't be taught.

A passionate product manager believes in her products. In fact, it's hard for a passionate PM to work on products that she doesn't believe in. When that happens, she may decide to move on. Matching people to their passions is important in hiring, and in management. It's crucial to recognize that different people are passionate about different things - one person may be excited about digital imaging applications, while another is enthusiastic about eLearning systems.

When a PM believes in a product, its success becomes important on a personal level. Failure becomes, as they say, not an option. The product vision becomes a kind of a mission for an engaged PM, something that he cares deeply about and wants others to care about.

There is no substitute for passion when it comes to understanding customers. Sure, you can interview or poll customers and collect information in a methodical way - that's the least a PM has to do - but a really effective product manager cares enough to really connect with these customers. By listening and understanding the customer's pain, on a gut level, a PM obtains a crucial insight that mere observation rarely provides. Uncovering and even empathizing with customers' emotional responses to problems provides a way to discover opportunities for products that might never occur to a detached observer. These insights only come from doggedly pursuing customers and listening to them zealously.

A passionate product manager can communicate these insights in a way that helps to engage a development team. Dry requirements documents rarely communicate how a product can captivate a customer's imagination and make them really want it. It's up to the PM to explain his observations in ways that personalize the customer to the development team - perhaps by creating really meaningful personas, or better still, introducing the team to the customer via video or even in person. A product manager can only connect the team with the customer if he's really engaged himself, and really cares that the team shares this engagement.

And, obviously, a passionate Product Manager cares enormously about the quality of the product. User experience, in particular, becomes a major focus, since the PM is often in the best position to understand how actual customers will view the product. A really engaged PM is a strong customer advocate, and may sometimes have to struggle to de-prioritize less important features, keeping his passion in check in order to achieve objectives.

Even if passion can't be taught, it can be inspired. A passionate leader can help other team members realize that it's OK to care about customers, and that it's a good thing to be enthusiastic about product quality. Most people have the ability to be passionate about their work. Sometimes it just takes someone with plenty of enthusiasm to help unlock their passion. Who better than a product manager?

Softball and Software

2010-04-11T08:46:00.000-07:00

I've coached girls softball for years, taking one team to the national championships. It's interesting to look at the ways that coaching a softball team is similar (or not) to product management…

- In softball, mastering the fundamental skills is the foundation for success. Without this, no amount of strategy or motivation will lead to success. One weak player can lead to many losses.
- In product development, there are specific skills that are absolutely necessary, such as mastery of development tools, design capabilities, and architectural vision. One missing skill can sink a project.

- A softball team must be motivated to succeed. Goals, both for both the team and individuals, can help a team continuously improve its performance. These goals can be about both competition (beating a team or winning a championship) and personal performance (improving batting or fielding results).
- A development team can usually produce something even if they're minimally motivated, but it takes real passion to achieve greatness. Like softball players, developers need goals that they passionately care about. A PM can foster this by ensuring that the team really cares about the customer, and challenging them to produce terrific products that they can be proud of. (Rewards and bonuses can be helpful, but they rarely inspire greatness.)

- Fun is essential. Girls play best when they learn how much fun it is to play well, and when they experience the joy of success (both personal and team). It also helps a lot if they like and care about each other, something that often develops during the course of a season.
- Software developers usually perform more successfully when they enjoy their work, and when they like working with each other. Management (including product management) can create the conditions under which a creative, enthusiastic workplace culture can thrive - the sort of place that people look forward to coming to every day. In this kind of work environment, cooperative relationships are more likely to develop, and people are more likely to support each others' efforts. As in softball, an enthusiastic workplace is built on a combination of positive attitude, creative/challenging jobs, clear feedback when success is achieved, and a healthy dose of fun thrown in from time to time.

- Softball has very clear rules that everyone must learn and follow.
- Software development teams often find ways to rewrite the rules to their advantage: They're not in a rule book, there are no umpires, and the rules change constantly.

- In softball, winning isn't everything (contrary to the opinion of many players' parents). Learning and improving is what it's about. A coach can encourage players to take risks that might or might not result in immediate success - it's the effort that counts.
- In the technology world, winning is everything. You don't start a project in order to lose. Nevertheless, it's crucial to take risks, try new things, and sometimes fail - as long as you learn from failure. "Wins" are often based on the lessons of previous efforts that didn't succeed.

- A softball coach is responsible for planning and implementing game strategy.
- A Product Manager may define product strategy, but the PM is both a leader and a player. Developing a strategy within an overall business strategy is a collaborative effort, requiring input and buy-in from execs, Marketing, Sales, Engineering, QA , and others.

Softball and product development are both team sports - that's why they both succeed when leadership, collaboration, skills and goals are well-developed and in-synch. When that happens, both softball and software are a heck of a lot fun.

P-Camp 2010

2010-03-14T11:19:00.000-07:00

A day at Silicon Valley P-Camp…very refreshing.

P-Camp is a free information-exchange event for product managers. This year's event was held at Yahoo headquarters in Silicon Valley. There were many hundreds of PMs there…kind of a scary thing, when you think about it. I can't imagine that more product managers have ever been packed into one room.

The beauty of this event is that it exists for everyone's benefit. The attitude is that if we all get better at what we do, then it's good for all. Never mind that there were many competitors there - in a way, we're all in this together. Product management is hard, so we might as well learn all we can from each other. It works.

Oh, and it's free.

P-Camp features class-type sessions that are chosen by the attendees. People propose sessions online, and attendees vote on which ones they want. The winners are given one-hour time slots, with 6-8 sessions at once. Topics ranged widely, from" PM Productivity" to "How Agile Changes PM Processes" to "Why would anyone want to hire YOU?". Every session I attended was useful - some were practical, others mind-opening.

It's free because organizations like SVPMA, Pragmatic Marketing, 280 Group and ZigZag Marketing have an enlightened self interest in promoting product management excellence, and have donated money to support this. Yet there is remarkably little self-promotion. It's about the community of product managers, and they really get it.

I'm already looking forward to next year. I recommend P-Camp to anyone who is involved in any aspect of product management. Not going seems unthinkable.

Just-in-Time Usability Testing

2010-02-08T14:12:00.000-08:00

If you've ever worked in a state-of-the-art usability lab, with skilled user experience staff, you probably find it hard to consider a product finished until it's been tested for usability.

Unfortunately, most companies don't have the infrastructure, budget or time for this sort of testing. While I believe it's too expensive not to do usability testing, I know that it's still very difficult for a PM to insist when deadlines are tight and there's no in-house usability infrastructure.

Not doing usability testing costs money and time - the later a usability problem is discovered, the more it costs to fix. Find a problem in the spec/prototype stage, and it's trivial. Find it during beta testing, and it's a lot more expensive to fix. Find it after shipping, and the cost can be measured in extra tech support and lost sales, and then it may still have to be fixed in the next release.

Clever user experience designers (you have some of them, right?) have done cognitive walkthroughs and paper prototypes for years. These are good tools for evaluating early-stage designs. But in the past few years it's become practical to do real, live, full scale usability testing without a lab. The equivalent of a $100k lab can run on a laptop, and anyone who knows testing methodology can run it - even a Product Manager.

A usability lab consists of equipment for recording a user's on-screen activities, as well as a synchronized video image of the user - usually a face and hands view. Traditionally, a one-way mirror was used to permit spectators, but live views can now be achieved via webcast.

The key to "miniaturizing" this setup is a product called Morae, from TechSmith (the Camtesia/Snagit people). Morae is a software app that runs on any modern PC. It has a module for running the test, which records a video of the user and everything on their screen as they use the being-tested app or web site. It has an administrator's module to record, annotate and edit the screen and live-video that's captured. And there's an observer module that can run on any remote PC to enable live observation of the test over the web. Morae can be used virtually anywhere, even at a customer's site, with very little setup time.

Of course, useful usability testing requires some skill. You have to pick the right people to test, design tests carefully to test the right tasks, and talk the participant through the test in a way that produces actionable information. Finally, the results must be analyzed in a way that is useful to the PM, the development team, and, often, executives.

A novice tester might not get this right unaided, but can learn by working with a good contract user experience expert. There's a skill in guiding the user, observing carefully, responding appropriated, and being very, very patient. It's not that hard, but it takes practice. And it's worth it.

The goal should be to have someone in house who owns usability testing, and can run tests when needed. They don't need to be dedicated to this, and in a small/midsized company this will be out of the question. But they need to understand the value of usability testing, and they need to be able to roll out the "lab" and run a few tests. The result is a "just-in-time" testing capability. I've successfully set up and run usability tests with as little as a few hours notice.

It can be done by a product manager (not that your plate isn't already full), a QA person, or someone else who's interested. The best non-dedicated usability tester I've worked with was a Tech Pubs manager.

With this capability, you can evaluate the usability of your product with very little lead time, simply by inviting in appropriate testees and having them do a few tasks that will confirm that a design is working…or not. The tests can be observed by developers or executives, or they can be distilled into a video/slideshow summary that illustrates where the application is or isn't working. Seeing is believing. There is no substitute for watching a user succeed or struggle - it instantly brings home a problem that might otherwise become just another bug report.

This may not be in your budget or schedule, but you can't afford not to do it. User interface mistakes cost money and can drive away customers. In long development projects, major development efforts can be based on flawed user interfaces. In an agile development environment it's crucial to evaluate the results of a sprint before moving on to the next one.

If you rely on people who know an application intimately to validate the user experience on behalf of first-time users, you're headed for trouble. There's no longer a reason to leave usability testing to big companies - it can and should be part of every software/web development project.

You Are Who You Hire (part 2)

2010-01-03T10:07:00.000-08:00

Hiring someone is a little bit like getting married. You're making a long-term commitment to spend a lot of time with him or her, you'll depend on each other in many ways, and it's not easy to end the relationship. So the hiring process is like dating - you want to find out a lot about each other, and like dating, it's not just about technical qualifications.

Here are some different approaches to getting to know someone during the hiring process.

Interviews usually start with a discussion of the candidate's past experiences. As an interviewer, it's important to press for details, not just hear the rehearsed story. For example, you can ask:
- "Why did you leave a job?" Press for details and ask how to confirm them. Is there someone, not necessarily a supervisor, you could talk to, from the previous job? You can learn a lot from a person's reaction to this, even if you don't follow up. And when you ask about why they left another job, you may get a more accurate answer.
- "Describe your accomplishments on a project" (pick one that was clearly a team effort). Then ask about the candidate's personal role on the team in each accomplishment. Listen for someone who takes all the credit, versus someone who acknowledges a team effort. Ask what he had to learn in order to do the project.

Get an idea of what sort of work culture the applicant has been in, and whether she will fit into your company's culture. Ask "what kind of work environment do you thrive in?" First, establish whether she is accustomed to a competitive or supportive/team-oriented environment by asking for examples of work situations where people competed for credit or advancement; then ask for examples where people worked together and/or shared credit. Ask which environment was most comfortable, challenging and rewarding. If you read between the lines, you'll learn a lot about how the candidate herself works with others.

In order to discover how an applicant handles specific situations, start by asking, generally, to describe a difficult situation and how he dealt with it. Then ask for an example of a success that grew from a personal initiative. Follow these with a few questions that require the applicant to describe how he might respond to difficult hypothetical situations, such as:
- "Say you were asked to do something that could not be done in the time allotted, and your manager said that you must finish it, and no other resources were available? What would you do?"
- "What if you were instructed to do something that you believed undermined your company's business objectives?:

One classic hiring technique is to ask the candidate to work on a very difficult problem, perhaps one that she could not actually solve. Something like, "a swimming pool and a faucet are 100 yards away from each other. Using only the things in this room as tools, how would you fill the pool?" Ask her to explain her process, and listen for how she brainstorms the problem, examines alternative approaches, and thinks when she hits a roadblock. A really good candidate won't give up, and a great one might solve the problem with a solution that never occurred to you. (Note that the swimming pool question is open to "outside the box" solutions, such as filling the pool with something other than water.)

One way to find out how someone sees himself is to ask “If I called three people who have worked for you, how would they describe you?” The implication that you might actually follow up encourages honest answers. (Checking references is a good idea anyway. Even though many companies now prohibit managers from giving references, a lengthy chat with a former co-worker can be very informative.)

Sometimes you can learn a lot about someone by asking "blue sky" questions, such as:
- What's the best job you can imagine?
- What would you do to grow our business if you could build any product or acquire any small company?(I answered this question in an interview once, and after I was hired, my suggestion led to a major acquisition.)
- What other company would you most want to work for, and why? (If you want to put the candidate on the spot, ask "Why aren't you interviewing there? If they're not hiring, would you go there when they are?")
- What would you be doing if you had $100 million in the bank?

Give a candidate plenty of time to ask questions. This isn't a courtesy - this is an important way to get to know someone. You'll get an idea how well they've researched your company (and maybe you), how well they understand the business/industry, and what kinds of things concern them. See if they take notes. (I would probably not hire someone who came to an interview without a notebook...)

Finally, my most important interviewing suggestion: If you're serious about a candidate, take him out to lunch (or dinner). You'll learn more about the person in an informal setting than in an office or conference room. Eating together can provide big insights into someone's personality and habits, so pay attention. Don't act like you're interviewing, just have a conversation. Encourage storytelling. Remember the airport test: if you wouldn't want to be stuck in an airport with someone, you may not want to hire them.

If you really interview well, you'll know when you've found the right candidate. If you're not sure, keep searching. Settling for someone who isn't smart, knowledgeable or compatible is a sure way to build a mediocre business. When you find the right person, you'll be making your own job more enjoyable and productive. Anything less should not be an option.

You Are Who You Hire (part 1)

2010-01-02T21:08:00.000-08:00

The recession has done strange things to the hiring process. Few openings, many applicants. Stacks of resumes, many embarrassingly overqualified, some grotesquely underqualified. All too frequently, companies are treating applicants poorly, not following up after interviews and behaving arrogantly. And often people are hired in a hurry, without sufficient scrutiny.

Hiring may be the most important process at any company. Everything else depends on having the right people in place, especially when it comes to product managers. But whether you're hiring a product manager, a CEO, or a product support rep, your company's future depends on having the best people in place. You are who you hire.

Hiring the right person isn't that difficult if you know what you're looking for, make the effort to get to know applicants well, and are patient.

Here's what I look for when I'm hiring, in order of importance:

1. Intelligence. You can't teach this, and if it isn't there, you get mediocre results. Hire only smart people, at every level. No exceptions. None. (Note: this does not always correlate with "educated." There are very smart people who are undereducated, who can be valuable contributors.)

2. Personality and cultural fit. Your hires should be people that you want to work with, and who want to work in the kind of workplace you want to have. It's important that people have compatible attitudes about things like teamwork, cooperation/competition, personal and work goals, and work/life balance. Find out whether they have an appropriate energy level, initiative and drive. Do they pass the "airport test": would you want to be stuck in an airport with them for eight hours?

3. Experience. While this is somewhat dependent on the position you're filling, you want people with appropriate experience. Sometime this means that they've done the job before; sometimes it means they have work or life experiences that give them knowledge and insights that will be useful for the job.

4. Domain knowledge. Does an applicant know about a specific industry or product type? This can be enormously valuable, yet it can often be learned on the job by a smart, motivated person.

5. Technical expertise. Obviously, this is most important in a technical position, and is a higher priority for, say, a software engineer. A product manager needs to at least be conversant with current technology, if not an expert. But any employee who knows how to get the most out of Office or the web can be valuable.

How do you figure out if a candidate fits the bill? Here are a few tips…

First, make sure you've written a thorough, precise job description, but don't fill it with minutia that excludes qualified candidates. Is a degree in computer science absolutely required for the position? (Hint: It is not required for a product management position, contrary to recent hiring trends.) If not, don't say it is - you'll lose qualified candidates. Provide applicants with enough information that they'll know whether there's a real potential fit…and leave the rest to the interview process.

Preliminary telephone interviews are often called "screening," an unfortunately negative term for the first contact with a future employee. But it's usually too time-consuming to talk to a lot of candidates in person, so it's necessary. The goals of a first-round phone interview are getting a sense of what's behind the job listings in the resume and getting a feel for the candidate as an individual (see priorities #1 and #2, above). Who is best suited to conduct a preliminary interview? Ideally, the hiring manager, but realistically, it's often more realistic to use an experienced interviewer who understands the company and the job requirements. Someone who is really good at this can sort out the best potential candidates.

From this point on, it's best to meet candidates in person if they are local, though if they live an hour or more away, it's reasonable to do a detailed phone interview. Usually the hiring manager should do the second round. I like to do this in a one-on-one meeting that will be "up to an hour", which I can cut short if someone is clearly not suitable. I generally don't schedule additional interviews the first day, unless a candidate is coming from a long distance. But I'll often ask a second interviewer to be available in case someone seems really good and I want a second opinion on the spot.

If a candidate reaches the "final round", I'll bring him or her back for a series of interviews with the team. (In the case of the non-local candidate, I'll schedule a series of interviews the first time they come in.) Some companies use group interviews. I prefer one-on-one, except with team members who are less experienced interviewers - then I will team them up.

When a candidate is a finalist, it's very important to listen to every interviewer's opinion. Most "bad hires" drop plenty of hints in their interviews, but the hints are ignored because no one was encouraged to provide detailed feedback, or "only one interviewer said there was a problem." When someone raises an issue, listen. It can save you a lot of pain and trouble later on. And never ignore warning signs because you're in a hurry to fill a position. Once you hire someone, you're going to have them around for a long time - so get it right.

In part 2, we'll look at some interview techniques.

Trust

2009-12-01T17:32:00.000-08:00

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 these problems. But not always by being "nice."

For example, if Sales is taking a message to customers that does not accurately describe the product that is being developed, it's incumbent on the PM to bring this to their attention and work with them to correct the messaging. It's the PM's responsibility to demand that Sales gets the messaging right.

Likewise, if engineering is developing something that does not meet customer expectations and will likely fail in the market, the PM must demand that the plan be modified. Usually, there is no one else in a position to do this, and failure to do so in the clearest terms can be disastrous. How it should be modified may be up to engineering, or a collaborative effort. But it's the PM's job to make the call as to whether chanages are required.

But making demands can't happen in a vacuum. Someone who demands things without credibility, or who is not respected by the team, is likely to be ignored. Or worse. A CEO can make demands because she has positional authority - a PM rarely has this kind of influence. Instead, there's one element that's a prerequisite to "demanding" behavior when there's no true authority:

Trust.

Trust is something that can grow from working together over time, or from shared interests. But there's one way that a product manager can actively build trust with people in different organizations: by emphasizing the value of working as a team toward common goals, and demonstrating a personal commitment to the goals.

When a PM demonstrates commitment to a project by becoming knowledgeable (about the customers, the technology and the team members) and by supporting the efforts of the team, then a trust is developed. This trust provides the foundation for working together effectively when things get tough. Trust happens when people believe that you have their interests at heart. The best way to build this trust is to promote the idea that when the team does well, everyone wins…and that you're on the same team they are. And your actions have to prove that you believe it.

When it comes time for a PM to demand that the team provide a detailed schedule, or to criticize a marketing plan that doesn't ring true, then trust had better already be in place. It won't magically appear during the tough times.

Asking nicely is good, when possible. But there are times when a PM has to be tough as nails. And it's going to be a lot easier with people who trust you.

Agile Architecture

2009-11-16T14:22:00.000-08:00

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 incremental: every morning we would review the previous day's work, and adjust our plans accordingly. Sometimes we decided that work that was underway needed to be changed or even removed - we felt free to improve by tearing things out and starting over if necessary. Our users - school staff - would visit now and then and make suggestions. When the project was done satisfactorily, we moved on to the next one.

I'm not making this up.

If you're an architect, you'll say "building design never happens that way." Well, it did, because we were working for our school, and the school gave us license to experiment. After all, the crew was paying (tuition) for the opportunity to build this way. If you're an agile software developer, you'll say, no way, this sounds too much like the agile process (and this was long before Agile was articulated).

We stumbled on this process for a reason. It wasn't a grand theory - it just made sense given our goals (a desire to build something special while learning new approaches to design) and college's willingness to experiment in exchange for free labor. We were able to design buildings incrementally, evaluating progress and making adjustments based on our observations. The results were pretty good. (Link to photos.)

Traditional architects don't generally work this way because on-site design is too expensive when you have a large crew of expensive builders to keep busy. ("Feed the beast!") Historically, buildings have been designed and specified 100% in advance, and the "product" is built to spec. The downside, as in software development, is that poor design and actual errors are often unnoticed until people move into the building, when it's often prohibitively expensive to make changes. Sound familiar, waterfallers?

Interestingly, modern design tools have provided ways for architects to simulate buildings with extraordinary realism: Building Information Modeling tools like Autodesk's Revit and NavisWorks enable designers to realistically envision the construction process and the final building. Design teams now have the ability to work more incrementally than ever, with meaningful feedback from clients and builders along the way. In effect, tools for rapid prototyping and evaluation have given the architects the same ability to "be agile" that modern development tools have given software teams.

If you think about it, many kinds of artistic and creative endeavors are approached incrementally. Painting, sculpture, writing - they're all done incrementally, with ongoing self-evaluation and revision. There are team-endeavors that work this way too: movie making and music recording, for example.Even pure engineering, in the design phase, tends to be incremental - an airplane is designed iteratively, with many iterations based on internal review, wind tunnel tests, etc. Perhaps a "design everything in advance and then build it as designed" approach is really an aberration, serving primarily to give architects and software designers a sense of control over the outcome that may actually be illusory.

My early experience with "agile building" and the rapid acceptance of agile software development lead me to believe that an incremental development process is a natural way to work when the right conditions are in place. These "conditions" are partly technical - tools for rapid development and evaluation - and partly social - a willingness to be flexible and to iterate until a product is "right." With these in place, why wouldn't you choose to work this way?

Getting Agreement on Priorities

2009-10-05T12:09:00.000-07:00

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 management says, "just ask people to work a little harder for this one sprint, and spend a little less time on the installation work," they sometimes fail to see that the original schedule was developed carefully. PMs and engineering managers usually want to be "can do" players, and agree to changes even though they know that it places the project at risk.

In this situation, the product manager has a very important responsibility. Setting priorities is all about weighing options, and no one can weigh options effectively without adequate information. The PM is in the best position to gather information from engineering, marketing, sales and management. To this, the PM can add data about customers and the market. It's then up to the PM to clearly explain the benefits and costs of each option, in a way that can be understood by all parties.

This role is crucial because, simply, there is no one else in a position to serve as a "clearinghouse" - someone who is responsible for digesting all the relevant information and making sure that everyone understands it.

For example, the installation feature may have been based on information from Product Support and a user experience designer, and the costs are based on estimates by engineering and QA. Management may only see that it's an item on a product roadmap, and not understand the urgency and opportunity involved. It's up to the PM to explain exactly why the work is important, and the consequences of not doing it. At the same time, the PM needs to understand the customer request that Sales has raised, and explain the costs and benefits of addressing it immediately, later, or not at all.

Decisions often come down to "bang for the buck." Sometimes this is an easy calculation…if the PM has defined what constitutes "bang" and has assembled data about how many "bucks" it's going to take to achieve the bang.

To get it right, each feature must be weighed in terms of:
- Effect on customers: target customers, key accounts, etc.
- Resource requirements (including impact on other features/projects)
- Opportunity cost: what won't be done if this is done?)
- Time to completion
- Quality concerns: will this or other features be compromised?
- Product support impact
- Impact on marketing and sales plans, training, launches, etc.
- Effects on partners, suppliers, and/or manufacturing
- Effect on other products
- Impact on product roadmap and strategy
- Revenue impact

Those are a lot of factors to consider. Yet every decision to add a feature or raise a priority may have an impact in each of these areas. By ignoring them when decisions are made, the likelihood increases that there will be an unforeseen consequence of the decision. A PM has to be emphatic about one fact: Not everything can be the top priority. Sure, a team can do several things at once, but not everything at once.

Prioritization is an art: if you have 20 feature projects under consideration, picking the top five most "urgent" features may not make sense. It may be more valuable to combine a group of related features into a "feature set" that, taken together, provides more of a benefit to a customer. The person best equipped to define useful feature sets is usually the one who knows the customer best - the product manager. To succeed in prioritization by feature aggregation, the PM must articulate yet another set of costs and benefits, explaining the benefits of feature synergy and the costs of not combining features into logical sets.

The First Law of Priorities can be deadly if overlooked, or it can provide the key to building a product roadmap that's based on consensus and actually works. Ignore it at your own risk.

Quality: What's Good Enough?

2009-09-22T09:50:00.000-07:00

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 a wrong way to do things, and little in between. But later, when I was working on my own, I learned another important lesson: the "right" level of quality depends on the intended use and the intended user. Context is important.

For example, a "perfect" saw cut is different if you're making a cabinet or a stud wall. Likewise, a "perfect" user interface is different if you're making a multi-million-user social networking website or a console for an expert system administrator. The different audiences expect different levels of design and "polish", as well as different levels of control and access. Quality is very much in the eye of the beholder, and it's up to the PM to understand what the beholder (the customer) wants and needs.

What makes this so hard is that there are a number of criteria to consider. For example:

- Is the product sufficiently functional that the user can successfully complete the intended task?
- Is the product sufficiently reliable for the intended use?
- Is the product sufficiently discoverable that people can figure out how to use it?
- Is the product sufficiently usable so that the intended user can use it effectively and with satisfaction?
- Is the product sufficiently attractive that users will be drawn to it? (Especially important for web services.)

The answer to these (and other) questions might vary for different target customers. A minor error message might be trivial for one audience, but might keep another from using the product.

It's crucial that product manager identify the expectations of the users at the beginning of a product, and make this clear to the development team. The more that the team understands about the needs and experience level of the users, the more likely they are to produce something with an appropriate level of quality.

There are ways to quantify problems: those responsible for Quality Assurance will likely identify problems by severity, frequency, and perhaps by customer impact. The PM can add an important level of realism to this process by helping to establish a clear vision of who the user is, typically by using personas and use cases, but also by encouraging engineers and QA staff to watch usability tests or even visit customers. QA people love to refer back to real customers, if they've had the chance to meet them, when assessing the impact of a bug. This not only empowers the team, it reduces the need for the PM to be involved in every quality decision.

When it's time to decide when (or if) the product is good enough to go to market, the product manager is in a unique position to contribute to this decision. In addition to assessing the functionality, usability and reliability of the product, then weighing customer expectations, the PM has to consider these things too:

- Will customers be able to accomplish primary tasks well, even though secondary tasks might not work as well, and is this acceptable?
- How much support will the product require?
- What effect will any problems have on the reputation of the product? The company?

Software is never perfect. There are always fix/defer decisions to make. There are times when it's OK to ship or go live with something that has a few glitches, and there are other times when it's better to throw some code in the river and do it again. The better you know the customer and business objectives, and can communicate these to a development team, the easier these decisions will be.

It's probably not a coincidence that Robert and I both went on to found successful software companies. We both loved to create things that people used, things that were functional and beautiful. It's not such a big leap from creating a nice piece of furniture to making an elegant and useful application or web service. It helps to have a strong desire to create things of "quality", but also to keep a healthy perspective on what's appropriate.

Quality: The Zen of Product Management

2009-09-14T09:13:00.000-07:00

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. This motorcycle owner doesn't care about the intricacies of the machine's design, and may not be interested in maintaining or improving it - but may care very much that it runs well and looks good.

Pirsig contrasts this viewpoint with a strictly rational lens - evaluating something in terms of how it works, its design and technology, and why it does what it does. This motorcycle owner is cares about the workings of the engine, and takes pleasure in making sure that the machine is running well. This rational understanding of the product contributes to the user's appreciation of it.

The romantic attitude would lead a software or web user to judge a product based on factors like aesthetics, discoverability, and efficiency of use - without being cognizant of these as measurable "qualities". The rational approach would be typical of someone who likes to understand the product, customize it, and perhaps play a role in improving it.

The romantic viewpoint is common among the customers of software product and web services - they want these things to work well, be easy to learn, and be pleasing. It's an approach that's typical of the majority of users of business and consumer applications and service.

On the other hand, there are usually a smaller number of users who are strictly rational - often power users, system administrators, and early adopters, These may be important users, and they are sometimes very vocal, but they are often in the minority, often a very small minority.

The rational approach is often ubiquitous in an engineering/development organization. Techies tend to be relentlessly logical, almost by definition. It's this attitude that makes them good engineers or QA testers. They are good at viewing the quality of a product in terms of efficiency, functionality and technical elegance.

The challenge for the product manager is to understand both these points of view, and to fully appreciate that customers and engineers have very different ideas of what constitutes quality. Pirsig says that merging these two viewpoints is the key to understanding the world more clearly. In the world of product development, the incentive is more immediate: it can be a matter of success or failure.

The PM who focuses exclusively on the customer's experience can easily fall into the trap of making products that are easier to use, but are limited by the customer's vision. Breakthrough ideas are rarely articulated by customers - a PM needs to take an analytical approach to understand why a product satisfies (or doesn't satisfy) a customer, to understand the underlying problems, and make the conceptual leaps that result in breakthroughs. PMs must be logical and analytical.

On the other hand, a PM who is exclusively analytical is not likely to understand the feelings and emotions that a customer experiences when using a product. These are often the reasons that a customer will choose - or not choose - one product over another. A PM who is not tuned into the customer's inner experience is not likely to drive the creation of a product that is deeply satisfying to users.

The value of a multidimensional understanding of quality is especially important during development. A PM needs to be able to communicate the customer's feelings to a detail-oriented engineering team, and at the same time must understand the team's need to create solutions that are functional and efficient. Without this "bipolar" understanding, a PM can't play the dual role of customer advocate and development partner.

I've heard that it takes a certain kind of personality type to be a good product manager. I've always felt that it requires a special combination of empathy and rationality. Maybe you don't have to a zen master to be a good product manager. But cultivating a zenlike view of quality sure helps.

When the Team Gets Stuck

2009-08-31T11:50:00.000-07:00

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 doesn't understand the customer requirements clearly, you either need to do some more homework, or communicate what you've got more effectively. Personas, scenarios, detailed workflows and use cases are usually effective in explaining customer requirements. But it's also essential to link these to specific feature sets, and to provide a clear sense of prioritization among these feature/function sets. The PM needs to make sure that the team always knows what the customer problems are, which functions are relevant to which problems, and which solutions are most important for the current release.

If it turns out that the team is simply not equipped to finish the design, get them help. The most common "missing skill" is product design expertise, though you may need help with media production, back end development, or something else. If you have the ability, you may have to personally step in and work on it, but you probably have other pressing things to attend to. If possible, borrow help temporarily from elsewhere in the company, and if you can't do that, try to bring in a consultant or contractor on an emergency basis. There are plenty of good product designers for hire as contractors, for example. The PM is often in a good position to advocate for more resources, or to support an engineering manager's request.

If you're well into development, or nearing the due date, and progress isn't happening, then consider these possible reasons:
1. The deadline was unrealistic, and Development may have signed up to it under pressure or out of false optimism.
2. The design/specs are flawed, contradictory, or unbuildable.
3. There are organizational problems in Development that are interfering with progress.
4. The design is beyond the technical capabilities of the team.

Each of these requires a very different response. And the response may depend on whether you are doing an agile or waterfall process. (One of the beauties of agile is that you aren't half way through a multi-month or multi-year project when you realize you have a problem.)

#1 is very common. Development often wants to be optimistic, and may estimate based on "best case" scenarios. No project ever achieves best case scenarios for each subproject, so this will always lead to trouble. The solution is a new project plan, perhaps with more frequent milestones. It may be possible to scale back the feature set in order to meet the schedule, and the PM will have to make some major decisions, usually involving senior management. And there may be some real pain involved.

In #2, if the problem is with the design or specs, then the problems must be identified as quickly as possible, before more time is spent building the wrong thing. One common late-surfacing problem that can bring development to a halt is usability - what if it becomes clear that the product isn't sufficiently usable, but Development has done the job it was asked to do? An agile process in designed to address this, but on a long-term development job, it may be necessary to call a time-out, run usability tests or performance benchmarks, and change the design. The later in the process that this happens, the more expensive it is. (It's never cheap, so doing the work/research to get the design right - and validating it by testing it - is really important!)

Case #3, organizational or personal problems in Development, can be very difficult and painful to resolve. It's usually the responsibility of engineering management to solve these, but it will sometimes fall to the PM to identify areas of dysfunction. Sometimes a PM, as a kind of neutral observer, can make valuable suggestions to improve the process. Pointing out inefficiencies or process gaps may be the best you can do - it's up to Development management to fix them. If that fails, you may have to escalate the issue - this is where a good relationship with management is important - they need to trust your observations. In general, the more people that agree about a problem, the more seriously it will be taken. Being constructive and proposing solutions is essential - negative criticism often makes things worse.

In #4, the case where the team is not capable of implementing the design, either you have to change the design, or the company has to change the team. Or both. Design changes may be preferable, but must often be reconciled with customer requirements, business strategy, marketing plans and sales expectations. It may be that adding to the team is preferable (keeping in mind that it's usually ineffective to add a lot of team members quickly). What isn't viable is allowing a team to keep spinning its wheels indefinitely, hoping that a solution will be found. Set a time limit and stick to it.

I was able to help my team get back on track by a combination of these approaches. Most important was clarifying customer requirements - the previous PM hadn't done so. But the team was also without an experienced product designer or product manager, and those problems had to be addressed too. It took several months to turn things around, but it worked.

In the end, it's about getting to the end. And if you can't figure out why you're not getting closer, you won't get there.

Persuasion

2009-08-20T08:50:00.000-07:00

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's meaningful, with data that shows it's representative of other customers. Even if Sales doesn't do a formal win/loss analysis, a product manager can build one from a series of discussions with Sales staff, resulting in highly useful data.

Data is useless without good analysis. Insights come when information is viewed in different ways, and when data from different sources is combined and interpreted. The more thorough your analysis, the more sound (and persuasive) your conclusions will be. And, of course, it's important to present data effectively, whether in a well-written MRD, an executive presentation, or a hallway conversation. (Never underestimate the importance of your "elevator story"!)

A PM can also play a valuable role in articulating other participants' viewpoints. As the center of the development ecosystem, the PM is often in a position to communicate the insights of Engineering to Marketing, of QA to Sales. Shared information can be the grease that keeps the development machine well-oiled, making the PM's job much easier.

Perhaps the single most important thing that a product manager can articulate is The Vision. It's a summary of the goals, the direction, and the spirit of a project. It should be universally understood, and never forgotten, and it's the PM's job to make sure it's clear and persuasive.

Negotiation
A product manager must often build consensus from conflicting interests and viewpoints. Sales may have one point of view ("we have to have the product next quarter") and engineering another ("it will take six months to finish the product"). Different viewpoints are sometimes both/all correct, from the point of view of the advocates. It's the PM's job to work with different team members ("remember, we're all on the same team…") to find a satisfactory approach. Sometimes this involves striking a mutual compromise, sometimes one side can be brought to accept another's viewpoint. Sometimes brainstorming and "out of the box thinking" can result in a new approach that satisfies all parties. The product manager is in the best position to facilitate these kinds of discussions.

There are many skills required for conducting negotiations successfully, but listening is fundamental to success. A PM needs to be able to understand the concerns of each team member - otherwise he will be perceived as an advocate for one side. The PM may ultimately adopt one viewpoint, but a good negotiator will do so only after ensuring that the other side knows that he understands their point of view.

The Power of Good Ideas
Never underestimate the persuasive power of a good idea. A product manager is not just someone who communicates data and facilitates discuss - a good PM is a creative part of the team who is constantly contributing ideas to the development process.

This begins from the beginning of data collection - it's the PM who has to decide what questions to ask and who to ask - through the design of the product. A PM is in a unique position - being responsible for understanding the market, the customer and product design - and has the opportunity to develop insights that no one else is in a position to conceive.

In a healthy development environment, good ideas are persuasive. They need to be expressed clearly and it's usually more effective to share ideas in a collaborative way, rather than "bringing stone tablets down from the mountaintop." In some organizations there is a fierce pride of idea ownership, and a competition to get one's own ideas built. In this situation, it's often most effective for a PM to practice the art of humility and let other team members take over an idea. It's important to keep in mind that the PM's responsibility - and ultimate "masterpiece" - is the whole, successful product, not a single feature. In fact, one of the PM's most powerful persuasive tools is recognition: ensuring that people receive credit for ideas and hard work. Giving credit is persuasive, taking credit isn't.

Ultimately, the art of persuasion is a product manager's most powerful tool. It's built on a mastery of technical skills and good interpersonal relations, but without the ability to communicate persuasively, a product manager is nearly powerless.

Getting Your Point Across

2009-07-14T07:34:00.000-07:00

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 requires a different presentation style, and one of your most important tasks as a presenter is to evaluate these factors and make the right choices.

For example, small groups usually expect less formality and more personal interaction; in big rooms this is much harder, so a more formal style, sometimes with more visuals, is appropriate. If a user group expects to see a highly visual, detailed preview of your next product, you had better have something very visual to show - and a lot to say. But if you force a busy executive to sit through a 60 minute slideshow with pages of text explaining every detail of your operation, you may not make it to the end (and you may not have a job the next day).

(I've found that in a corporate environment, executive presentations are often seriously overdesigned. There's a natural desire to impress senior management, and sometimes different groups compete to see who can develop the fanciest slides. Days or weeks may go into preparing visuals for an executive presentation, sometimes to the point that the executives would object if they were aware of the resource expenditure. With most executives, a convincing and confident explanation is appreciated more than pretty pictures and endless bullet points.)

Connecting with the Audience
Once you've gauged your audience and situation properly, here are a few guidelines that can help establish and maintain a connection to your audience:

First, be a storyteller. Whether you're delivering a three-minute report or a two hour class, stories engage the audience and provide a way to explain things in real-world terms. Stories have characters; they have a plot; they have conflicts and resolutions; they have a beginning, middle and end, and they have a moral or point.

If you're talking about your market, tell stories about real customers you've talked to. If you're explaining your product to someone, lead them through the experience the customer will have as they use it, story-style. If you're delivering something as mundane as a status report, think of it as a story, with a starting point and a goal (the plot), problems (the conflicts), characters (the team), and a resolution (the current or desired outcome).

Telling a story based on your personal experience or knowledge is also a lot easier to tell effectively than reciting facts. It's simply easier to engage emotionally when telling a story, and your audience will engage along with you.

Second, use PowerPoint when you need it, and don't use it when you don't need it.

If you're explaining something that has lots of numbers, lists of things, relationships, or important images, then put them on the screen so that people can see them. It's hard for an audience to remember lists of things while you're talking, so displaying the list can enable them to focus on what you're saying while referring to the list as they need to. Graphics, charts, images and photos are all ways of communicating at a glance what it might take you a thousand words to explain, and visual images are more memorable than words. Show them. Memorable images, closely connected to your point, can help people remember the point. But don't fill the screen with "eyewash" - meaningless or feel-good images. These will distract the audience.

Bullet points are the single most egregious presentation crime. The audience should never be reading a set of bullet point sentences as you say them: this distracts them from listening to you. The only time to use bullet points is to help underline your point with just a few summary words, such as "Don't use bullets", and then it's usually best to show only one bullet point at a time.

If you want the audience to focus on you and what you're saying, then they should be watching you, not a slide. It's almost always a mistake to read text from a slide. (The exception is when you present a quote or passage that you want the audience to see, as you read it, word for word.) In using PowerPoint, your best friend is the "B" key. This causes the screen to go dark and the audience will focus on you. In general, that's what you want, right? Then, when you have another visual point to make, press the B key again to bring the slideshow back up.

If you need notes for your presentation, put them on paper or read them from PowerPoint's Presenter's View display. Never use your presentation as your teleprompter.

Third, use animation when it communicates something extra, and only then. You can use PowerPoint animation to attract attention to something, to show how things work, or to show steps in a sequence. But as soon as the audience sees text flying onto the screen, it becomes a distraction. Don’t try to use animation to keep people awake - your story has to do that.

Every time you step in front of an audience, you are the show. Don't try to pretend that the show is on the screen - it's not. So plan for your audience, have a good story, practice what you're going to say, and say it like both your project and your reputation depend on it.

They do.

Really Good Requirements

2009-06-13T14:21:00.000-07:00

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 level functional requirements of a product in this context. User and buyer personas are often introduced in the MRD. Audience: executives, marketing, and some the members of the development team.

A Product Requirements Document is usually a little more focused on the functionality of the product itself, describing what features and functions are necessary to succeed. A PRD includes more design detail than an MRD, describes how functions can be combined into meaningful/useful feature sets, and it includes extensive prioritization of features. User scenarios, based on personas, are often introduced here. The product requirements should include a description of the user experience requirements. The PRD may include a long-term product roadmap, describing the long-term sequence of releases. Primary audience: The design and development team. However, this may be a consensus-building tool with executives and marketing staff.

A Functional Specification is a detailed description of each aspect of a product. It describes exactly what will be built. It should provide context by describing use cases that are based on personas and scenarios. The functional spec supplies the user experience guidelines for the product designer, and it may go down to the level of user interactions, including flow diagrams and "wireframe" screen designs. Audience: the design and development team.

A Technical Specification is an engineering document that describes how the product will be built. It may describe user interactions down to the "click" level, and provides information regarding interdependencies and interactions between functions. It may address the application of specific technologies and the design of data structures. A tech spec may take the form of a working prototype, which can be developed collaboratively between product management and engineering. (This can be subjected to usability tests before final development begins.) Audience: the development and QA team.

A Release Plan and Backlog are Agile terms for a list of features/functions prioritized into a sequence for development and release. These are typically built around specific use cases that are addressed in a release. Audience: The development and QA team.

If you're creating all these documents, you're probably wasting time - yours and your team's. If you consider the real purpose of product requirements, you can begin to pare these down.

Focus on the Process
A requirements document is the result of a process in which a product vision is developed and refined, and then the vision is developed into a product plan. It's the process that really matters, even though the document is an important artifact that will serve as an reference during development.

The requirements process is the Product Manager's opportunity to explain the competitive landscape, customer research and product development options to the team. It's an opportunity to work with management to align product plans with the company's business strategy, and to listen to Marketing's ideas, concerns and feedback. It's an opportunity to work with the development team to determine what's possible, before making final decisions. The process should be bidirectional: it's a time for listening, not just persuading.

An important outcome of this process should be the Product Vision. It's an idea that can be concisely stated and is both inspiring and credible. It's the central concept that everyone, from senior management to individual developers, understands and agrees on. The process of creating requirements docs should help you clarify and hone the vision, with feedback from as many contributors as possible.

The second outcome of the process is a consensus regarding what the product will do, and why. This is your opportunity to ensure that there is general agreement that you're building the right product, from both a business and technical standpoint. The documents you produce - whether presentations, requirements documents or specifications - are the "sign offs" that help you determine that you're on the right track. For this reason, you want maximum exposure for these, and you should make sure that key participants have seen/read them and are on board.

The form of the documents themselves should support this process. They should be accessible (easy to understand) and they should deal with the appropriate issues for your audience. You may combine the market and product requirements into a single document, but be sure to draw a distinction between analysis/observations and prescription/design. If you produce separate requirements and functional specifications, then there should be some overlap: Customer personas and scenarios are central to both, for example. You may want to link the documents so that if you change the target personas in the MRD, duplicated sections in a functional spec are updated.

The resulting documents become a reference point as development proceeds. When there's a what or why question about the product, the requirements/spec documents should be the first place someone turns. If they're well written and up-to-date, they can save a product manager many hours of answering the same questions over and over. Regardless of which documents you produce, be sure that you cover these elements:
- The overall vision
- User personas, scenarios and use cases
- Prioritized feature sets and functions
- The product roadmap
- User experience criteria and guidelines

It's important that these are "live" documents. Markets change, product priorities change, and user experience analysis can result in product design changes. You will be gathering additional customer information while a product is built, and sometimes this can prompt a change in direction. Whatever the reason, requirements and spec documents need to change as new decisions are made.

It can be really difficult to find time to keep these documents up to date, but it's worth the effort to record decisions. (If you're working with an Agile team, it's not optional - you have to keep the backlog updated.) To facilitate updating, it's often worthwhile to keep the documents in a central location, such as a SharePoint server or in a wiki, and set up automatic notifications when changes are made. This can also make it possible for the documents to become the basis for ongoing dialogs, which might be incorporated into or linked to the document, that can elaborate or clarify the meaning. This way, the process of explaining the product and building consensus is ongoing, throughout the project.

Regardless of what you call your requirements documents, it's the process that really matters. Get that right, record the results, and the documents will be right, too.

In a future post, we'll look at what makes a great specification.

Getting the Team Involved

2009-05-03T09:08:00.000-07:00

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 the pain of a problem is infinitely more memorable than reading a report about it. This matters. When it comes to creating a product, there's no substitute for caring about the customer…a team that remembers the customer's pain is motivated to help ease it.

Second, meeting customers helps build a common language within a team. I know, this is what personas are for. But a flesh-and-blood customer is more meaningful than a really well-written persona - when team members can talk about their firsthand experiences, it's no longer an abstract exercise.

One other benefit - going on customer visits help your colleagues understand what a PM does, and why it's important. Whether it's engineering staff or senior management, you'll find that there's a new level of respect for what you do, and a new eagerness to hear about your subsequent customer research.

There's one very real hazard to watch out for, though: If a team member visits a single customer, that visit will take on an exaggerated importance. This can be a problem if the customer turns out to be a non-target customer or is atypical in some important way. The team member may bring back a message that's irrelevant or distracting. The best way to avoid this is to line up three or four visits with different customers for each team member - admittedly more difficult, but this pretty much ensures a balanced view.

Either way, it is essential that you discuss each customer visit with each participating team member immediately afterward. Don't let your team members disperse after a visit - schedule a sit-down discussion after every visit. (It helps to have lunch money in your research budget!) This debrief should cover items such as "what was learned?", "what are the customer's pain points?", "how is this customer typical or unusual?" and "is this person likely to buy our product?" If the customer may not fit the target, it's essential to make sure that everyone understands this right away.

The discussion that follows a good customer visit can be as valuable as the visit itself, not just for team members, but for the Product Manager. It's a great way to hear other interpretations of the meeting, and note any points that you may have missed. In most cases, you'll end up with a consensus that will find its way into feature discussions months later, making it much easier to agree on the functionality and prioritization of product features.

And hey, why should PMs get to have all the fun?

Learning to Listen

2009-04-16T10:59:00.000-07:00

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 companies, which we visited over a 6 week period. We gathered an enormous amount of valuable information. But the good stuff was rarely the first thing the customer offered.

The customers, including both users and administrators, were asked to describe their work, their tools, and their challenges. People can be very articulate about these, particularly in a discussion with their peers. But they are also quick to point out the solution to their problems. They want to be helpful, they want to show how smart they are, and they really want that cool feature they thought up. This is where the danger lies.

If you go back and design a product based on their solutions and wishlists, you may end up with a camel when you really needed a cheetah. The problem is that customers usually go straight to a solution without understanding the problem, and how it relates to other problems. Sometimes they are totally unaware of related-but-different problems that other customers have. And their suggestions are usually based on their experience of existing products and technologies, rather than the kind of inventions that a good product team can develop to solve a problem.

In our 28-company tour, the most useful information came after we asked "why do you do this the way you do," and "tell us about the problem you're having." Then, in almost every case , it was our follow-up questions that elicited the most useful information. Few of these follow-ups could have been scripted in advance. We were able to ask them because we worked very, very hard at listening.

Listening involves more than paying attention. It means putting yourself in the customer's shoes as they describe their problems, feeling their pain, and continuing to dig deeper. It also means analyzing what someone has said - sometimes we would diagram a process on the whiteboard to make sure we understood what the customer was describing. We highlighted the problem areas, and asked them to explain them in more detail Later, we would discuss the findings with the product team, and follow up with the customer: In many cases, it was a follow-up email or phone call that resulted in a breakthrough in understanding a customer problem.

When were finally were able to understand what the customers actually meant, it enabled us to design a really innovative product. In most cases, the customers were surprised and delighted at the solutions that we had designed.

No one ever questioned whether the time we put into listening was worthwhile - it was obviously priceless.

Building Complete Products

2009-03-21T10:06:00.000-07:00

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's not. An example is a data management product that requires a database engine to be in place - in this case, there may be a big IT cost (acquiring and/or connecting the database, and supporting it from a server) every time a customer buys the product. A less dramatic example would be a web design application that requires you to go online and buy templates or content - the app is forcing the customer to finish assembling the product.

Incomplete products can be justified many ways:

"We can supply it at a lower price, and the customers can buy the
modules/content they want."

"We can get the base product done quickly,
then add functionality though modules, later."

"We don't own the engine (or content or web app) that's required, so the customer will have to purchase (or download) it themselves."

Each of these rationales can be very compelling from the development point of view, and may seem to be a good business strategy. But from the point of view of a customer who simply wants to start working, it's a lot less convincing. Typically, a tech enthusiast customer can handle an incomplete product - and may actually prefer something that can be tweaked and added-to. But a less sophisticated customer with no interest in customizing, downloading or extending an application is much less likely to take the trouble to use an incomplete product or service.

(There are times when "incompleteness" can be a business virtue: AutoCAD is an example of a product that succeeded because its open architecture encouraged add-on application development. But in that case, the product became a platform, and the opportunity to "complete" the product fell to the add-on developers.)

Here's an example of a web service that goes the extra mile, as opposed to the "not quite complete" approach of YouTube: Blurb is a service that publishes custom books that its customer submit. The beauty of Blurb is BookSmart, a free application for designing a custom book. It can be installed easily onto a Windows or Mac PC, and it provides a variety of templates for assembling books of all sorts. Finish your book, publish it to the Blurb web service, and your bound book arrives in the mail a few days later.

BookSmart is downloadable software. There are countless other examples of web applications, widgets and engines that can be plugged into a web service to "complete" it, like the embedded travel site maps. Why not put a good text editor onto that text entry page, instead of just a text box? The beauty of the web is that the user need never know that a site includes code from two, three or many vendors. As long as it gets the job done.

One caution: This isn't an argument for bloated products. If you try to make a product that is "complete" for every possible customer, you'll end up with a 100-blade swiss army knife that satisfies no one. Instead, the trick is to identify what is the minimum "complete" product for your target customer, and build that.

Customers are usually more interested in achieving an outcome than assembling a tool or figuring out a complicated process. This is true whether the product is a consumer electronics device, a PC-based software application, or a web service. There's a place for flexible, build-it yourself, or incremental products, but only when they are matched with customers who are willing to tinker with the product. For the rest of the world, "complete" is better.

Who Owns PM?

2009-02-11T14:32:00.000-08:00

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 listening to customers, competitive analysis, articulating product requirements and following through with the development team to ensure that the product meets the requirements.

I've done both these roles at once, and while I've successfully launched products and created marketing plans, I've found that it's difficult to be an effective product manager and product marketer over multiple release cycles.

Many technology companies place PM in Engineering. That's where the product is built, so why not put the person responsible for defining it there? The problem is that a development organization is all about how a product is built, not what product is going to be built. Engineering management's responsibility is to maximize the development productivity of its staff, and there is a tendency to have PMs focus on the development effort, moving into more of a program manager role. This is becoming particularly common in Agile teams, where the PM sometimes takes on "product owner" responsibilities, with little time available to understand the customer or the competition. There are exceptions, usually when Engineering management fully understands the importance of product management, and gives the PM license to do what needs to be done, or hires multiple PMs to cover all the bases.

The "none of the above" solution is best exemplified by a product management department that is at a peer level to Engineering and Marketing. It means that PM's voice will be heard by senior management as equal to the other groups, giving the organization a strong voice for product strategy and definition. It means that Product Management can set its priorities according to its understanding of what needs to be done to succeed. And the PM organization is best equipped for cross-product synchronization and roadmapping.

PMs always need to be a "go-to" resource for both Engineering and Marketing. Whether it's joining a development scrum, organizing usability tests, briefing Sales on a new feature or preparing/delivering a trade show demo, these are all part of the job. It's all part of "owning" the product. But a PM can do these things most effectively if the organization is structured to maximize each PM's ability to understand customer problems, identify market opportunities, and then define products that address these.

The Accidental Product Manager

2009-01-14T12:56:00.000-08:00

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 design. I suggested that there was an opportunity to transform the process of construction detailing, and we decided to start a company to do it. I designed a system for assembling detail drawings using parametric objects - bricks, studs, windows - rather than drawing with lines. Starting with two employees and a working prototype that I cobbled together, Vertex Design Systems raised $5 million in venture capital and within two years we employed 25 people.

As Vertex ramped up, I managed the development effort. I designed the product, wrote specifications, and hired the programmers and QA staff to build the product. As we brought in new people, it became clear that the key to success was making sure that the whole company understood the Vision - the idea that made Vertex unique. This wasn't so simple. It meant explaining the nuts and bolts of the architectural design process to people who had never been in an architecture office, before anyone thought of "personas." It meant evolving the product design as we invented new techniques, all the while keeping the end goal in sight. It meant building a business strategy and product roadmap that enabled us to get a product done quickly while paving the way for a full product line in the future…and getting both senior management and Engineering to contribute and buy in. It was, in short, Product Management.

Eventually others took over the engineering/QA management, and I focused on what I would soon realize was product management. Eventually, the Vertex Detailer was successfully launched, along with libraries of Dynamic Detail content and links to building material manufacturers' content. The products were far ahead of their time - it was years before anyone else replicated Vertex's approach to parametric construction detailing.

Yet the product did not reach its sales potential. We had hired a CEO to manage the business who believed in a strict division between development and marketing, and his marketing staff had little knowledge of the architectural market. Their pricing model was geared toward very large firms, who enthusiastically bought the product, but the majority of architectural firms are smaller, and were unable to afford the product. In retrospect, it became clear that product management and product marketing needed to share an understanding of the target customer, and develop both the product vision and marketing strategy (including the pricing model) together.

Later on, I also learned that you can't rely on your own experience to understand what products customers will need and pay for. It's great if you have firsthand experience, but even that is not always enough to understand the variety of problems that customers in different corners of the market face. And a good product manager needs to be able learn about customers in a market with little or no experience there. In fact, an outsider's perspective can be really valuable - but that's another story.

Vertex was acquired by another company, which was then acquired by Autodesk. By that time, I was a Product Manager at Autodesk, and was delighted to see the Vertex technology folded into Autodesk's architectural products. Parts of it are still there, and the basic approach of parametric design now underlies the industry standard for architectural software: Building Information Modeling.

Welcome!

2008-12-28T12:05:00.000-08:00

Throughout my career as a Product Manager, I've been filling notebooks with thoughts and reflections about my professional adventures. Some of these thoughts have been posted in various forums; now I'm going to consolidate them here in one place: the Product Management Journal. I'll be posting them here as I have the opportunity to refine and edit.

By posting these notes, I'd like to provoke an exchange of ideas with others who share my enthusiasm for developing great products. If you read these thoughts and have a response - positive, negative, whatever - please add a comment or send me an email. I look forward to hearing from you.