cover

作者:  [美] Marty Cagan 
出版社: SVPG Press
副标题: How To Create Products Customers Love
出版年: 2008-6-18
页数: 242
定价: USD 29.95
装帧: Hardcover
ISBN: 9780981690407

PART1 People
PART2 Process
PART3 Product
Summary
- Chapter 40:Best Practices Summary
- Chapter 41:Product Manager Worry List

PART1 People

Chapter 1: Key Roles and Responsibilities

The Modern Software Product Organization

Product Manager The product manager has two key responsibilities: assessing product opportunities, and defining the product to be built.
User Experience Designer The key role here is the interaction designer. These people are responsible for developing a deep understanding of the target users (each persona that you’re trying to satisfy in your product), and coming up with the tasks, navigation, and flow that are both usable and productive.
Project Management The project scheduling and tracking function is the core of project management.
Engineering Also known as product development or software developers these are the people responsible for actually building the product.
Site Operations The site operations team is responsible for keeping this service running.
Product Marketing The product marketing team member is responsible for telling the world about the product, managing the external-facing product launch, providing tools for the sales channel to market and sell the product, and for leading key programs such as online marketing campaigns and influencer marketing programs.

Chapter 2: Product Management vs. Product Marketing

They Are Not The Same Thing

Marketing-Driven Product

The rest of the product team views this person as the marketing resource who might be useful for creating data sheets, training the sales force, and coming up with the naming and pricing, but in terms of defining the product, this person is largely discounted and ignored. While these people might be great at marketing, they are way over their heads when it comes to trying to discover and define in detail a valuable, usable and feasible product.

Two People, One Role

A product marketing person is responsible for the high-level product requirements, and a product manager is responsible for the low-level product requirements. The problem is that neither person truly owns the product and, more importantly, neither person feels nor behaves like they are ultimately responsible for the product. Further, this model is based on a flawed view of software that holds that you can define high-level requirements independent of detailed requirements and especially the user experience.

One Person, Two Roles

Each of these roles is critical for a product’s success, and each requires special skills and talents. Creating a product is much different than telling the world about that product. I have known some truly exceptional people who can excel in both roles, but these people are very rare. As an organizational model, it just doesn’t scale.

The Way Out

The way out of these situations is to clearly define the distinct roles of product manager and product marketing in your company. The product manager is responsible for defining—in detail—the product to be built, and validating that product with real customers and users. The product marketing person is responsible for telling the world about that product, including positioning, messaging and pricing, managing the product launch, providing tools for the sales channel to market and sell the product, and for leading key programs such as online marketing and influencer marketing programs.

Chapter 3: Product Management vs. Project Management

The Internet Changed This Too

What Makes A Great Project Manager?

I think most people equate project management with Microsoft Project. But this is missing the real point of project management. Here are the seven skills that I think characterize great project managers like Lynn:

Sense of urgency. Just by walking into the room Lynn would instantly convey a sense of urgency. Pre-meeting banter was maybe 60 seconds, and then it was down to business. Partly this was due to her unique diet of sugar and caffeine, but in fact a sense of urgency—and efficiency—is at the heart of the eBay culture and was best personified by Lynn.
Framers. There are so many reasons for aimless, unconstructive meetings, but one of the biggest culprits is that it’s not always clear to the participants exactly what the purpose of the meeting is, what problem is to be solved, and what the specific issues or obstacles are. Great project managers understand how to clearly and concisely identify and frame problems and run constructive meetings.
Clear thinking. The typical business issue generally includes multiple underlying causes with a healthy dose of politics, personal agendas and personalities thrown in. This results in a murky confusion that if left unaddressed, delays development progress. The project manager needs to isolate the separate issues, and untangle the emotion and baggage to expose the underlying problem and get everyone focused on pursuing the solution.
Data driven. Great project managers understand the key role that data plays in informing them about precisely where they are and where they need to go. They are constantly looking to improve the product development process and the result, and they know this begins with measurement. It is all too easy to just shoot from the hip—especially in time-sensitive situations—so it’s essential for the project manager to insist on the data to make sure the decisions are made with the facts behind them.
Decisiveness. In most organizational models, the members of the product team don’t actually report to the project manager, yet he or she must drive decisions. This is where the project manager must communicate the sense of urgency, clearly frame the problem, have rational and transparent reasoning, and make decisions based on the data. The project manager also needs to know when it is appropriate to collect data and recommendations from the team, and when to escalate issues to senior management.
Judgment. Much of the above hinges on good judgment—knowing when to push, when to escalate, when to get more information, and when to take someone aside and have a little private chat. This trait is harder to teach, but experience can help.
Attitude. Finally, there are always hundreds of very valid reasons why a product isn’t ready to ship—not enough resources, not enough time, not enough money, etc. The job of the project manager is to get over each and every one of these obstacles. At their core, great project managers are great problem solvers. The great project manager doesn’t make excuses, she makes it happen. She is tireless and unstoppable.

Chapter 4: Product Management vs. Design

Understanding User Experience Design

In this chapter I spell out what I consider the design-related roles essential to creating a good user experience. Note that I’m emphasizing roles rather than people, as it’s possible to find people that can competently handle more than one role. But one way or the other you need these roles if you want a good user experience:

Interaction Design. These people are responsible for developing a deep understanding of the target users and coming up with the tasks, navigation, and flow that are both valuable and usable. Generally, the interaction designer maps product requirements to a design represented by wireframes, and passes them to the visual designer.
Visual Design. These people put the flesh on the wireframe and create the actual pages and user interface look and feel, which includes everything from the precise layout, colors, and fonts, but more importantly, the visual design communicates and evokes emotion in the product (which is far more important than you may think).
Rapid Prototyping. The prototypes work to capture the ideas of the product manager and designers into a prototype that can be tested on real users, and iterated upon.
Usability Testing. This person specializes in research and analysis of the users, evaluating whether products or prototypes allow a given user to easily achieve objectives. It includes recruiting appropriate test subjects, administering the tests, evaluating the results, and recommending alternatives.

You will also need to ensure the software you’re designing is feasible, so you need to have a software architect reviewing the progress and prototypes.

Chapter 5: Product Management vs. Engineering

Building The Right Product Versus Building The Product Right

Here are three ways you can use your engineers to come up with a better product:

Get your engineers in front of users and customers. Not only will they learn a great deal from seeing users struggle first hand, but they will get a better appreciation for the issues and their severity. This is often the inspiration for much better ideas and solutions. You can jumpstart this easily by inviting an engineer along to your prototype testing.
Enlist the help of your engineers in exploring what’s becoming possible as technology develops. Brainstorm the different technologies that are available or coming available, and how they might help solve the problems at hand.
Involve your engineers (or at least a lead engineer) or architect from the very beginning of the product discovery process to get very early assessments of relative costs of the different ideas, and to help identify better solutions. One of the most common mistakes that product managers make is to come up with a great product definition, and then throw it over the wall to engineering. That just postpones the critical negotiation process of what’s wanted vs. what’s possible until there’s not enough time to be able to make good and informed decisions.

Similarly, you can actually be a big help to your engineers. Here are three ways you can help them do their job:

Keep the focus on minimal product. More on this later, but your job as product manager is not to define the ultimate product, it’s to define the smallest possible product that will meet your goals. This point alone will fundamentally improve the dynamic between product management and engineering.
Do everything you can to minimize churn once engineering begins to develop the product. Churn is changing requirements and product definition. Some churn will be unavoidable, and engineers understand that some things are beyond your control, but remember that this is not the time for trying out your latest-and-greatest ideas.
There will inevitably be questions that arise during implementation, including use cases that were missed or weren’t completely thought through. This is normal, even in the best of product teams. However, your mission as the product manager during the implementation phase is to jump on their questions and get answers as fast as humanly possible, always keeping the focus on minimal product and minimizing churn.

Chapter 6: Recruiting Product Managers

Finding Great Product Managers

Personal Traits and Attitude

Product Passion
Customer Empathy
Intelligence
Work Ethic
Integrity
Confidence
Attitude
Skills
Applying Technology
Focus
Time Management
Communication Skills
Business Skills

Chapter 7:Managing Product Managers

Building The Team That Will Build Your Company

So here I’d like to discuss the role and responsibilities of those that manage product managers.Typically this individual is given the title Director or VP of Product Management.

These people have two essential responsibilities. First, they must build a strong team of product managers. Second, they are responsible for the company’s overall product strategy and the various products in the company’s portfolio.

Building the Product Management Team

When you hire a new product manager to the team, establish a program so that he or she can get the needed exposure to users and technologies.
If you determine that the product manager is unable or unwilling to do what is necessary to execute their duties at any level, it is your job as the manager to find someone that is.
Once you are convinced that the members of your team are capable of success and properly equipped to succeed, then you will need to step back and let these talented people do their job.
Note that you’ve first got to make sure you have strong people before you empower them. If you empower people who aren’t capable, you are abdicating your responsibility as manager.
Every good manager knows that the best way to look good is for the members of his or her team to look good. As such, always hire people that you believe are smarter than yourself, and then do everything you can to help them succeed.

Defining the Company’s Product Strategy

Even with the best team of product managers, each doing an outstanding job, you will still have cross-product conflicts as each product manager works to optimize his own product. The head of product management must work to identify and resolve these cross-product issues.
Similarly, the head of product management is responsible for the portfolio roadmap—taking an overall look at the many product releases that are planned, and considering the business needs and customer impact.
Finally, the head of product management will need to manage executive relationships within the organization. It is essential that all of the key players in the company—particularly the CEO—have a good and trusting relationship with the head of product management.

Chapter 8: Patton’s Advice for Product Managers

Managing By Objective

“Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity.”—General George S. Patton, Jr.

First, on the receiving end, customers and users will very often try to tell you as product manager how your product should work, rather than what your product should do. We all have experienced this, as it’s simple human nature for us to try to envision solutions to problems.

Also relevant is the other side of this point, where the product manager tells the user experience designers and engineers how to design and build the product, rather than telling them what the product needs to do.

All of the above also applies with engineers. The engineering team doesn’t appreciate the product manager spelling out the details of the implementation any more than the product manager wants the customer to dictate the specifics of the requirements.

So the more latitude you can give your engineers and user experience designers in coming up with the solutions to the problems you are trying to solve, the more likely they will come up with something that customers will love.

Chapter 9: Deputy Product Managers

The Smartest Guy In The Room

The bottom line is that these minds can be hidden anywhere—engineering, sales, customer service, professional services, the exec team, or your board of directors. It’s your job to find them. Now—how do you do that?

Ask! Ask at all levels of the company who people think the really great minds are, and you may be surprised by their answers.
MBWA. From the HP Way—Management By Wandering Around. Managers need to get out of their office or cubes and spend time with the people from across the company, not in meetings, but informally. It’s easy and it works.
Listen (really listen) to the dialog in meetings and conversations.
Keep your door open—make sure everyone knows that they are welcome to drop in with product suggestions.
Share. If you are willing to share with others the issues that you’re struggling with, you’ll find that word will get around and people may stop by with suggestions.
Hang Out. All too often the product people hang out with other product managers, and execs with other execs. But if you make an effort to spend time with people at all levels of your company, you’ll get a much better idea of what’s going on in general, and who the hidden gems are in particular.

Chapter 10: Managing up

Top 10 List

Measure and plan for churn. Churn is the term I use to represent the cost of the various drills, rework, and changes in plans that cause the frustration you feel in the first place. While you shouldn’t expect churn to go down to zero, you can constantly strive to reduce it. This starts by increasing awareness of churn, and that begins with measuring it. There are lots of ways to do this, but in one form or another, try to track how much of your week/month/quarter is spent on forward progress. Now that you’re more aware of the level of churn, it helps a great deal to plan for some amount of churn. When you’re scheduling your projects, know that there will be a percentage of your time devoted to responding to these changes and adjusting accordingly, and that some amount of your efforts will end up sitting on the shelf. It will help manage your stress level, make your schedules more accurate, and help you identify issues you can try to improve.
Communication style and frequency. Just as product managers are not all the same, managers are not all the same either. Some managers prefer to be kept apprised of every little detail on a continual basis. Others don’t want you to bother them unless there’s an escalation or serious issue that needs your manager’s help. Some prefer updates in writing with detailed supporting material, and others prefer a quick chat in the hall. You need to determine the style that your manager prefers and do your best to meet that need, even if it’s not your own preferred style.
Pre-meeting work. Most product companies have lots of meetings—too many in my view. However, the more influencers and stakeholders there are in your organization, the more you’ll be asked to have checkpoint and review meetings to keep everyone on track and informed. There are many techniques for running good meetings, but the main point here is to actually conduct the real meetings before your official meeting. This means going individually to the key influencers and stakeholders prior to the actual meeting and giving them a preview of your points, listening to their issues, and ensuring that they are already on board by the time the group meeting happens. If you do this well, the group meeting should be quick with no surprises. The formal meeting still has an important purpose however, which is for everyone at the table to see that everyone else is on board.
Recommendations, not issues. Most managers prefer to see your recommendations on how to solve problems you encounter rather than just a statement of the problem. Ideally, depending on the size of the problem, this means an analysis of several alternatives along with your recommendation and rationale.
Use your manager. Managers can often be a very useful tool that most employees underutilize. As an example, suppose there’s a problem you’re working to solve, and you have an analysis and recommendation, but some of the key influencers are not anxious to make the time available you need to pre-brief them as described in the pre-meeting work above. Your manager can often get the access you can’t. So provide your manager with the tools and the request that she hold this private session for you. Your manager will want to be prepared, but is often happy to help in this way.
Do your homework. One of the biggest mistakes product managers make is in not doing their homework. Managers are usually smart and can quickly identify holes in thinking and in plans—that’s their job. The best way for you to prepare for this is by doing your homework. You need to understand the issues thoroughly and be prepared.
Short e-mails. Another common mistake is that product managers like to write long, detailed e-mails to their managers, but then get frustrated when they’re not read or responded to. You need to realize that your manager is probably getting hundreds of e-mails a day, and is looking for short, to-the-point communications. The more senior the person you’re sending to, the shorter you’ll want the e-mail to be. Offer additional material, but don’t make the manager read more than a few lines.
Use data and facts, not opinions. When dealing with managers—especially senior managers—it’s essential to remember that your job is to provide the data and facts. Jim Barksdale, the former CEO of Netscape, had a great line when he was confronted with difficult decisions. He said, “If we’re going to make this decision based on opinions, we’re going to use my opinion.” If you do your homework, and have collected and laid out the data, your recommendation should be clear based on the facts and not opinion.
Evangelize. A big part of a product manager’s job is to evangelize the product across the organization. But few product managers seem to take this as seriously as I think they should. If you evangelize effectively, everything will become easier—especially working with other groups in the company. If they know what you’re doing and are excited about what your product will do for the company, they’ll be much more likely to find ways to help.
Low-maintenance employees. One of the secrets that nearly every manager thinks—but few will admit—is that what they’re really looking for in an employee is someone who is low maintenance. High-maintenance employees consume a disproportionate amount of the manager’s time and attention, and while it’s your manager’s job to ensure that his team is productive, there is only so much time in the day, and this type of hand-holding is not usually what your manager is anxious to spend his day doing. Don’t try to use your manager as a mentor—find another mentor from outside of your direct management chain. And be thoughtful of how you use of your manager’s time. I can promise you that your manager will appreciate it.

PART2 Process

Chapter 11:Assessing Product Opportunities

Defining The Problem To Be Solved

I ask product managers to answer ten fundamental questions:

Exactly what problem will this solve? (value proposition)
For whom do we solve that problem? (target market)
How big is the opportunity? (market size)
How will we measure success? (metrics/revenue strategy)
What alternatives are out there now? (competitive landscape)
Why are we best suited to pursue this? (our differentiator)
Why now? (market window)
How will we get this product to market? (go-to-market strategy)
What factors are critical to success? (solution requirements)
Given the above, what’s the recommendation? (go or no-go)

Where’s the Money?

I learned a long time ago that I could benefit a great deal from making a friend in the finance department. In every company I’ve ever worked at, I have asked the CFO for someone that could help me answer these questions. It always amazed me how willing these people were to help, and just how much information they had available for those who asked.

I’ve found that my friends in finance can help with three big things.

Understanding Your Product Sit down with your friend and ask for help determining and evaluating the financial aspects of your product, starting with the questions I posed above. If you have partnerships, read the contracts. If you license technology, look at the agreements. Ask your friend to help you assess your product. Is it carrying its own weight? Is it a good investment for the company? What trends does your friend see? Is the product heading in the right direction?
Understanding Your Customers While we typically have good tools for understanding how users behave on a Web site (via Web analytics), the finance department often has a wealth of additional information on the actual customers, accumulated from transaction histories, payment information, customer data, and management reporting. You both need to be sensitive about what information you can view and how you use it, but in terms of understanding your customers it can be extremely useful.
Preparing The Business Case You’ve got a great idea, but you’re not sure about the business case—now what? Your friend in finance can help. You’ll need to provide most of the inputs, but your friend will know how to put together the case. If it’s a good case, you’ll also find that having someone in finance who has studied the economics of the potential product can be a big help for you when discussing with senior management.

Chapter 12:Product Discovery

Defining The Right Product

Software projects can be thought of as having two distinct stages: figuring out what to build (build the right product), and building it (building the product right). The first stage is dominated by product discovery, and the second stage is all about execution.

Can You Schedule Discovery?

This notion of requirements and design as a sequential, predictable and scheduled phase in a product development process is so ingrained in our industry that it’s often one of the most difficult habits for product organizations to break. But we all need to get past this. Product organizations need to come to terms with the fact that the product invention process is fundamentally a creative process. It is more art than science.

This is why I prefer to think of this phase as “product discovery” more than “requirements and design.” I think this nomenclature emphasizes two all-important points:

First, you need to discover whether there are real users out there who want this product. In other words, you need to identify your market and validate the opportunity with your customers.
Second, you need to discover a product solution to this problem that is valuable, usable, and feasible. In other words, you need to design your solution and validate it with your customers and your engineering team.

Management especially struggles with this notion of product discovery. I think there are two underlying reasons for this:

First, the discovery process isn’t as predictable as we wish it was. Management fears you may spend months chasing a solution and end up with nothing to show for it. At least if they go ahead and build, they can say that they shipped something. It’s the same reason why many managers are uncomfortable with Agile methods like Scrum. They want to know how many 30-day sprints it will take before they’re done.
Second, the most highly constrained and expensive resource in just about every software product organization is the engineers, and the thought that an engineering team might be sitting around with nothing to do but play Foosball just drives management nuts.

Chapter 13:Product Principles

Deciding What’s Important

Another tool that can be a big aid in determining the right tradeoffs and priorities is a good set of product principles. The product principles are a public declaration of your beliefs and intentions. I like them because if they’re done well, they can serve as a useful complement to a product strategy and significantly speed the product discovery process.

Coming up with product principles means deciding what is important to you—and what is incidental—and deciding what is strategic and fundamental, and what is simply tactical and temporary.

There are other benefits to developing product principles. The process serves as a way for me to understand the DNA of a company, and what the founders hope to achieve. Most importantly, it serves as a framework for evaluating the many alternatives in front of every product and company.

An example of a product principle for a movie site may be that the team believes that the user community’s opinions on movies are more valuable than those of professional reviewers. Later, if a studio wants to place reviews on your site, you can then decide if this is consistent with your principles or not.

Finally, many teams make a couple of mistakes when they first try creating a set of product principles. The first is that they state principles that are so generic that they aren’t really useful (“must be reliable”). The second is that they confuse their product principles with design principles. For example, a common design principle is to provide a well-lit path (so the user always knows where to go next). That’s not a product principle.

Resolving Conflicts

For virtually all product decisions, the key is to properly frame the decision to be made, and to first get everyone on the same page in terms of:

What problem exactly are you trying to solve?
Who exactly are you trying to solve this problem for—which persona?
What are the goals you are trying to satisfy with this product?
What is the relative priority of each goal?

Chapter 14: The Product Council

Timely And Definitive Product Decisions

Purpose

The purpose of the product council is to set the strategic product direction, allocate product resources and investments, and provide a level of oversight of the company’s product efforts. This group is not trying to set the company’s business strategy, but rather—given the business strategy—come up with a product strategy that will meet the needs of the business. The decisions this group makes will directly impact the success of the business.

Membership

CEO, COO or Division GM
VP/Director of Product Management
VP/Director of User Experience Design
VP/Director of Marketing
VP/Director of Engineering
VP/Director of Site Operations
VP/Director of Customer Service

Specific Responsibilities

For each product effort, there are four major milestones for product council review and decision making:

Milestone 1: Review proposed product strategies and product roadmaps, and initiate opportunity assessments for specific product releases. That is, select the product opportunities to be investigated.
Milestone 2: Review opportunity assessments and recommendations, and issue go/no-go decisions to begin discovering a solution.
Milestone 3: Review product prototypes, user testing results and detailed cost estimates, and issue go/no-go decision to begin engineering.
Milestone 4: Review final product, QA status, launch plans, and community impact assessments, and issue go/no-go decision to launch.

Additional Notes

For small organizations, one product council typically covers all products. For large companies, the product council typically aligns with the business unit.
There is no need to review minor updates or fixes in this process—there should be an expedited process for the minor changes needed to run the business (which are typically more content related).
These are not product design sessions—if there are issues with the product then the team should work on them and return to the product council when they have been addressed.
While you will often have a very preliminary sense of estimated cost at Milestone 2, no one should take that estimate very seriously as the solution has not yet been outlined—anything beyond “small, medium or large” effort is not fair to engineering. However, the estimate of time and cost at Milestone 3 should be detailed, and something the full product team is prepared to commit to.
You will need to decide if this group will also address issues of policy (such as product end-of-life policy, privacy policies, etc.) Often, this group does discuss such issues, but these topics can become long unstructured discussions if not managed. Make sure policy discussions don’t delay product oversight responsibilities.
The frequency of meetings depends on the number of product efforts going on. You may only need to meet for one hour a month, or you may need to meet two hours a week.
It can be useful for the product council to review the business performance of the products that have launched. The product council may request a presentation on the business results of the product launch, typically 3-6 months post-launch. This sort of accountability will help the council better understand which investments and decisions they made were good ones, and why.
Ideally, the product manager should present his product to the product council. His manager should help him prepare for this presentation, to ensure that he has done his homework and the recommendations are sound. The smart product manager will have individually briefed the members of the product council prior to his presentation to learn of any issues and resolve them, so he’s not caught by surprise.

Chapter 15: Charter User Programs

Your Product Development Partners

The benefits to the customers/users that join

They get early and significant product input—they recognize the problem that this product is trying to solve, they feel the pain, and are anxious to ensure they find a good solution
They get early access to the product—again, they feel the pain, so the sooner they can get relief the better
Typically, there is a significantly reduced cost, if any

The benefits to you

You have a set of users and customers available for ongoing questions and dialog
You have access to the customer’s offices and the users at that company (or the company’s developers if it’s a platform product)
The customers/users agree to come to your offices periodically for group sessions
The customer agrees to deploy test versions promptly and provide timely feedback (you’ll typically be there with them)
If they are happy with the delivered product, the customer agrees to serve as a public reference customer

A few critical points

It’s important that the customer not pay in advance to participate in this program. That would make this a very different type of relationship. You want a partner in developing the product—you do not want to build a custom solution just for them, and you’re not a project shop. You can take their money after you deliver them a product they love.
If you’re like most companies, you will be overwhelmed with customers that want to participate. It really is a great deal, and customers know this. If you have a sales organization, they’ll try to use this as a bargaining chip, and the result is that you’ll be leaned on to include many more customers than you can handle. This will take finesse at times, but it’s important that the members of the charter user program be the right set. (Sometimes companies create an early release program that is available for those customers that want the software early, but aren’t right for the charter user program. This is fine. Just make sure you don’t accept more than about 10 customers into the charter user program as you won’t be able to manage them and work as closely as you need to with that many.)
If you find that you are having real trouble recruiting charter users and customers, then it’s very likely you are chasing a problem that isn’t that important, and you will probably have a very hard time selling this product. This is one of the very first reality checks to make sure you are spending your time on something worthwhile. If customers aren’t interested in this problem, you may want to rethink your plans.
You need to make sure your charter users and customers are truly from your target market. It’s easy to end up with early adopters, who are much more tolerant and can easily lead to a product of interest only to early adopters (See the chapterEmotional Adoption Curve).
You will need to explain to each member of the program that you are trying to come up with a general product—something you can successfully sell to a large number of customers. You’re not trying to build a custom solution that works only for that particular company, and they wouldn’t really want that in any case (because if you can’t build a real business with that product, you’ll go under and they’ll be left with unsupported, dead-end software). You are, however, deeply committed to coming up with a product that works very well for them.
You need to think of these charter users and customers as development partners. You’re in this together. You need to treat them as colleagues. You are helping each other. You’ll find that the relationships you create can last for decades.
You will be interacting with these people throughout the project lifecycle—you’ll be showing them prototypes and testing with their users, you’ll be asking hundreds of detailed questions, and you’ll be testing release candidates in their environment.
Make sure you release the software to these people before the general release, and make sure they are live and happy before the public release. When you launch, they’ll be ready to stand up for you.
You’ll likely be working very closely with product marketing on preparing the charter customer to be a public reference, and they’ll often help with finding these partners as well.
If your product is a platform product (others will write and deliver applications on top of your product), then this program is especially critical. The main difference is that you want to focus on ending the program with six reference applications rather than six customers. And you’ll need to work closely with your application partners to ensure that the applications they build on your platform are also successful with their users (and a great way to do that is to encourage them to have charter users).

Chapter 16: Market Research

Understanding The Capabilities And Limitations

Capabilities

Customer surveys. The Web has made this approach easy and powerful. Combined with techniques such as conjoint analysis (to help users rank order their preferences), customer surveys are so easy and so inexpensive, that they’re a must-do for any product. However, there are two important things to note. First, there is an art to coming up with the survey questions themselves—it’s not as easy as it sounds. Think hard about the questions and context, otherwise you’ll find that people in your company will discount the results. They’ll argue “garbage in, garbage out,” which may very well be true if the questions are unclear or biased in their phrasing. Second, set expectations in your company that this data is but one input to the answer—it isn’t the answer itself. You may very well have every user come back and say “I want X” and it still may make more sense for your company to instead give them “Y.”
Site analytics. If your product is a Web site, there are terrific tools out there for understanding how your users are using it. You’ll have to do a little work to make sure your site is instrumented appropriately, but it’s well worth it. Get the site analytics in place early and continually watch and learn—and adjust. If your product is not a Web site, you can usually instrument your product so that it records valuable information about how the product is used and sends the data to you. You may have to be clear to your customers that you’re sending aggregated data and nothing personally identifiable, but it’s worth getting it.
Data mining. You’ll collect data from many sources, such as the site analytics I’ve mentioned above, billing and user account information, and your own product’s data. Today there are better tools than ever for analyzing and harvesting that data. Want to know the gender breakdown of people that use some combination of your services? Or the activity level tiers and distribution of a specific persona? You can usually answer these and thousands of other questions easily and quickly with the new breed of data analysis tools.
Site visits. There is no real substitute for visiting with your users in their native habitat—home, office, mall—wherever they will use your product. It can be expensive and time-consuming yet, whenever I do a site visit, I realize something I wouldn’t have known any other way. Site visits are extremely valuable, but for cost and time considerations you’ll want to pick them carefully.
Personas. I like personas, especially for product definition and design. Market researchers use personas too, although not for the same purposes. It’s essential to realize that there is no single “user” and your job is to deeply understand the major types of users out there—those who are your current customers, and those you want to have in the future. See the chapter Personas for Product Management.
Usability testing. I am a huge fan of usability testing, and advocate its use early and often (see the chapter Prototype Testing). You can also use this tool with existing products to better understand what users really think. Essentially, it’s a way to see through their eyes while they use your product—you can gauge enthusiasm or frustration, and watch actions (and not just words). There are tools for doing this remotely, and for recording and analyzing what exactly people do, but this is all just icing on the cake.
Competitive analysis. Too frequently product teams write off competitors as clueless, but in my experience every product has at least some things that the product does well, and it’s your job to find these things. Learn from their successes and their mistakes.

With these tools and techniques you can get some very real help answering the following important product questions:

Do you understand who your users really are?
How are users using your product?
Can users figure out how to use your product? Where do they stumble?
Why do users use your product?
What do users like about your product?
What do users want added to or changed in your product?

Limitations

Notice that while these questions are critically important, they do not directly address the fundamental question for most product people: What product to build? This information certainly is an input to the product creation process, but you’re in trouble if you try to steer your product with market research.

The product discovery process is about answering these questions:

What technologies can I apply to solve this problem in a better way?
What should the user experience be?

Chapter 17:Personas for Product Management

Understanding The Target User

There are numerous benefits of using personas as a tool for product management:

Personas help you prioritize what’s important. If you have decided to make “Mary” the target for this release, then if this feature is critical for “Mary” then put it in, if it’s for “Sam” then it’s out. As you can see, just as important as deciding who a release is for, is deciding who it is not for. It is an extremely common mistake for a product to try to please everyone and end up pleasing no one. This process helps prevent that.
One of the most common mistakes product teams make is confusing themselves with their customers. One thing I really like about personas is that they help shine a light on this all too prevalent problem.
Many products have many types of users—different types of end-users, managers, administrators, etc., and it’s easy to think that you should just put some features in for each of these people, and again, you can end up with a muddled mess. This is partly a design problem, but personas often help you prioritize the importance of these different users, and also realize where you need a separate user experience.
Personas are a very useful tool for describing to your entire product team who the product is for, how they will use it, and why they will care.
More generally, much like the product principles, personas have the benefit of rallying the team around a common vision. There are literally thousands of details that will have to be addressed in the course of a product release. The product manager (or designer) can’t possibly make every one. If every manager, designer, writer, developer, and tester has taken the product principles and personas to heart, then when faced with an open question, they are more likely to make the right call.

These are some pretty great benefits. But there are also some pitfalls to watch out for:

Some teams create personas but they don’t take the next step—to make the hard choices about which persona should be the priority. It’s not ok to say your product is for everyone—you’re only deluding yourself. While this is extremely difficult for most product managers, I try hard to get the product manager to focus each release on a single primary persona. It’s not that the release won’t be valuable and usable by others, but your focus on each release should be to do a great job for just one type of target user.
Sometimes teams create personas based on their assumptions and stereotypes of their users, and they don’t actually take the time to talk to real users and verify if these theoretical people really exist. I have been surprised many times—so many times in fact that I have learned to consider my initial impressions as just a theory, and hold off on real judgments until after talking with real users. In no way is the process of creating a persona a substitute for talking face-to-face with real target users, and testing your designs on real users.
One question that often comes up is—as you recruit users for your prototype testing—do you only test with users from your primary persona? Certainly you need to make sure your product is great for the people it is intended for, however, you’ll want to test with some people from outside this persona as well, as you won’t have the luxury of having only primary personas using your product. So for prototype testing, you’ll want to recruit a range of possible users.

Chapter 18:Reinventing the Product Spec

R.I.P. PRD

Here are what I consider the requirements for a good and useful product spec:

The spec must describe the full user experience—not just the product requirements but also the user interaction and visual design. By now, hopefully everyone recognizes how closely intertwined the requirements are with the user experience design.
The spec must accurately represent the behavior of the software—and we need to acknowledge that words and pretty pictures are just too limited in their ability to describe this behavior.
There are several critical consumers of the spec—engineering, QA, customer service, marketing, site operations, sales, and executives. As such, the spec needs to communicate the behavior of the product in a way that all these groups get what they need.
The spec will change—the rate of change should slow down dramatically once engineering gets started, but there will be decisions and issues that arise, and the spec should change to reflect the very latest decisions.
There are a number of artifacts in the creation of a spec, such as lists of prioritized requirements, wireframes, and mock-ups, but there needs to be a single master representation of the spec to minimize confusion, ambiguity and versionitis.

In my mind, there’s only one form of spec that can deliver on these requirements, and that is the high-fidelity prototype.

Chapter 19:Design vs. Implementation

Define The User Experience Before Proceeding To Build

That said, one thing that many teams try to do in parallel—but should not—is user experience design and implementation.There are several reasons for this:

First, there is a dynamic in software teams that is important to recognize: once implementation begins, it becomes increasingly difficult to make the fundamental changes that will likely be necessary as you work through your user experience design ideas. Partly this is technical—engineering teams must make some early architectural decisions based on assumptions about the requirements and designs in order to make progress. These early decisions are important and have big consequences. Partly, this is psychological—there is a mindset that takes hold once the team shifts into implementation mode, and it’s demotivating to go backwards. Partly, this is practical—the clock is ticking, and rework and churn just compounds the pressure the team is under. So even though methods like Agile advocate embracing change, you quickly find that some changes are much more welcome than others.
Second, user experience design deals with very difficult questions of both usability and value and, in order to come up with a product that is both usable and valuable, you will need to try ideas out—early and often. One common response is “We’ll get feedback during beta,” or with Agile teams, “We’ll test the idea out at the end of the sprint.” Unfortunately, this is far too long to wait to test out an idea. A good user experience designer will want to try out dozens of ideas and approaches in a matter of days, and the thought of waiting even for a two- to four-week sprint would be debilitating as the frequency is an order of magnitude too slow.
Third, and related to the above, I argue that to try out an idea you need a high-fidelity prototype. Some will argue that the beta release can be viewed as the prototype, or that the result of the sprint can be viewed as the prototype. But even beyond waiting too long for that software to be available for test, it’s important to realize that prototype software is far different than production software. Prototype software needs to be truly disposable. It needs to be something that can be changed substantially in a few hours. What is necessary for production software is like dragging around a boat anchor for a prototype. You’ll also find that different types of people like to write prototype versus production software.
Fourth, while it often makes excellent sense to break up a release into several iterations to implement (this reduces risk, improves quality, and eases integration) a user experience is often not something that can be designed in pieces. You have to look at the user experience holistically—it has to make sense to the user at each release. While it’s easy to “stub out” software that’s not yet available, it’s not so easy to do the same for the user experience.
Finally, user experience designers don’t necessarily require a lot of time (just as with software engineering, it depends on the methodology they are using, the particular product requirements, and the skills and experience of the specific people), but they do require some time. Even if it’s only a week or two.

Fortunately, this really isn’t a hard problem to solve. The key is that the user experience design needs to happen before the implementation begins. This is one situation where sequential is important. The requirements and design happen together, and then implementation and test can happen together.

For Agile teams, the product manager and user experience designers use the “sprint zero” concept to stay a step or two ahead of the engineers. You are still working to design in as small of increments as possible. It requires a somewhat richer definition of what’s in the backlog, but the team will be happier and the product will be better for it.

Chapter 20:Minimal Product

Cutting Features Versus Slipping Dates

Instead, I argue for a very different model:

First, the job of the product manager, working with his designer, is to come up with a high-fidelity prototype with the minimal functionality necessary to meet the business objectives, yet with a user experience that users can figure out how to use—and actually want to use. The reason it’s so important that the team come up with the minimal functionality is to minimize implementation time and user complexity.
Second, starting at the very beginning of this design process, someone from the engineering team (typically an architect or lead engineer) needs to participate in reviewing the product ideas expressed in the prototype, so she can help the product manager and designer understand the relative and absolute costs of the various product ideas. She can point out any dangerous directions the product might be heading in, or she can go investigate any areas she’s unsure about. But by the time the prototype is ready, this engineer must have provided detailed estimates of the surviving features. So the many trade-offs of what is in and what’s cut have already been made—and made collaboratively—and at this point the engineering team must have a detailed estimate that they can commit to.
Third, it’s essential that this prototype be validated (tested) with real target users. Before committing the resources of the full product team, the product manager and designer must be confident they have come up with something that will succeed. It’s not enough to just believe the product definition is good, you have to test to make sure. Just as you wouldn’t allow an engineer to ship code just because he or she believed it was good, you must test that code to make sure.

This is why once you’ve come up with this minimal product—and have tested it with target users to the point that you have evidence it will work—you can’t later just cut out some more features and assume it will still work with users. If you could, then you didn’t really identify the minimal product earlier.

Similarly, for essentially the same reasons, once the engineering is underway, the product manager can’t just keep tossing in additional requirements. By far the most common reason product managers request changes to the spec is a consequence of not really thinking through the requirements in the first place. The high-fidelity prototype will force most of these issues to the surface much earlier in the process.

So by all means prioritize as you’re thinking about the requirements and what’s most important, but by the time you come up with your final spec, make sure your product is already the minimal possible. Then yank all those P1/P2/P3 annotations from the spec, and make it clear to the team that it describes an entire product. And if you remove a leg, then as an old boss of mine would say, that dog won’t hunt.

Chapter 21:Product Validation

Evidence of Valuable, Usable And Feasible

There are three important types of validation that you need to perform before you hand over a final product specification to the engineering team:

Feasibility Testing

One immediate question is whether or not the product is going to be buildable, with the technology time and funds currently available. Your engineers and architects should be very involved in investigating technologies and exploring possible approaches. Some paths will be dead ends, but hopefully others will prove viable.

What is most important is that, if there are obstacles the engineering team considers insurmountable in this product’s timeframe, it is important to know this now rather than much later in the process—after the time and money has been lost.

Some products have more technical risks than others, but if yours has significant risks regarding feasibility, make sure you address them early.

Usability Testing

Your interaction designers will be working very closely with you to come up with ways of presenting the functionality in the product so that users can figure out how to use it.

Usability testing will often uncover missing product requirements and, also—if done well—identify product requirements that are not as necessary as originally thought. You should plan on multiple iterations before you come up with a successful user experience.

The purpose of the prototype is to have something to test on real people, and usability testing is the art and science of getting useful feedback on your product from your target customers. Certainly, the product manager and designers will use the prototype and learn a great deal from it, but there is no substitute for putting the prototype in front of real people from the target customer base.

Note that for usability testing purposes, it is perfectly fine if complicated back-end processing is simulated—the key is to evaluate the user experience.

Value Testing

Finally, it is not enough to know that your product is feasible to build and will be usable. What really matters is whether or not your product is something users will find valuable and want to buy—that is, how much do users and customers like and value what you’re doing?

This testing can typically be combined with the usability testing process, and the prototypes used are the same. But in usability testing, you’re seeing if users can figure out how to do the necessary tasks, while in value testing you’re seeing if they actually care about those tasks and how well you’ve solved them.

Chapter 22: Prototype Testing

Putting Your Ideas In Front Of Real Users

The primary reason to create a high-fidelity prototype is to help you gain a much deeper understanding of your product, and—ultimately—so that you can test your ideas with real users before you have your engineering teams take months to go build something that you have no real evidence will serve its purpose.

Finding Test Subjects

Before you do the prototype testing, you’ll need to round up some test subjects. If you’re using a lab they’ll recruit and schedule the users for you, which is a big help, but if you’re on your own, you’ve got several options:

If you’ve established a charter customer program as I described in Charter User Programs, you should have quite a few users readily available. If you haven’t yet established your program, then you should.
If you’re doing a product for business, then trade shows are a great source of target customers.
It’s increasingly common to advertise for test subjects on Craigslist. If you do this, try to keep your participant description a notch more general than specific, and then when you call interested test subjects to explore their participation you can screen for the right match.
For consumer products you can use your “friends and family” network, but try to avoid people too close to you, and those in the tech industry, unless that’s specifically your target. Be sure to use subjects from outside this network, too.
If you have a list of user e-mail addresses, you can do a selection from there. Often your marketing team can help you narrow down the list.
You can solicit volunteers on your Web site—lots of major sites do this now. Remember: you’ll still call and screen the people to make sure you don’t get a sample skewed with early adopter types.
One technique I especially like for medium to larger companies is to set up regular prototype test sessions—say every other Friday—where you arrange for 10-20 or so users to come into your offices for a couple hours each. Your product managers sign up for the time slots, so a given user might test a couple prototypes each. I like this because one person can do the logistics of invites and screening, and product teams can count on a ready set of test users on a steady basis.
You can always take your show on the road and go to where your users congregate. If you’re doing an e-commerce product, you may want to go to a shopping mall. If you’re doing a sports product, go to a sports bar. If your product addresses a real need, you won’t have trouble getting people to give you an hour of their time. Just bring some thank you gifts, and try not to look like you’re trying to convert their religion.
If you’re asking users to come to your location—especially for business use—you will likely need to compensate the people for their time. If you’re doing a consumer service product, a big sincere thank-you along with a hat with your company logo on it will often suffice, as people genuinely want to help in the creation of products—especially for companies they like. However, if you do compensate test subjects, consider providing something along the lines of US$50 of credit on your site.
Realize that there’s a very high no-show rate when you schedule people to come in for testing—it’s just a fact of life. While this number can rise to as high as 30%, you can drop it to the 5-10% range by giving your subjects a personal phone call the day before. Even leaving a voicemail message will help, but note that sending an email message does not work equally well.

Preparing the Test

You’ll need to define the usability tasks you’ll want to test, and the interview questions concerning value:

Define in advance the set of tasks you want to test. Usually these tasks are fairly obvious. If you’re building an e-mail client, for example, your users will need to do things such as compose a message, read new mail, and file away messages. There will also be more obscure tasks, but concentrate on the primary tasks—the ones that users will do most of the time. If you have time, you can get to less common tasks but it’s essential the key tasks are tested well.
You have a one-time-only opportunity with each user you test—the opportunity to learn how they think about this problem today, without your product. If you’re testing a new online restaurant rating service, rather than start them out at your prototype’s home page, you might instead want to start them out with an empty browser and see what they do. What review sites do they use today? Do they use Google or Yahoo’s search to find the specific restaurant, or do they go somewhere like OpenTable or Zagat? Do they search by neighborhood, by cuisine type, or price range? This type of incredibly valuable information is missed if you jump right into your prototype, which will necessarily have quite a few assumptions built in. Once your test subjects have the opportunity to play with your prototype for a while, they can tell you what they like better, but they will no longer be thinking about the problem the way a first-time visitor would.
You’ll then want to get them to your prototype, but there’s one more thing before you jump into your tasks. See if they can tell from the home page or landing page of your prototype what it is that you actually do, and especially what might be valuable or appealing to them. Again, once they jump into tasks, they’ll lose that first-time visitor context, so don’t waste the opportunity. You’ll find that landing pages are incredibly important to bridging the gap between expectations and what the site actually does.
After you’ve seen if your user can figure out how to do the tasks you’re testing, now is the right time to have a conversation with him or her. Think of it as a one-person focus group. Does the person use a different product or site for the same purpose today, or is this something they do manually or offline? How much better is this than what they use today? And don’t forget to ask my favorite question, Net Promoter Score (NPS): How likely would you be to recommend this product to your friends? Now that the user has interacted with your prototype, they understand the topic and you can have an extremely useful dialogue with them about this problem. Most importantly, you’re trying to gauge how much this person values the product.
It’s useful if you structure your questions on a scale, such as 0-10, or with numeric answers in general. This is so that you can track the averages as they improve. One technique I like for gauging value is to ask how much the user would be willing to pay for it, even if you have no intention of actually charging for use this way. It’s a way to assess value and—especially—to track how the average value goes up or down over time as you change the prototype.
Note that you don’t have to wait until you have a complete prototype in order to begin testing. You can start with the main tasks, and it’s okay if you have dead ends in the rest of the prototype. If the user wanders over to one of those dead ends, just ask “And what would you expect to happen if you did that?” This is a great question whether you have that path laid out or not. If you do have it laid out, you can see if they match. And if you don’t, you’ll get important info about what you’ll need to do.

The Test Environment

Here’s how to prepare your test environment:

Formal testing labs will typically have setups with two-way mirrors or closed-circuit video monitors, as well as cameras that capture both the screen and a frontal view of the user. Just know that while that’s great if you have it, you do not need these things to have an extremely useful and valuable test. I can’t count how many prototypes I’ve tested at a tiny table at Starbucks—just big enough for a laptop—with three chairs around the table. In fact, in some ways this is preferable to the testing lab because the user feels a lot less like a lab rat and may be more candid and open in his or her responses.
The other environment that works quite well is your customer’s office. It may be time consuming to go there and get set up, but even 30 minutes in their office will often tell you a lot. And because they are “master of their domain,” they’re frequently very open and talkative. Also, all the cues are there in the office to remind them of how they might actually use the product in their daily routine. You can also learn a lot from observing what the office looks like. How big is their monitor? How fast is their computer and network connectivity? How do they communicate with their colleagues on their work tasks?
There are tools for doing this type of testing remotely, but while you can see where their mouse is, and what the user is clicking on, it’s not the same as looking at the person’s eyes and body language. So, again, while more testing is generally better, this is not a substitute for face-to-face testing.
As product manager, you need to make sure you are at every single test—do not delegate this task. Real value comes from experiencing as many users as possible—first hand—interacting with and responding to your ideas. Even if you use an outside firm to arrange and administer the tests, you need to be there with them during the testing. No one knows your product as well as you do, and you will have insights from watching the slightest hesitation or confused look, or the nuance of a question that reveals that your test subjects don’t understand the conceptual model or particular feature. What gets summarized for you by a proctor will probably miss several key insights.
Some people believe that the product manager (and the interaction designer) are too close to the product to do this type of testing objectively—that they may either get their feelings hurt or only hear what they want to hear. My view is that good product managers and interaction designers get past this very quickly. They know they will get the product wrong initially—that almost nobody gets it right the first time—and they know that learning from these tests is the fastest path to an inspiring product. So to me the benefits far outweigh the risks.
Ideally, you should have one person administer the tests and another person taking notes. It’s very useful to have someone to debrief with afterwards to make sure you both saw the same things and came to the same conclusions. That said, if it’s just you and your laptop—and you’ve got a ready and willing target user in front of you—do it. It’s all good.
If you as product manager have a user researcher or usability engineer along with you, let him or her administer the test while you take notes. Otherwise, you’ll probably be the one that administers. It’s great to invite others on the product team to be your note taker. Most often this person will probably be the interaction designer, but the visual designer, managers, and especially engineers are all useful and they’ll get a lot out of the experience.

Testing Your Prototype

Now that you’ve got your prototype ready, you’ve lined up your test subjects, and you’ve prepared the tasks and questions, here are a set of tips and techniques for administering the actual testing:

Greet the person warmly and offer a coffee or bottle of water, but the sooner you get to the prototype the better. Tell your subject you’ll chat with them after they test the prototype, but you want to get their untainted impressions first. The more you chat beforehand, the more clues you are giving away and the less of a true first impression your test subject can provide. If more than five minutes goes by without the user starting in on the prototype you are talking too much.
After your greeting, be sure to tell him or her that (1) this is just a prototype—it’s a very early product idea—and it’s not real, (2) they won’t be hurting your feelings by giving you their honest opinion—good or bad, and (3) you’re testing the prototype—you’re not testing him or her. Your test subject can’t pass or fail—only the prototype can pass or fail.
When testing, you’ll want to do everything you can to keep your users in “use mode” and out of “critique mode.” What matters is whether users can easily do the tasks they need to do, and whether they value the product. It really doesn’t matter if the user thinks something on the page is ugly or should be moved or changed. Sometimes misguided testers will ask users questions like “What three things on the page would you change?” To me, unless that user happens to be an interaction designer, I’m not really interested in the answer to that question, or others like it. If users knew what they really wanted, software would be a lot easier to create. So watch what they do more than what they say.
During the testing, the main skill you have to learn is to keep quiet. Normally, when we see someone struggle, most of us have an urge to help the person out. You need to suppress that urge. You have to turn into a horrible conversationalist and get comfortable with silence.
There are three important cases you’re looking for: (1) the user got through the task with no problem at all and no help, (2) the user struggled and moaned a bit but eventually got through it, or (3) the user got so frustrated he gave up. Sometimes people will give up pretty quick, so you may need to encourage them to keep trying a bit longer. But if the user gets to the point that you believe he would truly leave the site and go to a competitor, then that’s when you note he truly gave up.
In general, you’ll want to avoid giving any help or “leading the witness” in any way. If you see the user scrolling the page up and down and clearly looking for something, it’s okay to ask the user what specifically he’s looking for, as that information is very valuable to you. Some people ask users to keep a running narration of what they’re thinking, but I find this tends to put people in critique mode, as it’s not a natural behavior.
Act like a parrot. This helps in many ways. First, it helps avoid leading. If your test subject is quiet and you can’t stand it any longer, tell them what they’re doing: “I see that you’re looking at the list on the right.” This will prompt them to tell you what they’re trying to do, looking for, whatever. If your subject asks a question, rather than giving a leading answer you can play back the question to them, “Will clicking on this make a new entry?” The subject will usually take it from there because they’ll want to answer your question: “Yeah, I think it will.” Parroting also helps avoid leading value judgments. If you have the urge to say “Great!,” instead say “You created a new entry.” Finally, parroting key points also helps your note taker because he or she will have more time to write down important points.
Fundamentally, you’re trying to get an understanding of how your target users think about this problem, and to identify places in your prototype where the model the software presents is inconsistent or incompatible with how the user is thinking about the problem. That’s what it means to be counterintuitive. Fortunately, when you spot this it is usually not hard to fix, and can be a big win for your product.
You will find that you can tell a great deal from body language and tone. It is painfully obvious when test subjects don’t like your ideas, and it is also clear when they genuinely do. If they like what they see, they’ll almost always ask for an email telling them when the product is out. And if they really like it, they’ll try to get access from you before it’s released to the general public. When I attend the prototype testing with my clients in Germany, even though I don’t speak German, it is obvious what the issues are—which ideas work well and which ones don’t.

Updating the Prototype

The point of this prototype testing is to identify what you need to fix in the prototype to make it more valuable and usable. So, as quickly as possible, you’ll want to correct the problems.

Some people believe you have to freeze the prototype, the tasks, and the questions for a complete round of testing (generally 6-8 users) before drawing any conclusions. I don’t think that’s true. I have found that you can significantly accelerate the process of getting to a good product by responding more quickly to feedback.You don’t have to be hit on the head by eight users in a row to know you need to fix something big. So go ahead and fix it when you feel you’ve identified a problem, even if it’s after only two or three users. The harder question is deciding when you’re done. Generally, if you can get through six consecutive users who understand and appreciate the value of the product—and can get through the key tasks—you’re in good shape and you’ve done your job.
You might determine that you just aren’t able to get people interested in this problem, or figure out a way to make the product clear or usable enough that your target users realize its value. In this case, you may decide to stop right there and put the idea on the shelf. Some product managers consider this a big failure. I view it as saving the company the wasted cost of building and shipping a losing product, not to mention the opportunity cost of what your engineering team could be building instead.

Chapter 23:Improving Existing Products

It’s Not About Adding Features

As with new product development, everything starts with having a very clear understanding of what you’re trying to achieve. For example, let’s say you’re the product manager responsible for new insurance coverage applications at an online insurance site.

There are all kinds of great metrics for you to track. How many users visit the start of the application process? How many drop off at each page? How many refuse to give personal information? How many confirm their e-mail addresses? How many complete the process?

Let’s say that today only 7% of the people who begin the registration process actually complete it. If you can drive that number up to 15%, look what you’ve just done for your product and your company.

To accomplish this goal, you might find that you need some new features, and the justification for the new feature is the degree to which it can improve these metrics.

Remember that it’s not about what a particular customer thinks is important to add, or the result of a survey, or a focus group. What matters is what actually moves the needle on the metrics you are driving towards.

Chapter 24: Gentle Deployment

Help Prevent User Abuse

User abuse is when you unnecessarily and (hopefully) unintentionally mistreat your users by releasing changes to the user community that they don’t appreciate. I know it’s hard to believe that not every one of your users is waiting excitedly for all of your changes, but it’s true. There are several reasons why your users may feel this way:

They may not have received any notice of the changes, so they were caught by surprise—and they weren’t in the mood for a surprise.
They may not have time at the moment to learn the changes and you don’t have a way for them to continue to use the old version until they do.
The new change may not actually work.
The new change may be incompatible with early versions (such as for accessing data).
The new change may work but it is perceived as gratuitous.
They may already be fatigued from all of the changes you have recently made.
They may have their own layer of process or behavior built around your previous version, and now that is broken and they have to update it.

In the spirit of minimizing the disruption caused by change, there are several techniques that can be useful in deploying changes gently.

First, do everything you can to communicate the changes in advance, through vehicles such as newsletters, onsite education, and tutorials. But remember that many people will have neither the time nor the inclination to read what you write, so this technique can only take you so far.
Second, if there is any question about the new version of your product working properly—either due to reliability issues, or scale, or performance—then you need to redouble your QA efforts to ensure that you won’t have to rollback your updates, which compounds community angst significantly.
Third, if the change is significant, it may be important to contain the risk by pursuing some form of gentle deployment such as parallel, or incremental deployment.

You can do this by deploying a parallel version of your product and inviting people to opt-in and try out the new version when they have the time. Allow those who try to use the new version to make it their default if they like it. Once you are confident that the new version is working well—and the majority of your community has converted to using it—you can make it the default and allow customers to “opt-out” and continue to use the old version for a period of time if they don’t have the time to learn the changes immediately.

Another gentle deployment approach is to deploy regionally—first trying out the new version in a limited area of the country or world, and then expanding. Or you can deploy the changes incrementally—introducing the changes in bite-size pieces over time.

Chapter 25: Rapid Response

Finish What You Start And Save Entire Release Cycles

For consumer Internet services, it has never been easier to understand how people are using your product or service. It is easy to instrument and track activity—there are many products in this space. Services such as Google Analytics(www.google.com/analytics) can quickly and easily tell you a great deal about how your users are using your service.
For enterprise software, I like to send members of the product team—product manager, engineers, designers—out to the customer site to be there with them when they install the software and work to get the software live and in use. It is amazing how much faster issues are identified and resolved when a team member understands she’s going to be at the customer site until the customer is live and referenceable.

Once the issues have been identified, the product team (product manager, interaction designer, lead engineers, customer service, marketing, etc.) needs to meet no less than daily, prioritize the issues, and discuss the best way to respond. The result might be a “hot fix” that is rushed to the site, or possibly additional content that explains problem areas. If the team is prepared for these changes—and understands how crucial it is to identify and respond quickly—then, in a very short amount of time, it can make substantial improvements to the effectiveness of the product or service.

Chapter 26:Succeeding with Agile Methods

Top 10 List

Note that this list is meant for product software teams. For custom software, there are some very different considerations.

The product manager is the product owner, and he represents the customer. He will need to be extremely involved with the product development team, helping to drive the backlog and especially answer questions as they arise. Some misguided product managers think they get off easy in an Agile environment—they couldn’t be more wrong. Some also like to have different people covering the product manager and the product owner role, but this is usually just a symptom of a deeper problem (see the chapter Product Management vs. Product Marketing)
Using Agile is not an excuse for a lack of product planning. As a product manager/owner, you still need to know where you’re going, what you’re trying to accomplish, and how you’ll measure success. That said, in an Agile environment, your planning horizon can be somewhat shorter and rolling. You should use the lightweight opportunity assessment instead of a heavy MRD (see the chapter Opportunity Assessments).
You and your designers should always try and be one or two sprints ahead of your team. This allows you to validate difficult features with sufficient time to improve them. Insist that the designers (interaction designers and visual designers) are front and center in the process, and make sure they don’t try to do their design work during the sprint—while the implementation is already underway (see the chapter Design vs. Implementation). Make sure, however, that someone from the engineering team is reviewing your ideas and prototypes every step of the way to provide feedback on feasibility, costs, and insights into better solutions.
Break the design work into as small and as independent chunks as possible, but not too small—make sure you don’t try to design a house one room at a time. But remember the emphasis on coming up with the minimal product possible. Note that, in an Agile environment, the designers may need to work faster than they’re comfortable with. You’ll find that certain designers, and certain design methodologies—such as rapid prototyping—are more compatible with the pace of an Agileenvironment than others.
As a product manager/owner, your main responsibility is to come up with valuable and usable prototypes and user stories that your team can build from. Replace heavy PRDs and functional specs with prototypes and user stories. Do prototypes for three reasons: (1) so you can test with real users, (2) to force yourself to think through the issues; and (3) so you have a good way to describe to engineering what you need built during the sprint. Be sure to test prototypes with real users. Try out your ideas and iterate on the prototype until you’ve got something worth building. You still need to make sure that you don’t waste sprint cycles.
Let engineering break up the sprints into whatever granularity they prefer. Sometimes the functionality in a prototype can be built in a single sprint, other times it may take several sprints. You will find that having good prototypes will help significantly in estimating the amount of work and time required to build. Remember that the engineering team has considerations in the areas of quality, scalability, and performance, so let them chunk the functionality into sprints as they see fit.
Make sure you as product manager/owner and your interaction designer are at every daily status meeting (aka standup or daily scrum). These morning meetings are the beginning of the communication process, not the end. There will be a constant stream of discussion about the product. Designers should be previewing functionality to the developers and QA. Developers should be showing off completed code to each other, QA, and the designers and product manager. QA and developers should be identifying potential pitfalls during prototyping, and helping the team to make better functionality, design and implementation trade-offs.
Don’t just launch every sprint—reassemble sprint results in a staging area until you have enough to make a release as defined by the product manager/owner. It’s the product manager’s job to ensure that there is sufficient functionality to warrant a release to the user. Remember that in a product environment, constant change can be upsetting to your customers (see the chapter Gentle Deployment).
At the end of each sprint, make sure you demo the current state of the product, as well as the prototype for the next sprint. Having everyone see what you finished validates the team’s hard work, gives the entire company insight into the product, and keeps the evangelism going.
Get Agile training for your entire team. Hire a consultant to help your product team move to Agile, but make sure the consultant has proven experience with product software teams and understands the difference between product software and IT or custom software. If everyone understands the mechanisms around Agile, then you can focus on the execution. If people don’t understand, you’ll get bogged down in the semantics and dogmatic issues.

Chapter 27:Succeeding with Waterfall Processes

Proactively Addressing The Issues

The conventional waterfall process is extremely simple in concept:

Phased development. Software progresses through a well defined series of phases, including: a written description of the requirements, user experience design, high-level architectural design, low-level detailed design, code, testing, and deployment.
Phase review. Each phase ends with a review of the deliverables from that phase, followed by sign-off and an explicit transition to the next phase.

Product Management Concerns

Validation Occurs Too Late in the Process
Changes Are Costly and Disruptive
Responding to the Market

Chapter 28:Startup Product Management

It’s All About Product Discovery

I describe this process in detail in the chapter Reinventing the Product Spec, but there are two keys:

The idea is to create a high-fidelity prototype that mimics the eventual user experience
You need to validate this product design with real target users.

Chapter 29:Innovating in Large Companies

Difficult But Worth The Effort

Innovation via the 20% Rule

Many of you have heard that at Google, engineers get to spend 20% of their time on the projects of their choice. If your company has the 20% rule, make sure it applies to product managers and interaction designers as well as to engineers.

Innovation via Skunk Works

Skunk works is a very old industry term that originally referred to secret military projects, but today refers to chasing ideas under the radar, unhampered by bureaucracy, on your own time if necessary. Skunk works projects have saved countless large companies.

Innovation via Observation

One of the easiest ways I know of to innovate is to just watch (and listen) as actual users attempt to use your current product or a competitor’s product. Watch a few of these sessions and you’ll start to see patterns of frustration and expectation. Watch some more and you’ll start to get ideas of how to better meet the needs. Bring in an engineer who is familiar with the available technologies, and together you will start to come up with better ways of solving the problem.

Innovation via User Experience Design

Another good source of innovation is to step back, relax your technical constraints for a moment, and consider what the ideal user experience would be for your product.

When you spot these incongruences, you have identified an opportunity for innovation (or at the very least, an opportunity for significant product improvements).

Innovation via Acquisition

But in truth, acquisition can be an excellent technique for innovation—especially in areas where the risks are high.

I encourage product managers at large companies to reach out and establish relationships with interesting, related startups. You can often help—and learn from—one another, and the nurturing you do might just save your company millions.

Chapter 30:Succeeding in Large Companies

Top 10 List

First, it’s critical to realize that an underlying dynamic in large organizations is that they are generally risk averse.

Second, many of these same organizations have at least some degree of matrix management and shared resources, where key members of the product team (most often design, engineering, QA, site operations, and marketing), are shared resources, and your project needs to secure the necessary people from the pool in order to staff up and create your product. It’s not that this organizational design is particularly effective, it’s just that this model has significant cost savings over project-oriented approaches (where much like a startup, you assemble a dedicated product team for the life of the project).

With these points in mind, here is a list of ten techniques for getting things done in a large company:

Learn how decisions are really made in your organization.
Build relationships before you need them.
Long live skunk works.
Just get it done.
Pick your battles.
Build consensus before important meetings where decisions are required.
Be smart about how you spend your time.
Share information.
Put your manager to work.
Evangelize!

PART3 Product

Chapter 31:Lessons From Apple

A Different Type Of Hardware Company

There is a great deal to learn from Apple, but to me there are three higher-order lessons:

The Hardware Serves the Software
The Software Serves the User Experience
The User Experience Serves the Emotion

Chapter 32:Beware of Specials

Don’t Fall Down This Slippery Slope

I’ve talked in several chapters about the reasons why you can’t count on customers to describe the product that they need, but to summarize: first, it’s extremely difficult for the customer to know what he needs until he sees it; second, customers don’t know what’s possible; and third, customers don’t often interact with each other in order to identify common themes.

But, more generally, even if the customer doesn’t have these issues, it’s not clear that these are the best things to focus on right now. By pursuing these special features now, what important work are you delaying? What is the business cost of that delay?

Assuming these are not issues, specials are still dangerous. How come? Because your job is to meet the needs of a broad range of customers—that’s what distinguishes product companies from customer software shops.

This leadership comes from the CEO, but there is much you can do as product manager to help.

First, it is natural for any customer to want to describe their problem in terms of the solution they can envision rather than the underlying problem itself. But as product manager it’s your job to work with the customer to tease out the core issues and needs. You can help them recognize that there may be other approaches to this problem that provide a solution they would like even better.
Second, consider looking at how you could keep your product general purpose but allow the product to be tailored/customized/ extended by the customer or by a solutions provider.

Chapter 33:The New Old Thing

What Is Possible Is Constantly Changing

While it’s always fun to speculate on what the next new big thing is, much more often than not, the next big thing is not something altogether new, but rather a new incarnation of something old. The difference is that the new product does it so much better, faster, and/ or cheaper that they end up redefining their category.

There are two key methods that smart companies use to create winning products in mature markets.

First, they understand their target market and where the current products fall short. Product usability testing is my favorite technique for doing this, and you can do this with your competitor’s products in addition to your own.

Second, great product leaders know that what is now possible is always changing. New technologies enable new solutions that may not have been possible or feasible until now. It is not easy to constantly stay on top of relevant technologies and consider how they might be applied to help solve the problems you face, but it can make all the difference for your product.

Chapter 34:Fear, Greed and Lust

The Role Of Emotion In Products

In the enterprise space, the dominant emotion is generally fear or greed. If I don’t buy this product, my competitors will beat me to market, hackers will penetrate my firewalls, or my customers will desert me. Or, if I do buy this product, I will make more money, save more money, or stop spending so much money.

In the consumer space, the dominant emotions get more personal. If I buy this product or use this Web site, I will make friends (loneliness), find a date (love or lust), win money (greed), or show off my pictures or my taste in music (pride).

Chapter 35:The Emotional Adoption Curve

An Interview With Jeff Bonforte

In this interview, Jeff shares his views on the role of emotions in product development.

Marty: Why do you like to focus on anger?

Jeff: Because angry people dictate the future of technology.

I like my product managers to focus on the most miserable thing people have to deal with everyday. If you can solve that problem, that actually changes behavior, and that can lead to the truly big product wins.

Don’t focus on the technology of your product, just think about the people that you’re trying to help. What are the problems they’re dealing with? What are the things that they’re frustrated with?

For example, every single one of us hates to travel nowadays—its just miserable. It’s almost as if it’s engineered for misery from start to finish. Or, we hate our telephone company—it’s almost impossible not to. They send us a bill that’s so complicated and so structured to screw you over. The rules are so elaborate that almost nobody understands them. The result is you feel like the entire billing process was engineered from the start to screw you over, and you’re in a monthly battle to figure out how not to get screwed.

In my view, far too many product managers talk in terms of features and technology, and we don’t really talk in terms of the user’s core needs or emotions.

Marty: Let’s go back to the technology adoption curve. What do you see as the underlying emotions and needs driving each of the groups of users?

Jeff: In the Technology Adoption model, we’re told that there’s a technology adoption curve, and it’s nice and clean. But there’s also a chasm, and maybe there’s a tornado in there too. But, what does that mean exactly? What are we supposed to do to design around these things?

Instead of thinking about these groups using the labels that we were given by Geoffrey Moore—which, by the way, I found to be counterintuitive—I instead assign one of the emotional states for their adoption of technology. So, I talk about the Lover, the Irrational, the Efficient, the Laugher, and the Comfortable.

Marty: What does each of these groups represent?

Jeff: The Lovers (Innovators) are the techies who buy the product because they find the technology cool. These people are very dangerous to product managers because they are driven by very different needs than the larger population. They look at solving tough technical problems as fun.

On the other hand, the Irrationals (Early Adopters) feel the same emotions as the general population, but with more intensity. These are often negative emotions such as anger, fear, or loneliness, but in any case, the strength of these feelings can lead to buying behavior that is not economically rational, for example, they’ll spend more time learning something than the value they get just so they can get the satisfaction of addressing these emotional needs.

The good news is that as the product improves, ordinary people who feel the more subdued versions of the same emotions will also be motivated to buy.

The Efficients (Early Majority) will adopt when the technology becomes practical. Again, they feel the same emotion, but they’re more pragmatic about the benefits versus the costs.

The Laughers (Late Majority, and Yahoo’s core constituency) feel the same emotion, but it’s more muted and they don’t want to deal with any grief in order to get the benefits.

The Comfortable (Laggards) are the 15% that want the benefits but it just has to be drop dead simple and convenient for them to make the move.

In this view of adoption, there is tremendous power in the Irrationals.

Lovers and Irrationals are often coming in the door at the same time, despite the traditional adoption curve that seems to imply there’s first one and then the other. While Lovers and Irrationals may enter in at the same time, Lovers are the worst possible people in the world from a product manager’s perspective.

Marty: Why is that?

Jeff: Because they mislead you one hundred percent of the way. Lovers buy a Prius because they like the battery technology.

On the other hand, Irrationals buy a Prius because they love the environment so much that they’ll spend $22,000 over the benefit of the environment. They could just buy carbon credits and carbon neutralize themselves, or they could get a motorcycle, but they overspend on the solution because they’re passionate about the problem they’re trying to solve.

The bottom line is that Irrationals are really interesting, and Lovers are really not.

People that obsess over your product because they like battery technology don’t buy your product for the same reasons anyone else does, but the Irrationals do.

Irrationals are essentially overreacting to the anger, but the emotional reaction they have is more of a multiplier times their logic. They exaggerate the value. But if you can tap into what they’re thinking and what they feel, this can be very powerful.

The Irrationals can teach you the value of your product all the way down the line.

The latent frustration is highest amongst the Irrational and then it dissipates, but it’s still always there. The Lovers are largely unconcerned with the core solution—they’re more concerned with the technology involved.

One of the reasons startups in particular fall into the chasm is that they misread the situation—they confuse the Irrationals with the Lovers.

Marty: So how do you address this at Yahoo!?

Jeff: One of the challenges Yahoo! and many large companies face is that we envy a lot of startups, and we think, “We want to do cool stuff like that.” But Yahoo has made its fame and fortune off serving the Laughers, so we will serve our user base much better by understanding Irrationals, and not by kowtowing to the Lovers.

Sometimes marketing folks confuse the emotional groups with demographics. They’ll look at the Irrationals and say, “Oh, this group is comprised of males 18-30,” but it’s not true. If you’re in finance, you may have an Irrational group that’s very different looking—it could be retired women. You have to look at each product individually, and look at the core emotions for this particular product.

Marty: So what do teach your product managers to look for?

Jeff: Look for anger, exasperation, and frustration. If you just take a look at all those we love to hate—the telcos, banks, consumer credit firms, the tax man, government bureaucracy, airlines, health-care—these are all great opportunities for innovation because the consumer latent frustration is so high.

Look at the music industry. We have to pay $15.98 for a CD with one good song on it. Is it any surprise that so many people feel good about stealing from these people?

We’re all so impressed with Skype’s growth, and yet, had we looked and seen the latent anger and frustration in the space, it would have been relatively predictable to say, it’s not about standards or technology, or being open versus proprietary. The Skype guys rejected all that thinking and said we’re just gonna make it work, and they then tapped into that latent frustration. It was like heroin, you couldn’t stop it.

Contrast this with the webcam business. The problem here is there’s no angry person in the webcam business—we don’t hate our webcam providers, or our video conferencing guys—and webcam satisfies a need that’s high up in Maslow’s pyramid. It’s “I wanna see my kid,” and while there’s love involved there, not all of us have kids, and you can easily call your kids, so we’re not all dying for a webcam.

So, when you add video to Skype, not much happens. Their user base doesn’t grow that much, the usage of webcam and messenger doesn’t go down—nothing changed. And so the chasm for webcam is actually huge because taking it to the mainstream for webcam means you don’t have much frustration to leverage—you don’t have that driving emotional need.

You really need the Irrationals to slingshot your business into the Efficients and the Laughers. Without that emotion from those irrational people you don’t get the passion that carries the product over the chasm. So as with so many things in life we’re brought back to Maslow’s pyramid. If you look at the needs, the further down you go, the more you’re tapping into core emotions, and the better off you are because these are the deepest emotions for humans.

Politicians like to tap into the fear emotion and explain that bad people are gonna destroy your cities, or come and bomb you, or you’re not going to have food tomorrow. Well it’s not that hard to motivate you to change your behavior when you energize these core emotions. It’s much harder to get people to do something by appealing to their aspirations.

Google is the big winner in this way of thinking because the nature of a search engine is to help address countless critical human needs. If you’ve been diagnosed with a disease you go to Google to learn how to treat it. If you have to buy something, Google finds it for you. They’re the good guys that are there to help you with whatever problem you have.

So the question we ask is, “What are the emotions that are driving the behavior?” And then we look for ways to tap into those emotion with features and all the other things. We assess for each of our projects which core emotions they appeal to, and how acute is the user’s pain.

Marty: Do you have a favorite approach for assessing these core emotions?

Jeff: One technique I use is what I call the “freshman test.” Think back to the first day you walked into high school. You feel more pure emotions of human frailty in that one day than in any other day in your life. You’re small, your hormones are all out of whack, anything you had acheived in your previous school completely gets washed away and you’re a nobody—and you know you’re a nobody.

If you can tap into any one of those emotions that every human everyday feels—loneliness, insecurity, fear, frustration, anger—some bit of that freshman thing, then you’re on the right track.

Chapter 36:Usability vs. Aesthetics

Both Are Important

I think what these two cases illustrate is that the disciplines of interaction design and visual design are very different. To have a site that is both usable and appealing you need both skills on your design team. Some teams are very lucky and they have a designer talented at both types of design. But in many cases, I think they just expect that since they hired a “designer,” that person should be able to do both—and they can’t.

But, fundamentally, I believe you need both interaction and visual design skill sets to deliver a good user experience, and that these people need to work closely with the product manager to define the product, which includes both the functionality and the user experience.

Chapter 37:Keys to Consumer Internet Service Products

Top 10 List

Usability. In my opinion, most companies give far too little attention to this in every type of product (especially enterprise software!) but, with a consumer Internet service, there simply is no getting around that it’s really all about the user experience. If you can’t find a way to make your service something that the target user can figure out how to use—and provide them with an idea of why they should use it—then you’re going nowhere fast. Also remember that performance is a key factor in usability. If a page takes too long to load, people will think it’s broken or just go elsewhere because the experience is bad.
Personas. When you have millions of users, there is no single “user,” rather you have at least several important types of users. It’s critical that you segment your users into the most important personas and consider each one separately. When you create a feature, you need to examine how each persona will value and respond to that feature. See the chapterPersonas for Product Management.
Scalability. Weird things happen to products once millions of users start using them. Databases break, performance bottlenecks pop up all over, user interfaces become unusable. You can do some amount of load testing during QA, but I’ve found this only finds the easy problems. I guarantee you that you’ll have surprises—and not pleasant ones. Managing scalability needs takes a collaboration of product management, design, engineering, and operations. It also takes a proactive management team that allocates a significant amount of engineering and operations resources on an ongoing basis (I generally advise 20%) to scaling the product and infrastructure. If you get to the point where everything breaks and the engineering team is telling you that the “house of cards has collapsed,” you’re in big trouble. The only way I know to avoid that is to pay your taxes by working on scale continuously from day one, and don’t let yourself get to the brink.
Availability. Very quickly you’ll find that there really is no time of the day or week or month or year that your service doesn’t need to be running. I don’t know of anyone that has achieved 100% availability, but I know outages are painful to everyone. The life of a consumer Internet service provider is not for everyone. Things happen at all hours, weekday and weekends, and everyone I know in the business has their stories. You need to design-in high-availability to all of your thinking just as you need to do with scalability.
Customer support. One of the biggest (and least fun) surprises that most consumer service companies run into is customer support. Traditional models of customer support can quickly bankrupt even the best services companies. This is oversimplifying a complicated topic, but you have no alternative other than designing and building the product to absolutely minimize customer support costs—especially if you charge a fee for your service. Yet, always remember that it is not about controlling customer support costs—it is about ensuring a great customer experience.
Privacy and data protection. Consumer Internet service companies can very quickly end up with far more personal information than they ever imagined. You may be collecting this data for purely innocent purposes—such as to provide a personalized user experience. But today customer data such as e-mail addresses and credit card numbers are a very sensitive asset, and you don’t want the bad press, the possible penalties, and especially the customer anger that results if that data gets into the wrong hands. You need to put the protections in place early to absolutely ensure that you are protecting the information that your customers entrusted you with. You also need to protect the actual user data from your own employees.
Viral marketing. If your product is good, your users will want to share that experience with their friends, family, and co-workers. That’s absolutely what you want, but it’s surprising how few companies actually do anything to facilitate this most powerful form of marketing. Consider what you can do with your product to enable users to invite their friends to try it. Also, work the numbers—most companies are willing to pay a certain amount per new user (customer acquisition cost, usually for marketing and advertising). Maybe you can funnel some of that money to your users instead? But find ways to make sharing the love easy—even without using financial incentives.
Globalization. If you have a good service, you’ll find that it will quickly spread beyond your country’s borders—first to other countries that speak the same language, then to the rest of the major Internet-connected countries. It is far less expensive—and overall, faster to market—to design a product that can easily be localized than it is to try and take a product for one country/currency/language/culture and rewrite it for another. You don’t have to localize initially for all the countries but—as your business spreads—you can much more rapidly and economically meet your new users’ needs.
Gentle deployment. When millions of people are using your service, any change is a big deal, and every change needs to be considered carefully. We talked earlier about gentle deployment strategies (see the chapter Gentle Deployment), but suffice it to say here that changes need to be deployed intelligently. This doesn’t just mean great QA—it also means deploying gradually, and giving your users time to switch when they have the time to learn about the changes, not when you happen to roll it out. In many cases, this involves deploying the new version alongside the old so that people can switch over a period of time. Also, do everything you can to eliminate gratuitous changes. It’s hard enough for your community to absorb features that they know they want and need.
Community management. Every company is dependent on its customers, but for consumer Internet service companies, this community of users takes on even more powerful importance—they can make you or break you. It has never been easier for them to communicate how much they love your product—or how badly you just treated them. If your users value your product, they will want to be loyal, and they will want to be a part of the great community you are creating. But they also want to be appreciated and recognized—and not just with lip service. There are many ways to reach out to your community—to learn from them and understand where they want to see your product go. There are also many ways to show your gratitude to the community and to recognize those that make especially valuable contributions. Do this, and make community awareness a top priority for everyone in your company—from the CEO on down.

Chapter 38:Keys to Enterprise Products

Top 10 List

Usability. Pity the poor souls who must sit at their desks all day and use the typical enterprise applications for purchasing, billing, customer service, and hundreds of other applications. If the people who actually had to use the systems were the same ones that made the actual buying decisions, I think we’d have a very different set of vendors. I’m very sorry to say it, but most of the applications are just awful. One of my favorite books is The Inmates are Running the Asylum by Alan Cooper. Nowhere is his argument truer than with enterprise software. I find too few enterprise companies doing any interaction design, visual design, or usability testing—and it certainly shows. Even when the application produces business results, there is still a sour taste in the mouth, and you rarely find true enthusiasm for these types of products. It really is time to raise the bar.
Product actually needs to work. Even more egregious than poor product usability, too many enterprise products simply don’t work—at least not without tremendous investments in time and money to “customize” and “integrate” or develop countless workarounds. This is certainly not the case with all products, but the many out there that ship with often hundreds of serious defects give a bad reputation to all of us. As product manager, it’s essential to make sure your product does what you says it will.
Specials. One of the biggest mistakes companies make is that they think they can get their product requirements from their customers. I’ve talked about this earlier (see Beware of Specials), but the most dangerous example of this is when the sales organization brings in a potential customer that has a big check all ready to sign if you’ll just agree to put these seven features in your product. Soon you’re becoming a custom software shop, and you don’t have anything resembling a generally useful product. If that’s not bad enough, there’s a good chance the initial customer won’t be happy with those seven features anyway (once they got it and tried it they realized they needed something different). Avoiding specials takes a lot of discipline—especially for a small company struggling to bring in some cash—but it is critical you create products that meet the needs of a wide range of customers.
Customers and Charter User Programs. The above is not to say that you shouldn’t listen to your customers—you should absolutely meet with and listen to many customers. Just don’t expect them to be able to dictate your product requirements. To determine the real product requirements, you’ll need to meet with many customers. One valuable technique is to identify a half-dozen or so great potential customers (smart, enthusiastic, motivated, friendly) and invite them to participate on a charter customer program (see the chapter Charter User Programs). In exchange for the opportunity to work closely with the development team, they know that their needs will be understood and seriously considered, and they agree to be accessible to try out ideas, answer questions, and install software immediately—and, if it meets their needs, to be vocal reference customers. Your goal should always be to have at least half a dozen live, happy referenceable customers when you release your product.
Designing for the sales channel. It’s critical to design your product around the needs of your sales and distribution channel. Different channels require different capabilities. The key is to provide value all along the distribution chain. If you’re selling through systems integrators, you’ll need to ensure that your product doesn’t try to cut them out of the equation. If you’re selling through VARs that supply a wide range of products, you’ll need to ensure that your product doesn’t overwhelm them with time-consuming technical requirements. Many otherwise good products struggle because they’re not appropriate for their sales channel.
The customer versus the user. Many enterprise products are designed around the needs of the person who will actually buy the product—the customer. That’s who the team talks to when learning about needs, and that’s who has to give the okay in order to sell the product. However, as we alluded to above, there are often several different users of the product who also bring needs and requirements. For example, the different types of end-users, the systems administrators, management, and often other business applications.
Product installation. With consumer products, vendors know that they have to make the product absolutely bulletproof to install, and something that just takes minutes or even seconds. But with enterprise products, many vendors assume they’ll be able to get dedicated systems administration staff that can craft custom installations that can take days or even weeks of work, and that these administrators will be able to watch over the applications daily. Even when this is true, when the person moves on—or is out due to vacation or illness, or just gets overloaded—things can quickly fall apart. Again, it’s time to raise the bar.
Product configuration, customization, and integration. An enormous professional services industry has emerged to fill the gap and try and get these enterprise software products to actually work, and further, to work with each other. I believe that the vast majority of the cost is simply due to poor product design and execution. However, even if you accept that the need for services is appropriate, there is still much that can be done by vendors to make their products easier to configure, customize and integrate. If you don’t believe this is possible, look at how Salesforce.com has redefined the game in their market.
Product update. Installing a new version of enterprise software is never fun. The vendor thinks it’s the biggest event of the year, but the customer has a business to run, and installing updates of vendor software isn’t something they typically want to be spending their precious time and resources on. Having problems upgrading or requiring complex data migration is extremely frustrating to the customer. Again, most consumer products realize this and make a much bigger investment in technology to upgrade, and in testing the upgrade process.
The Sales Process. For many years, in the enterprise software market, far too much of the sale was driven by the talents/personality/charm of the respective sales staff. A product selection was too often driven by the relationship between the sales rep and the customer rather than by whether the product was the best fit or not. While the relationship aspects are still very important (more than they should be), today the Internet has changed the product research and evaluation process, and vendors need to support this new sales process. Make your product easy to try and buy.

Chapter 39:Keys to Platform Products

High Leverage But Not Easy

But assuming you are, then you know how difficult platform product management can be. To begin with, there are three very different constituencies:

The application providers—the businesses that choose to use your platform to build their solution.
The developers—those who work for the application providers and who write their software using your platform services.
The end-users—the ones who run the application provider’s products, and ultimately use your services.

The application provider is going to be concerned with business viability—their viability if they use your services, and your viability in case you go out of business or discontinue support for the platform. The application provider cares about your pricing, licensing, quality, support, and global availability, among other factors.

The developers are looking for services that make it easy for them to quickly create maintainable, reliable code in the languages they want to use, working with their favorite tools and infrastructure, on the devices they need to deliver on.

The end-users care mainly about the end result. If the features and services they want aren’t there or don’t work in the way they need, they don’t buy the application, and the application provider fails. You lose a customer, and eventually you fail too.

Many extremely successful platforms have been downright awful for the developers. But they succeeded because of compelling value to the end-users and—therefore—to the application providers.

There are other important dimensions to platform product management that make this area challenging. For example, there are many different delivery models (e.g., embedded, private-label, co-branded, hosted) and many forms of customization that may be required (e.g., end-user, customer’s IT, solution provider/SI, vendor, source code). Each of these is a topic in itself.

Summary

Chapter 40:Best Practices Summary

Top 10 List

The role of product management. Too many product leaders spend their time on other activities, especially product marketing and/or project management. These activities are not a substitute for true product management.
The role of user experience. For most software products, the user experience is all-important. Devising a good user experience requires that you collaborate closely with an interaction designer and an engineer to come up with something that is valuable, usable, and feasible.
Opportunity assessments. These lightweight, to-the-point assessments replace the old “MRD” (market requirements documents). Before you jump into the solution, this makes sure you know what problem you’re trying to solve, who you’re trying to solve it for, and how you’ll know if you are successful.
Charter user program. It is shocking to me how many product teams think they can come up with great products without talking to users and customers. If you only do this one thing, it will ensure that you do several other things right, starting with direct and intense user interaction.
Product principles. Product management is all about making choices, and many of the techniques here are about helping you make good choices. The product principles help you identify and prioritize what you believe is important.
Personas. Another key technique for making the difficult choices required for an inspiring product is to use personas as a way to focus your release and to understand the key behaviors and underlying emotions of the target users.
Focus on discovery. The primary responsibility of the product manager is to discover a product that is valuable, usable, and feasible. It makes no sense to proceed to building something until you have evidence that you have discovered this product.
The use of prototypes. One of the most important product discovery techniques is to create a high-fidelity prototype. We do this for several reasons: First, it forces you to think much deeper about the solution; second, it enables you test your ideas out with real users; and third, it is the most useful way to describe the product to be built to the rest of the product team.
Test prototype with target users. Once you have a prototype, you can find out which of your ideas works and which do not. The techniques for this prototype testing are something that all product managers and designers need to master. Knowing how to get feedback on product ideas is probably the single most important skill for product managers.
Measure to improve. The successful product manager uses data to make important decisions, especially when trying to improve an existing product. Improving a product is not about adding features that customers request; it is about analyzing the product’s actual use, and then relentlessly driving the product to improve the key metrics.

Chapter 41:Product Manager Worry List

Top 10 List

Is my product compelling to our target customer?
Have we made this product as easy to use as humanly possible?
Will this product succeed against the competition? Not today’s competition, but the competition that will be in the market when we ship?
Do I know customers who will really buy this product? Not the product I wish we were going to build, but what we’re really going to build?
Is my product truly differentiated? Can I explain the differentiation to a company executive in two minutes? To a smart customer in one minute? To an industry analyst in 30 seconds?
Will the product actually work?
Is the product a whole product? How will customers actually think about and buy the product? Is it consistent with how we plan to sell it?
Are the product’s strengths consistent with what’s important to our customers? Are we positioning these strengths as aggressively as possible?
Is the product worth money? How much money? Why? Can customers get it cheaper elsewhere?
Do I understand what the rest of the product team thinks is good about the product? Is it consistent with my own view?