Full Title: Inspired How to Create Products Customers
Highlights
It doesn’t matter how good your engineering team is if they are not given something worthwhile to build. (Page 8)
learned that the decisions about what to build came from a “Product Manager”— someone who generally resided in the marketing organization and who was responsible for defining the products we built. But I also learned that Product Management wasn’t something HP was particularly good at. I later learned that most companies weren’t good at this, and in fact most still aren’t. (Page 8)
I promised myself that never again would I work so hard on a product unless I knew the product would be something that users and customers wanted. (Page 8)
discovered that there was a tremendous difference between how the best companies produced products, and how most companies produced them. I realized that the state of the art was very different from the state of the practice. (Page 9)
chose this career because I wanted to work on products that customers love; products that inspire and provide real value. I find that most product leaders also want to create inspiring and successful products. Yet most products are not inspiring, and life is too short for bad products. (Page 9)
The job of the product manager is to discover a product that is valuable, usable, and feasible. (Page 11)
Product discovery is a collaboration between the product manager, interaction designer, and software architect. (Page 11)
Engineering is important and difficult, but user experience design is even more important, and usually more difficult. (Page 12)
Engineers are typically very poor at user experience design— engineers think in terms of implementation models, but users think in terms of conceptual models. (Page 12)
User experience design means both interaction design and visual design (and for hardware- based devices, industrial design). (Page 12)
Functionality (product requirements) and user experience design are inherently intertwined. (Page 12)
Product ideas must be tested— early and often— on actual target users in order to come up with a product that is valuable and usable. (Page 12)
We need a high- fidelity prototype so we can quickly, easily, and frequently test our ideas on real users using a realistic user experience. (Page 12)
The job of the product manager is to identify the minimal possible product that meets the objectives— valuable, usable and feasible— minimizing time to market and user complexity. (Page 12)
Once this minimal successful product has been discovered and validated, it is not something that can be piecemealed and expect the same results. (Page 12)
Everything starts with the people, but the process is what enables these people to consistently produce inspiring and successful products. (Page 13)
The product manager has two key responsibilities: assessing product opportunities, and defining the product to be built. (Page 18)
Typically, new ideas can come from anywhere— company executives, discussions with customers, usability testing, your own product team, your sales or marketing staff, industry analysts, to name a few. But then someone needs to take a hard look at the idea and decide if it is something worth pursuing. The product manager is responsible for this assessment (many companies call this an MRD— Market Requirements Document— but I’ll describe a lighter- weight version of this called an Opportunity Assessment). (Page 18)
Once you’ve decided that you have a good opportunity and your company is well- suited to pursue it, then someone needs to discover what the solution— the product— actually is, including the necessary features and functionality, the user experience, and the release criteria. Again, this someone is the product manager, and this task is the heart of his or her job. Some companies call this spec a Product Requirements Document (PRD), and others call it a Product Spec or Functional Spec. Again, I’ll advocate a lighter- weight approach that’s based on prototypes and not paper, but the key is that it describes the functionality and behavior of the product to be built, and not how it will be implemented. (Page 18)
The key role here is the interaction designer (also known as information architect, user interface designer, and user experience architect). 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. The interaction designer works closely with the product manager to discover the blend of requirements and design that meet the needs of the user. The idea is to get to the point where the software is both usable (users can figure out how to use it) and valuable (users actually want to use it). (Page 19)
Once the product has been defined, the product development team will take on the project and begin building the product. The project scheduling and tracking function is the core of project management. There are several different models regarding who exactly handles the scheduling and tracking. Sometimes it is managed by dedicated project managers, sometimes by the engineering manager (since most of the resources are usually from his or her team), and in some cases the product manager is asked to project manage as well. It often depends more on the culture of the company and the size of the project. Larger projects especially benefit from a dedicated and skilled project manager. (Page 19)
product development or software developers these are the people responsible for actually building the product. In some companies this is called “IT” (information technology), but it’s important to draw a distinction between the software created for customers and the software created for internal use such as an HR application. IT is typically the group that supports internal employees, and the engineering organization builds and maintains products for external customers. (Page 20)
For Internet services, the product is typically run on central servers and accessed over the Web. The site operations team is responsible for keeping this service running. While some companies ask the engineering team to cover this, most find that it demands a specialized set of skills and is far too important to be a secondary responsibility. (Page 21)
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. Often companies ask the same person to cover both the product management (product definition) and the product marketing responsibilities. This can be difficult since the skills required are very different, but nevertheless it occurs at many companies. (Page 22)
How many product managers do we need? A: Generally, one product manager for every 5- 10 engineers. (Page 23)
Q: How many user experience designers do we need? A: One interaction designer can generally support two product managers, and one visual designer can typically support four interaction designers. (Page 23)
Q: Should we have dedicated project managers? A: For significant- sized projects, such as those with more than 5 engineers, yes. Further, if you use the “train model” of releases (where you make a release every one to four weeks consistently, and if a given feature is not ready it simply moves to the next available train), you’ll definitely need dedicated project managers assigned to each release (which generally contains software from multiple projects). (Page 23)
Industry pundits claim that as much as nine out of ten product releases are failures in that they fail to meet their objectives. Even if your organization performs better than this, I strongly believe that most releases are ill- conceived. Countless release cycles are wasted on products that are either not valuable or not usable. (Page 24)
There are many reasons for bad products, and each topic in this book is intended to speak to some aspect of where these bad products come from, but I have long argued that the root cause of wasted releases can most often be traced to poor definition of the role of the product manager in a company, and inadequate training of the people chosen for this role. (Page 24)
the job of the product manager is to define— in detail— the product that the engineering team will build. In contrast, the role of product marketing is to tell the world about this product. These are extremely different jobs. (Page 24)
I argue that every product needs a single, accountable product manager, who is responsible for the product definition (the combination of product requirements and user experience design that describe the product to be built). (Page 25)
Marketing- Driven Product: There is a product marketing or product manager- titled person responsible for market requirements, and then the product goes straight to engineering— bypassing detailed product requirements and the many tough decisions that are encountered through the discovery process (Page 25)
Two People, One Role: The product definition role is split between a product marketing person responsible for “high- level” business requirements and a product manager person responsible for the “low- level” product requirements. (Page 25)
One Person, Two Roles: A product marketing person is asked to cover both roles (and the company sometimes calls these people product managers and sometimes product marketing). (Page 25)
Marketing- Driven Product This situation is pretty easy to spot. 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. There are plenty of Dilbert cartoons portraying this person, and we’ve all known this type of product manager. 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. In this situation, hopefully someone else on the product team— sometimes a lead engineer, sometimes an interaction designer, and sometimes a manager— steps in and performs the true product management function. If this person has the skills in addition to the bandwidth, the product may yet succeed. More often, however, the product is already in trouble right from the start. (Page 25)
Two People, One Role This situation is also easy to spot, as there is no single person responsible for the product. A product marketing person (sometimes in this model called the “business owner” or the “business product manager”) is responsible for the high- level product requirements, and a product manager (sometimes called a “technical product manager” or “product owner” in Agile teams) 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. In companies with this model, product managers become little more than a spec- generation service. It is a frustrating job that tends to stifle innovation and rarely produces successful products. Many larger companies with multiple business units evolve into these roles and then wonder why they can no longer come up with inspiring products that their customers love. (Page 26)
One Person, Two Roles The problem with combining the product manager and product marketing roles into one position is that it is very hard to find someone who can do both types of jobs well. 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. (Page 27)
Further, for all but the simplest of products, the role of the product manager as defined here is an all- consuming, full- time job, requiring a dedicated person. If you ask the product marketing person to cover the product management role, even if the person has the skills and talents required for both, it is unlikely he or she will have the bandwidth to do both jobs well. (Page 27)
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. (Page 28)
the product manager and product marketing person will communicate often and collaborate occasionally on specific topics, but there are two main interactions. First, the product marketing person will be one of several key sources of input to product requirements owned by the product manager. Second, the product manager will be one of the several key sources of input to marketing messages owned by product marketing. (Page 29)
It doesn’t matter how great your engineering organization is if the product manager doesn’t give the engineers something valuable, usable and feasible to build. (Page 29)
The reason so many Internet companies still define product management as including project management is because many of our practices came from the shipped software world. In the shipped software world (such as the Office software products from Microsoft became famous for), it is common to have product managers cover the project management role. However, while it might work for shipped software, this approach just doesn’t migrate well to the Internet. (Page 30)
We initially tried to continue having the product manager cover the project manager role. Early internet companies like Netscape and Yahoo! tried this approach but they ran into a problem: in the shipped software world, the product was generally packaged as a self- contained unit, with one release package serially following another often months or even years later. So the product generally was in the same granularity and frequency as the project, making it relatively easy for the product manager to double as the project manager. But in the Web services world, this model breaks down. (Page 30)
Most Internet service companies found that they needed to make more frequent, smaller releases to a larger common code base. And since a typical project required more work than a release interval (usually ranging from weekly to monthly), this quickly turns into parallel development and the software train model of releases. Most Internet companies beyond the startup phase use this train model. (Page 31)
The most important point for this book is that a train requires active and strong project management which is not tied to specific projects, but rather to the release as a whole. A train typically contains features from many projects and product managers, and it has significant coordination requirements such as release management, engineering, site operations, customer service, and product management. Some Internet companies refer to the project manager of a release train as the train’s conductor . (Page 31)
eBay has a very unusual product development process, but three key characteristics of this process stand out: it is extremely productive, extremely demanding, and it is a process predicated on an extremely strong project management competency. (Page 33)
The person that established this project management competency for eBay was Lynn Reedy, the very best project management mind I’ve ever had the privilege of working with. Before I joined eBay I thought I was pretty good at project management, but she showed me where the bar really was. (Page 33)
believe that developing strong project management skills is a big advantage for product managers. At the very least, your product will get to market faster, and— ultimately— it could make the difference between getting your product shipped at all. However, I also argue that the product manager and the project manager should be separate roles. (Page 33)
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. (Page 34)
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. (Page 34)
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. (Page 34)
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. (Page 34)
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. (Page 35)
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. (Page 35)
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. (Page 35)
The message about the value they deliver is most needed by the teams without designers. One way to do this is to work on educating the wider product team about the need and benefits of designers to a product, especially the product managers. (Page 37)
A good product requires a good user experience. And a good user experience requires the close collaboration of product management and user experience design. (Page 37)
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. (Page 37)
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). (Page 37)
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. (Page 38)
The idea is to get to the point where the software is both usable (users can figure out how to use it) and valuable (users actually want to use it). 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. (Page 38)
Many companies realize they need to do something in this area, but they think they can outsource this user experience work to a design firm. To some degree you can, but beware that certain functions are more appropriate than others. (Page 39)
I don’t recommend outsourcing the interaction designer role because of these three reasons: It takes time, over the course of several projects, to truly develop the necessary understanding of users and customers. Most design contracts don’t have the time to do that, and even if they do, that knowledge is lost when the next release comes up; The interaction designer needs to be on hand and deeply involved all the way through the project, from the beginning to launch. Hundreds of detailed questions will come up during development and test— having an interaction designer there to make the right decisions immediately is critical; The user experience of the product is simply too core to the company to not have in- house. Given the option, it’s a better choice to outsource QA. (Page 39)
The product manager is responsible for defining the solution, but the engineering team knows best what’s possible, and they must ultimately deliver that solution. As a product manager, you’ll quickly learn that if you have a good relationship with engineering, then the job can be a great one. If you don’t, let’s just say that you’re in for some very long and frustrating days. (Page 41)
One key to this relationship is for each of you to understand that you are peers— neither position is subordinate to the other. As product manager, you are responsible for defining the right product, and your engineering counterpart is responsible for building the product right. You need both. You need to let your engineering counterpart do what he believes necessary to build a quality product, and he needs to give you the room to come up with a valuable and usable product. (Page 41)
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. (Page 41)
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. (Page 42)
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. (Page 42)
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. (Page 43)
In the chapter Reinventing the Product Spec, I write about the importance of a high- fidelity prototype as the basis of the product spec. (Page 44)
here’s what you need to do to make sure you never do— you need to allocate a percentage of your engineering capacity to what at eBay we called “headroom.” Since many of the issues you run into with rapid growth have to do with scale, the idea behind headroom is to avoid slamming into ceilings. (Page 50)
The deal with engineering goes like this: Product management takes 20% of the team’s capacity right off the top and gives this to engineering to spend as they see fit. They might use it to rewrite, re- architect, or re- factor problematic parts of the code base, or to swap out database management systems, improve system performance— whatever they believe is necessary to avoid ever having to come to the team and say, “we need to stop and rewrite.” (Page 51)
Do a realistic schedule and timeline for making the necessary changes that engineering identifies. Most of the time in a normal development project, an experienced engineering team will come up with fairly accurate estimates. (Page 51)
If there’s any way humanly possible to break up the rewrite into chunks to be done incrementally with user- visible product development continuing on the site, you should absolutely do so. Even though the rewrite might now stretch over two years instead of nine months, if you can find a way to continue to make forward progress on user- visible functionality— even if it’s only with 25% to 50% of the capacity— this is incredibly important for the product to stay relevant in the marketplace, particularly in the fast- paced Internet space. (Page 51)
great product managers they’re looking for are already in their organization, hiding under a different title— maybe a software engineer, user experience designer, or a Systems Engineer (SE), just waiting to be discovered. (Page 53)
Great product managers have a love and respect for good products, no matter where they come from, and they live to create them. This passion for product is an essential ingredient as it will often be called upon to provide the motivation to get through the many very difficult challenges— and long hours— of defining a great product. (Page 53)
The ideal product manager does not necessarily have to come from your target market (there are pros and cons to this), but they absolutely need to be able to empathize with your target market. (Page 54)
There is really no substitute for innate intelligence. Product management is about insights and judgment, both of which require a sharp mind. Hard work is also necessary, but for this job, it is not sufficient. (Page 55)
Hiring very smart people is harder than it sounds. Much depends on the strength and security of the hiring manager. You’ve probably heard the old adage about A’s hiring A’s, and B’s hiring C’s. It’s true. (Page 55)
However, the product manager role is not for someone who is afraid of hard work. It comes along with the responsibility; the product manager is the person ultimately held accountable for the success of the product, and this burden weighs heavily on the successful product manager. (Page 56)
Of all the members of the product team, the product manager most needs to reflect the values of the company and the product. In most organizational structures, the product manager does not directly manage the people on the project team, and as such, he can’t simply direct the people to do his bidding. Rather, he must work by influencing those on his team. This persuasion is done by mutual trust and respect— both of which depend on the integrity of your product manager. (Page 57)
Trust and respect is built over time by the successful product manager demonstrating the traits and skills of a strong product team leader. If the product manager is not perceived to have integrity, or honesty, or fairness when dealing with his teammates, then the product manager will not have the degree of collaboration and team effectiveness that he needs to get the job done well. (Page 57)
Confidence is an important trait because the entire product team, executive team, and sales organization is looking to the product manager to convince them that what they are investing their time and money and careers in will be successful, and that the vision is a good one. In communicating persuasively, confidence is a critical ingredient, and people are more likely to follow a leader who has it, rather than one who does not. (Page 59)
The successful product manager knows he is ultimately responsible for the success of the product. More importantly, he knows there are many very valid reasons for the product not to ship, or fail in the market when it does— the product is too difficult to build, it will take too long to get to market, it will cost too much, it will be too complicated, etc. But he knows it is his job to see that each and every one of these obstacles is overcome. (Page 59)
One reason so many successful product managers come from the engineering ranks is that a big part of defining a successful product is in understanding new technology and seeing how it might be applied to help solve a relevant problem. (Page 60)
There are so many distractions out there, especially for the product manager trying to create a product that customers will love. The ability to keep the focus on the key problem to be solved at any given moment, and not succumb to creeping featurism, or the loud voices of a few key people or customers, requires tremendous discipline— both company discipline and personal (Page 60)
The truth is that nearly every product has features that are not really all that important— if the features were never there, it would not significantly impact the sales or customer satisfaction. Much more often, if the features were not there, the product would be better for it as more users could comprehend and appreciate the resulting simpler product. Focus will help you reduce the number of cluttering features, reduce the time it takes you to build the product, and therefore the time it takes you to get to market and your costs of getting it there. (Page 60)
It is absolutely essential to get very skilled at quickly distinguishing that which is important from that which is urgent, and learn to prioritize and plan your time appropriately. If you can’t manage to get the time to focus on those tasks which are truly important to your product, your product will fail. (Page 61)
While communication skills can, for the most part, be learned, it can take years to become an effective speaker or writer, and these skills will be required from the start. As discussed above, the product manager influences others by persuasion rather than authority— making his case by communicating either through writing, speaking or both. (Page 62)
Being able to write clear and concise prose is a skill that product managers use every day. The successful product manager realizes that the readers are constantly evaluating him based on his writings. (Page 62)
The book Presenting to Win: The Art of Telling Your Story by Jerry Weissman is a good guide to improving your presentation skills. (Page 63)
sometimes talk of product managers needing to be bilingual. Not in Chinese and English. They need to be able to converse equally well with engineers about technology as they do with executives and marketers about cost structures, margins, market share, positioning, and brand. (Page 64)
My favorite source for product managers is to look for people with the characteristics described above and then use training, an informal mentoring program, and/ or a formal employee development program to develop these people into strong product managers. (Page 65)
It can be dangerous for a product manager to have too much domain expertise. I say that because people that have spent a long time building their mastery of one domain often fall into another common product management trap: they believe they can speak for the target customer, and that they are more like their target customer than they really are. The product manager needs to constantly revisit assumptions about the domain and the customers. It’s not impossible for people with deep domain expertise to do this, but they have to work harder at it to remain open- minded to new developments and options. (Page 67)
This is not to say that you don’t need domain expertise in order to do a good job with your product— in fact I think understanding your product domain is absolutely essential, and I don’t mean superficial knowledge either. But I believe that strong product managers can come up to speed on most new product domains very quickly if they approach the education process aggressively. (Page 67)
For many positions in the company, the truth is that you can often get away with subpar employees because there are others who will pick up the slack. However, given that most products just have a single product manager for this position, this is rarely the case. Your only real hope if the product manager isn’t fully capable is that someone else on the product team— perhaps a lead engineer— steps up to do what’s necessary. (Page 73)
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. And if you micromanage people who are not capable, you are essentially doing their job for them. (Page 75)
Every good manager knows that the best way to look good is for the members of his or her team to look good. (Page 75)
Nobody is more responsible or more accountable for the suite of products a company offers than the head of the product management organization. This person decides what products to pursue, and then closely reviews the strategy and progress for each product. (Page 75)
Net Promoter Score (NPS). It’s a very simple metric, and you can read all about it at www.netpromoter.com. Here’s how it works: You ask your customers how likely they would be to recommend your product to others, on a scale of 0- 10. Those who rate 9 or 10 are considered “promoters” (they’re out there telling their friends how much they love your product, and are actively evangelizing for you); those who rate 7- 8 are lukewarm or neutral; and those who rate 0- 6, the “detractors,” that is, they not only won’t recommend your product, they may even actively warn their friends or the public against your product. If you take the percentage of promoters and subtract the percentage of detractors, you get the NPS, which essentially tells you if you have more people cheering for you or against you. (Page 77)
And in terms of profitability, the most cost- effective sales or marketing program is your own customers doing the sales and marketing work for you. A great product with happy customers lowers these other (often very significant) costs, which contributes to profitability. (Page 78)
You can compare your NPS across companies and even across industries, which is interesting, but NPS is most useful as a way to measure your own progress towards improving your products and services. (Page 79)
The most common situation I find in the companies I work with is that product management lives within the marketing organization. The problem with this organizational design is that it is based on the misconception that you get products from talking to your customers, and that it is marketing’s job to talk to customers. I won’t repeat all the fallacies of this line of thinking here, but suffice it to say that there are several key reasons why you won’t find successful products just by asking your customers. (Page 80)
The next most common situation I encounter is that product management is put in the engineering organization. While this has the benefit of putting the people who invent and design the product next to the people who actually build the product, this can also be problematic. Why? Because engineering organizations are typically designed to focus on building a product right, rather than building the right product. (Page 80)
engineering is essentially an execution- based activity, and it can be hard to perform discovery activities in an organization optimized for execution. (Page 80)
am a big believer in raising the level of the product organization to be organizationally on par with engineering and marketing. Ideally, the product organization includes the design team, because the interaction between product management and user experience design absolutely needs to be as close as possible. (Page 81)
the head of product needs to have a seat at the table on the executive team. Companies are all about products, and marketing and engineering are each critical components with their own considerations and challenges, and it’s easy for the product to get lost in these issues. Additionally, this organizational structure makes it clear that the product is not being driven by the technology, and not being driven solely by the sales or marketing needs either. (Page 81)
Often large companies have a centralized engineering function and decentralized business units. This lets the company focus on multiple business lines, while potentially enjoying efficiencies in common engineering services. In such organizations, the product management and design function might be located in the centralized engineering/ product development organization, or it might be in its own organization, or it might be a part of the business units themselves. Often in such an organization, the business unit managers must play a major product management role, creating problems if the product management team isn’t part of the business unit. In these situations, I usually prefer integrating product management and design into the business units. (Page 81)
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. But when a product manager focuses on what problem to solve, it’s pretty amazing how many possibilities open up as to how to best solve the problem. (Page 83)
Unfortunately, the skills for interaction design are very different from product management, and it’s the rare product manager who’s good at both. Another problem I see that complicates this is that, in many companies, the user experience design resources are part of a service organization where they’re pulled in “as needed” to help with design after the spec is complete. The problem here is that this severely limits the contribution of a good designer. Designers are most valuable very early in the process, when the product manager is working to understand the target market and come up with a solution. (Page 84)
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. (Page 85)
Probably the single most important lesson I’ve learned in the product business is to start by seeking out the smartest people in the company. I’ve found that every organization has at least a few very smart people, and these people may hold the key to unlocking your company’s potential— if you can find them. (Page 86)
If you’re lucky enough to have great product people as founders, you should initiate a channel with them and invite their feedback and suggestions on your product plans. They’re often all too happy to do so, and you should absolutely find a way to utilize that resource if it is available to you. (Page 89)
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. (Page 89)
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. (Page 92)
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. (Page 92)
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. (Page 93)
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. (Page 93)
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. (Page 93)
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. (Page 94)
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. (Page 94)
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. (Page 94)
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. (Page 95)
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. (Page 95)
Defining The Problem To Be Solved Opportunities for new products exist all around us, in every market— even mature markets. This is because what is possible is always changing. New technologies are constantly emerging, competitors come and go, and new people with new talents and new ideas join your company. The product manager must be able to quickly evaluate opportunities to decide which are promising and which are not; what looks appealing, which should be pursued, which are better left for others, and which ideas are not yet ready for productization. (Page 98)
Unfortunately, too often the process of deciding whether or not to build a product is left to intuition (or worse, a large customer will offer to fund a “special,” and this becomes the basis for a product effort). (Page 98)
Typically someone on the business side or in marketing will create some form of a Market Requirements Document (MRD) that is intended to describe the problem to be solved and usually includes a business justification. The purpose of the MRD is to describe the opportunity, not the solution— at least, that’s the theory. In practice, many companies don’t really do MRDs, or if they do, they’re essentially attempts at product specs that are misnamed as MRDs. Even if a true MRD is done, they suffer many of the same problems as PRDs— that is, they take too long to write, they aren’t read, and they often don’t answer the key questions they need to address. (Page 98)
I consider the Product Opportunity Assessment an extremely important responsibility of the product manager. The purpose of a good product opportunity assessment is to either (a) prevent the company from wasting time and money on poor opportunities by ultimately proving the idea should be shelved for now, or (b) for those opportunities that are good ones, focus the team and understand what will be required to succeed and how to define that success. (Page 99)
it’s really not that hard to do a useful opportunity assessment. 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) (Page 99)
The opportunity assessment should just discuss the problem to be solved, not the particular solution you may have in mind. The majority of your time going forward will be focused on the solution, but this is the time to think clearly and concisely about the problem you are trying to solve. (Page 100)
All too often what happens is that a product manager combines the problem to be solved with the solution and, when they run into difficulties with the particular solution they are pursuing, they abandon the opportunity. (Page 100)
The hardest question to answer is usually the first in the opportunity assessment, the value proposition, which surprises many people because it sounds like the easiest. But ask most product managers what problem their product is intended to solve, and you usually get a rambling list of features and capabilities, rather than the a crisp, clear and compelling statement of the exact problem that’s being solved. (Page 100)
Another difficult problem can be assessing the size of the opportunity. You can get thoughts on this from industry analysts, trade associations, your finance staff, and from your own bottom- up calculations. Just remember to be conservative and realize that not every opportunity needs to be a billion- dollar market. (Page 101)
The go- to- market strategy is especially important as it describes how the product will be sold, which can have very significant impact on product requirements. (Page 101)
The success factors, or solution requirements, refer to any special needs or requirements that were identified during the investigation. Again, we’re not describing the product here, but rather making clear any dependencies or constraints. (Page 101)
A product organization is all about pursuing good opportunities and providing great product solutions. Opportunities for new products are everywhere, and it is important that the product manager be able to effectively evaluate new opportunities and identify those that have the most potential for their company. It is just as important that bad product ideas get identified and rejected at this stage, before significant time and money is lost chasing them. Choosing the right set of products to pursue is among the most important decisions a company will make. (Page 101)
It is important that the results of the product opportunity assessment be presented and discussed with senior management, and that the company make a clear decision on whether or not to pursue a product to meet this opportunity. If you do decide to proceed, you will be much better informed about what you are getting yourself into, and what it will take to succeed. (Page 102)
So what do you do if the CEO tells you that, like it or not, this is what we’re doing, so just get to work on the product? First, realize that there are sometimes strategic reasons for doing a particular product, so you might need to pursue it even when it’s unlikely to succeed in the marketplace. That said, doing a lightweight and quick product opportunity assessment is still valuable because you will become much better informed about what the product involves. It is possible that what you learn will change your CEO’s opinion, but even if not at least you will have a clear understanding of your objective. (Page 102)
To me, all projects, whether a new 1.0 product, or an enhancement to an existing product, are product investments and instead of worrying about whether you’re investing enough in new product lines versus existing product lines, I would rather have the team worry about investing in the best opportunities. (Page 103)
Many times, the best product opportunities are sitting right under the company’s nose. In particular, often the biggest bang for the buck comes from improving existing products that are not performing at the level they should and could be. (Page 103)
Companies tend to believe that their products are inherently complex, or that a 9% conversion rate isn’t bad, or that they just need to spend more on customer acquisition marketing or advertising, or that investing in customer service is just a necessary cost of doing business. However, what’s actually going on is that the product is weak, and the company is just trying to make the best of what they have. On one level, this is just another symptom of companies under- investing in design and user experience. But more generally, the truth is that many products are poorly done and, rather than improve a product to the point where it can generate real revenue and success, many organizations view it as easier to create a new product instead. But unless they change the way they produce that new product, they’re likely going to end up with yet another under- performing product in need of improvement. (Page 104)
I learned a long time ago that I could benefit a great deal from making a friend in the finance department. (Page 106)
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, (Page 106)
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. (Page 106)
Realize the life of a finance person is largely thankless, and driven by extreme deadlines (“ Our quarter closes on Thursday and we’re announcing earnings on Monday!”). I also have a theory that people in finance are often fairly quiet, and not the type to come to your desk advocating product opportunities. Usually, you’ve got to go to them. (Page 107)
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. So go make a friend in finance. You need the information they have and their help in interpreting the information and putting it to good use. I think you’ll find that these people want to help their company, and appreciate the opportunity to do so. (Page 107)
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. (Page 108)
When in product discovery, you welcome and explore new ideas, talk with scores of users and customers, learn how you can apply new technologies, flesh out your product concepts and test them out, and spend a lot of time thinking about the overall product direction, both immediate and longer term. It is all about discovering that mix of form and function that results in a winning product. (Page 109)
However, once you’ve spec’d out this product, and your engineering team begins the process of building it, a very profound and important shift needs to take place for the product team. Now the game is all about execution— getting the product built, tested, and delivered to market. In this stage, you spend your time keeping everyone focused, chasing down the countless issues that inevitably arise, and getting these issues resolved immediately. Acquisitions, competitors, organizational and management changes— these are all distractions, and your job is to keep the team on track so this product can get out there when it needs to be. (Page 109)
If you’re naturally a discovery kind of person— preferring the freedom and creativity of the invention process— then you’ll have to work extra hard to contain those urges during execution. On the other hand, if you’re more naturally the project manager type who loves getting things out the door, then you’ll need to work on your strategic thinking and discovery skills— remembering that what matters most is creating a product that your customers love. (Page 110)
One technique I have found very useful is to always keep two versions of a product going in parallel. In other words, as soon as you start the engineering for release 1.0 and switch into execution mode for that project, then you start up the discovery for release 2.0 in parallel. Always keep that innovation engine working— once a given release goes to engineering, redirect your creative urges to the next release. One note of warning: You do need to be careful that this approach doesn’t detract from the execution work for the current project. (Page 110)
It doesn’t help to talk to users, create prototypes, and test with users, if you don’t adjust your course based on what you learn. (Page 112)
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. (Page 112)
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. (Page 113)
Sometimes the product discovery phase is straightforward. Other times it is extremely difficult. In my experience, it’s not so hard to discover and validate the market opportunity, but it’s often very challenging to discover the solution. Even with the help of great designers and great engineers, some problems are just truly hard (at least many of the ones worth pursuing and that haven’t been solved already). The pharmaceutical drug industry provides an extreme example. The market discovery process is usually not very difficult— there are no shortage of good medical problems worth solving (like saving your life, extending your life, or improving the quality of your life). The hard part of course is discovering a product solution. (Page 113)
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. (Page 114)
Startups especially must focus their energies on this much faster product discovery process. And once they discover the solution that works— one that is valuable, usable and feasible— then it’s all about execution. Until that point, they don’t have to hire too many engineers right away— the engineers they already have can and should actively participate in the product discovery process. (Page 115)
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. (Page 116)
When I start working with a product team, once I understand the business strategy, often one of the first activities we do together is to define a set of product principles. 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. (Page 116)
Product principles are not a list of features and, in fact, are not tied to any one product incarnation. In this sense, they are most aligned with a product strategy for an entire product line, or with a company mission statement for a startup. A good set of principles serves as the basis or foundation for inspiring product features. (Page 116)
a set of product principles can bring together the product team— especially product management, user experience design, engineering, and marketing— and get the team on the same page. (Page 117)
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? (Page 120)
It is extremely important to take prioritization seriously— you should get the team to agree on the specific ordering, most to least important. Don’t just wave your hands and group the goals into something like “critical” and “very important.” Be sure your team can identify what is most critical, then second most critical, and so on. (Page 120)
I think it is very important for product managers to be completely transparent in their decision making process and reasoning. You don’t want the team thinking that you’re just following your intuition. Every member of the team should be able to see the goals and objectives you are using, their priority, and how you assess each option. The decision— and the reasoning behind how you got there— should be clear to all. (Page 121)
THE PRODUCT COUNCIL Timely And Definitive Product Decisions Even in small companies, getting decisions made is often time consuming and frustrating. Every product company needs a mechanism to get the key stakeholders and decision makers together to make timely and informed product decisions. My favorite way to ensure this is to establish a product council. (Page 123)
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. (Page 123)
Membership The Product Council is typically comprised of the cross- functional set of managers responsible for product development. Every company has its own considerations, but an example might be: 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 As with any such group, the effectiveness of the meetings will largely be a function of the meeting skills of the leader. The leader needs to be good at staying on task, framing issues, and driving to decisions. Usually, the leader of the product council is either the head of product or— for smaller companies— the head of the company. Make sure you have representation from the key areas, but try to keep the group at 10 or less. (Page 124)
Specific Responsibilities This is not a group that designs or builds products. This group should oversee the flow of products through the product development process, and make the key decisions required. (Page 125)
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. (Page 125)
you find your product organization taking too long to make decisions, consider instituting a product council. Hopefully you’ll find that this one meeting eliminates countless others and makes the decision process informed, transparent and timely. (Page 127)
Even though we’ve been estimating project costs since the very beginning of software development, it’s remarkable to me how much confusion remains. I believe the root cause of this confusion is that management needs cost information very early in the process, yet engineering doesn’t have the information it needs for a reasonably accurate estimate until much later in the process (because there’s virtually no good information yet on the solution required). The result is either premature estimates that prove wildly inaccurate, or surprises because people had different assumptions all along and— when the accurate estimate eventually does come in— management experiences a severe case of sticker shock. (Page 128)
This assessment is what the management team uses to decide whether there is a problem worth trying to solve. There’s no solution yet, just a problem and an opportunity. But, for most teams, there’s a clear need at this stage for a very preliminary estimate of project scope. Of course, since there’s no solution spelled out at this stage, it’s going to be very much a SWAG (a “scientific wild- assed guess”) which is why I recommend that the estimates at this stage be limited to “Small,” “Medium,” or “Large.” It’s usually fairly clear at this granularity what the cost will be, although there will still be occasional surprises. (Page 128)
If the opportunity looks good relative to the estimated cost, management will likely allow the project to proceed to defining the solution. It is at this stage that the product solution is spelled out in detail, ideally with a high- fidelity prototype that you validate against real target users with prototype testing. Throughout the process of coming up with the solution, the product manager and interaction designer should include a member of engineering to evaluate the various options and estimate costs for the different alternatives. This information is then considered by the product manager and designer and the product is adjusted as needed. But at the end of the spec process, there should be a very detailed and high- confidence estimate based on a detailed description of the product proposed to be built. (Page 129)
At this stage, the management team has a detailed product spec, and a corresponding high- confidence cost estimate, and they should be able to make a final decision on whether to proceed to build this product or not. It may be that the solution turned out to be more complex and expensive than they thought, or they might not like the actual solution, but if they do proceed the entire product team knows the cost and the product they’ll get for that investment. (Page 129)
To summarize, I’m suggesting a preliminary estimate at opportunity assessment time, followed by a detailed estimate that accompanies the final product spec. (Page 129)
Most marketing people will tell you that nothing is more important or compelling when launching a product than to have a solid set of reference customers (or reference applications for a platform product). Yet it continually amazes me how many products launch with none. (Page 130)
If at launch there are a half- dozen marquee names publicly stating their use and satisfaction with a product, then the job of the sales and marketing folks is dramatically easier, as the greatest risk the potential customer faces is dramatically reduced. On the other hand, if good reference customers are missing, all the creative marketing and clever sales tactics in the world will only take you so far. If there are no references, this is a huge red flag, and it usually means the product is either bad, or not yet ready for prime time. And you don’t want to be the first to try to use it. If there’s only one or a few reference sites, I worry that what’s been built is essentially a special, or custom solution, and that it won’t be generally useful. (Page 130)
As product manager, you know your job is to gain a deep understanding of your target customer, the problems to be solved, and whether you can come up with a product that meets these needs. (Page 131)
My favorite technique for addressing both of these problems— getting deep insight into my target customers, and having great reference customers at launch— is to use a charter user program (also known as a Customer Advisory Board, Customer Council, or Voice of the Customer). This is not a new technique (I did my first at HP about 20 years ago), and many companies do this. But I’m surprised how many do not. (Page 131)
The program is fairly straightforward. Your goal is to end with at least six happy, live, referenceable customers from your target market. That means you’ll probably need to start with 8- 10. So your job is to recruit these customers right at the start of your project. You’re looking for customers in your target market who would make great references. They may be from your existing customer base, or prospects, or often a blend of both. The key is that they believe this is a real problem to solve and they need it solved as quickly as possible. (Page 131)
Note that while many of my examples are for customers in an enterprise software or a platform product sense, these techniques also work with end- users for consumer Internet services and consumer devices. For consumer services, you will want to expand the set to 10- 15 or so, but the key is to really get to know these people and the environment in which they will be using your product— home or office. It is all too easy when designing a site for consumers to not have enough exposure to true target users until very late in the process (beta or even launch). This is very dangerous, and a program like this helps keep the product manager focused on providing real value to real users. In (Page 135)
Every so often I meet a product manager who tells me she is not allowed to talk to users or customers. Sometimes it’s because the sales reps want to control all such access, or maybe it’s because marketing is supposed to be the interface with the customer, or perhaps the product is sold through a channel. Occasionally, there is a corporate policy restricting direct customer access because of worries about inappropriate statements or commitments. (Page 136)
Whatever the reason, if you work at a company where you’re told you can’t talk to your users, my advice is to first try hard to change this policy. If that doesn’t work, dust off your resume and find a place where you can practice your craft and have a shot at creating successful products. I really don’t know how you can build products users will love without a deep understanding of those users, and you won’t get that without lots of direct communication— including face- to- face interactions. (Page 136)
To be very clear, I believe that the product manager should attend every user interview, every site visit, every usability test, and every charter user program meeting that pertains directly to his product. (Page 137)
One often controversial topic is the appropriate role in product discovery of market research tools and techniques such as focus groups, customer surveys, site analytics, site visits, usability testing/ field testing and competitive analysis. Unfortunately, I think this is an area of significant confusion, fueled in part by the various camps— those from a marketing background that may see the benefits of these tools, and those from product that see the limitations. The result is that some product teams miss out because they don’t take advantage of the information these tools and techniques can offer. (Page 139)
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. (Page 140)
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. (Page 140)
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. (Page 140)
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. (Page 141)
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. (Page 141)
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). (Page 141)
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. (Page 142)
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? (Page 142)
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? (Page 142)
As useful as market research tools and techniques are, I know of no winning product that was created by market research. Not Google, not eBay, not the iPod or iPhone, not FaceBook or MySpace. None. Winning products come from the deep understanding of the user’s needs combined with an equally deep understanding of what’s just now possible. (Page 143)
while you can learn about your target customers, I can promise you that you won’t discover great products from focus groups. How come? There are two very fundamental reasons why not: Customers don’t know what’s possible. Most have no idea about the enabling technologies involved. Customers don’t know what they want. It’s very hard to envision the solution you want without actually seeing it. (Page 144)
There are other drawbacks to focus groups: First, there is a dynamic that happens when users get together. They influence each other so much that you lose the pure input of each, and instead get a skewed representation influenced by the most articulate or vocal attendees. Second, related to the point about customers not knowing what they want, it’s very hard to get useful data about a product idea unless customers can actually see and interact with the product. Most often, focus groups are conducted prior to the stage where that is possible. Third, as with surveys, there is an art to conducting focus groups, and finding someone who actually knows how to conduct them effectively, and when they should and should not be used. Add a requirement to understand your product domain enough to elicit the depth of conversation you need, and it can be tough finding the right person for the job. (Page 144)
PERSONAS FOR PRODUCT MANAGEMENT Understanding The Target User Product management is all about choices— making decisions about what opportunities are worth chasing, which problems are worth solving, what features will provide the most value, what the best time- to- market trade- offs are, and which customers are most important. While you’ll never make all the right choices, you have to make most of them right for your product to succeed. (Page 146)
One of my favorite tools for helping to make the hard decisions is a persona (aka user profile)— a technique for capturing the important learnings from interviewing users and customers, and identifying and understanding the different types of people who will be using your product. The persona is an archetype description of an imaginary but very plausible user that personifies these traits— especially their behaviors, attitudes, and goals. (Page 146)
The Inmates Are Running the Asylum , by Alan Cooper. If you haven’t read this book you should— it’s a classic for product managers, designers, and engineers. (Page 146)
To get the true potential of personas, the product manager needs to be deeply involved in their creation and prioritization, and especially the user interviews and research that goes into identifying them. The creation of personas should be a collaboration between the product manager and interaction designer and— if you are lucky enough to have them— your user research team. But whatever you do, don’t delegate this task. (Page 147)
I always encourage product managers to actively participate in the creation of personas— and make sure they are done as early in the process as possible. (Page 147)
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. (Page 148)
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. (Page 149)
I have seen a few truly good product specs, but most specs take too long to write, they are seldom read, and they don’t provide the necessary detail, don’t address the difficult questions, nor contain the critical information they need to. And— most important— it is all too easy for the mere existence of the spec to serve as a false indicator to management and the product team that everything is proceeding just fine. (Page 151)
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. (Page 152)
Except for the most trivial of user interfaces, I am not a fan of so- called paper prototypes. With the tools available today, it is now so quick, easy, and inexpensive to create a high- fidelity prototype for most products that there is no reason not to do so. This is still a prototype, so it’s fine to fake (simulate) the backend processing and data, so long as the user experience is plausible. (Page 153)
I advocate prototyping virtually everything— all pages/ screens, and all the major use cases. There will still be some error conditions and corner cases that don’t pay to prototype, but the benefits of having a high- fidelity representation of the product that the full product team can interact with to understand the product to be built are so great that they dwarf the incremental costs. (Page 153)
It is true that you will still need to supplement the prototype, as there are aspects of the proposed product’s behavior that are not easily represented in a prototype, such as business logic (e.g. tax tables and shipping charges), the release requirements (e.g. reliability, performance, scalability) or platform delivery requirements (such as installation requirements, or the list of browser versions to be supported). Also useful as a supplement are use cases, describing the most important flows through the product. (Page 153)
a high- fidelity prototype can be tested. You can put it in front of actual target users and ensure that they can figure out how to use your product (usability), and also determine if they care to use your product (value). You don’t actually have a spec worth handing over to engineering until your prototype passes these two tests. Doing this form of testing while you are in QA or Beta is far too late in the process. (Page 154)
can promise that if you give this a try— creating a high- fidelity prototype of the proposed functionality and user experience— your product team will absolutely love it. Engineers are the immediate winners as they finally get a spec that effectively and unambiguously describes the product they need to build, and that they can refer to at any time when they’re confused about how something is supposed to behave. The job of QA is similarly made easier as they now know what should happen when they test the actual product. Marketing, sales, and customer support will love being able to learn the product much earlier in the cycle. You’ll also find that your execs will love it too as they can describe what you’re doing (and demo the prototype) to investors, board members, and partners much more effectively than any PowerPoint deck can do. (Page 154)
The biggest surprise for most teams is that creating a spec this way will typically significantly reduce time to market. Yep. I realize this may sound counter- intuitive, but to understand why the total time to market is faster, you have to look a little deeper at what almost always happens in a software project. Because the typical spec is so poor (incomplete, ambiguous, and especially untested), and so few of the hard questions and critical details are actually addressed and resolved, it is during the engineering phase that the team is forced to tackle these issues. This results in either tremendous churn (the specs keep changing resulting in delays and frustration in engineering), or the engineers just make assumptions as best they can, and the product that ships is a mess and one or more update releases are required before you actually get something useful to your customers. In either case, the time to market is longer than it should be. (Page 155)
DESIGN VS. IMPLEMENTATION Define The User Experience Before Proceeding To Build (Page 157)
I have long argued that requirements (functionality) and design (user experience design) are intertwined and should be done together. I don’t like the old waterfall model of a product manager doing “requirements” and handing that off to interaction designers that do “design.” (Page 157)
I also believe that great strides have been made by software engineering teams that have learned the value of doing implementation and testing in parallel. The old model of the engineer writing software and then handing it all off to a QA person to test actually takes longer and the result is less reliable. Agile methods like XP demonstrate the value of doing implementation and testing in concert. (Page 157)
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. (Page 157)
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. (Page 158)
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. (Page 158)
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. (Page 159)
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. (Page 159)
If you try to start implementation at the same time as design, here’s what you will almost certainly see: the designers will be stressed trying to accomplish weeks worth of work in just days, the engineers get anxious as they wait for the designers to give them something, soon the designers will reluctantly make some preliminary guesses to allow the engineers to get going and then hurry to try to get something decent put together before the engineers get too far down the path. However, when they finally do have something, it’ll be too late and the engineers will say “we can get to it in the next round” but of course the next round has its own priorities. The designers do not feel good about what is built and shipped, and the customers don’t like the result either. In the worst- case situation, the designers come to the conclusion that they need to go work for a company that prioritizes the user experience. (Page 159)
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. (Page 160)
The exception to the rule is when the engineers have a lot of backend infrastructure work to do. In this situation, the engineering team can be working on this while the user experience is being defined. There will be some interdependencies, but they can be managed. If your user experience designers are about to revolt, have your engineers work on the infrastructure for a release cycle or two, as this gives the designers time to work on creating a backlog of good design. (Page 160)
Note that although I’m advocating that requirements and design are both done before implementation begins, you will still need at least someone from engineering to review the design work from the start, as it’s critical for them to assess feasibility and costs along the way. This is necessary to inform the design process. Remember that the objective is to ensure that you discover a product definition that is valuable, and usable. (Page 160)
MINIMAL PRODUCT Cutting Features Versus Slipping Dates (Page 161)
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. (Page 162)
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. (Page 162)
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. (Page 163)
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. (Page 163)
You will still have some cases where you have the same tough decision— a common situation is when one or more features takes engineering longer to build than they anticipated— but in this model, the normal response is a schedule slip rather than a feature cut. Remember, you’ve already done the cutting. The good news is that the estimates in this process are better than normal because— with a high- fidelity prototype on which to base an estimate, rather than a paper document— engineering had more time to evaluate the functionality, they feel more ownership in their estimates, and there is also less product to build. So, when slips do occur, they’re not as severe or frequent as we are used to. (Page 163)
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. (Page 163)
for just about every type of product today, the costs to produce effective prototypes or simulations has come down so far that I am amazed I continue to encounter product teams that don’t do this. (Page 165)
One of the biggest and most common mistakes product teams make is to have far more confidence in their product specifications than they should. They move forward, thinking they’ll adjust the product— if necessary— once they get beta feedback. But of course beta is far past the time for major changes, and it is little wonder so many initial product releases are so far off the mark. (Page 165)
The key is to prove to yourself and to the rest of the product team that the spec you give them describes a winning product. You can do this, and it costs far less than you probably think. There are three important types of validation that you need to perform before you hand over a final product specification to the engineering team: (Page 165)
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. (Page 166)
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. (Page 166)
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. (Page 166)
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? (Page 167)
Today, there are outstanding prototyping tools that can let engineers or designers rapidly create very functional prototypes (often in hours or days) that can effectively emulate the future product— to the degree necessary— and form the basis of realistic user testing. Moreover, most managers today understand that building a simulation and building the actual product are very different animals— akin to building a scale model of a house versus building the actual home. (Page 168)
PROTOTYPE TESTING Putting Your Ideas In Front Of Real Users By this point you should know that I view the high- fidelity prototype as the primary means of describing the product to be built— a prototype is significantly more useful to the product team than the typical paper- based specification. (Page 170)
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. (Page 170)
testing your ideas with real users is probably the single most important activity in your job as product manager. (Page 170)
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. (Page 171)
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. (Page 173)
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. (Page 181)
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. (Page 182)
Don’t Make Me Think by Steve Krug. It’s mostly a book on interaction design, but in the back third he makes a compelling case for this sort of informal testing, and he provides many useful tips. (Page 182)
my favorite product testing firm is Creative Good (www.creativegood.com). These guys specialize in a form of testing they call Listening Labs , which is a powerful form of undirected testing that can find huge issues with your product— functionality and design— resulting in dramatic improvements to the business results. While most testing firms test the products on a task basis, these guys are good at looking at the big picture, which is where many of the biggest improvements are to be found. (Page 182)
IMPROVING EXISTING PRODUCTS It’s Not About Adding Features Many product managers get thrown off course when it comes to continuing development on an existing product. Most have a detailed product roadmap with all their great ideas of what they should add, or the roadmap is loaded with requirements that come from specific customers—“ If you want me to buy this you’ll need to add these six features…” (Page 183)
Most product organizations are essentially feature factories (with some bug fixing thrown in). For them it is all about adding features. (Page 183)
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. (Page 185)
So when you’re trying to improve an existing product, don’t fall into the trap of gathering subjective feedback, eliciting customer requirements and chasing features. (Page 185)
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. (Page 186)
So what causes user abuse? Mainly change. As a general rule, users don’t like change. Sure they want the software to be great, and they clamor for new functionality, but most people aren’t excited about taking the time to learn a new way to do something they can already do. (Page 187)
The solution to user abuse isn’t to prevent change, it’s to be smart about deploying change. (Page 187)
I call the process of deploying updates intelligently and carefully to a large community of users “gentle deployment.” (Page 188)
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. Give these people sufficient notice of when support for the old version will be discontinued. For a significant client or service with a large community, expect this process to take months. Also expect some heat from your engineering and site operations organizations because it is not easy to support parallel versions. (Page 188)
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. (Page 189)
RAPID RESPONSE Finish What You Start And Save Entire Release Cycles I’ve discussed elsewhere in this book the pitfalls of confusing product launch with success, and how important it is to not lose focus after you ship your product or service. (Page 190)
In many organizations, the resources that have been marshaled to build and launch the product evaporate very quickly after launch so they can be applied to the next project coming along. This is especially unfortunate because this is the moment when your opportunity for learning and correcting is greatest. I consider this a project management and product development process failing that can be corrected simply by slightly extending the project to incorporate this critical phase. No phase of the process will provide a better ROI than this one, so the change is not a difficult pitch to management. (Page 190)
I advocate that all project teams schedule a phase that begins at launch and lasts typically a few days to a week. I call this phase rapid response, to emphasize that it is all about responding quickly to what you learn once the product has been launched. (Page 191)
Even if you’ve done all of the early prototypes and validation testing prior to engineering that I advocate— and you have a great QA team so the product is reliable— you still need to expect that there will be issues that can only be discovered once you’re live. The typical approach of waiting to see what the response is and if any issues exist— and then trying to schedule follow- on point releases following the same general cycle— takes far too long and costs far too much. The question is not whether there will be issues but, rather, how quickly will you address them? (Page 191)
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 (Page 194)
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 (Page 194)
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. (Page 194)
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 Agile environment than others. (Page 195)
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. (Page 195)
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. (Page 195)
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. (Page 196)
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 (Page 196)
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. (Page 196)
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. (Page 197)
Some Agile advocates and practitioners argue that the team should just consider the early sprints as the working prototype. And in fact, for custom software efforts where there really isn’t true product management and rarely user experience design, this is the essentially the best you can do. However, for product software organizations, you can and must do better than this, for three reasons: First, a sprint is typically far too long to wait to try out an idea— an idea which will most likely be wrong. It is much faster to try that idea out with a disposable prototype in days rather than wait months for one or more sprint cycles. Second, there are typically too many critical things for the engineering team to do to use them for the product discovery process. By taking their time for this prototyping work they are not able to do what they should be doing— building production software. Third, while Agile methods do much to encourage the team to learn and respond quickly, it is still difficult and time consuming for a team to change directions significantly once they have begun down a path, and put long hours into a particular architecture or approach. (Page 197)
Many are surprised to learn that Scrum, the most popular of the Agile methods, is now over 20 years old. It was created in 1986 in Japan. (Yet another example of just how long it can take for a new idea to reach the tipping point). But most importantly, these methods originated in the custom software world. The custom software world— building special purpose software for specific customers— has long been a brutally difficult type of software. This is partly because customers notoriously don’t know what they want, but they have a need so they write a contract with a custom software supplier, or sit down with their internal IT folks, who then work to deliver. When they do deliver, the customer invariably responds that it really wasn’t what they had in mind, so the cycle repeats and frustration mounts. But the core need still exists, so this provides job security for countless IT developers, custom software shops, and professional services businesses. (Page 199)
In the custom software model, since the customer believes he knows what he needs, you’ll rarely find the role of the product manager. Likewise, you’ll almost never find user experience designers. The reasons for this are more complex, and involve a degree of ignorance (relatively few in the custom software world realize what user experience designers do and why they’re needed), and cost sensitivity (cut costs by letting the developers design). But to be fair— due to the shortage of user experience designers in our industry— the few available are immediately grabbed by the product companies that realize how critical they are, so custom software teams can rarely find designers even if their leaders realize they need them. Similarly, QA as a discipline is rarely found in custom software projects— again, the developers are typically expected to do the required testing. (Page 200)
Agile methods encourage engineers to not get attached to their implementation, believing that things can be re- factored or rearchitected relatively quickly and easily. This is true for the vast majority of custom software, but for many product software systems, such as large- scale consumer Internet services— which must support hundreds of thousands if not millions of users— this approach can be naïve. (Page 202)
So it shouldn’t be a big surprise that the main issues many product software teams encounter with Agile methods stem from their custom software origin. Many Agile books, articles, and training classes still don’t mention product managers— or any form of user experience designers (interaction designers and visual designers)— because they aren’t meant for product software teams. My suggestion to teams moving to Agile is to make sure the firm you hire to help your organization transition to Agile actually understands the differences that product software demands. Most don’t, but some do. (Page 202)
While it has long been unfashionable for a team to describe their product development process as waterfall, in most cases that is essentially what is still being followed, (Page 203)
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. (Page 203)
Management appreciates the (perceived) predictability of the process. It is possible, although not common, to come up with fairly accurate schedules for even large and complex software projects. This assumes, however, that you completely and accurately understand the requirements and the technology, and that there will be no changes. With iterative approaches, you don’t really know how many iterations will be required, and this can be disconcerting to management. There are deliverables throughout the process. Many people (managers, customers/ clients, and even some engineers) are reassured by seeing well thought- out and thorough documents and design diagrams. It helps these people to gauge progress towards the end, and it also helps them feel better about the level of thinking that has gone into the project (even though there is no way to test whether or not the confidence is justified because unlike software you can’t execute paper documents). Many people make the mistake of feeling unjustifiably reassured by impressive specifications and documents. (Page 204)
Validation Occurs Too Late in the Process The most costly issue is that there is typically no actual working software until nearly the end of the process, so there is little if any visibility into whether the software will be useful until after the majority of the investment has been made. The product manager must ensure that, prior to moving into the expensive design and implementation phases, the product must be prototyped and tested on actual target users. This ensures the specification that is eventually provided to the product development organization describes a product that has been successfully validated with the target audience. Likewise, if there are major technical risks, these too should be explored and feasibility questions resolved (by the engineering organization) prior to beginning the actual architectural design and implementation. Before proceeding, the team needs to know that the product specification is something that can be successfully delivered. (Page 205)
Changes Are Costly and Disruptive Any change to decisions from previous stages destabilizes the process and causes considerable pain and cost, as much work has to be reviewed and reworked. Moreover, the coding and testing process often uncovers issues in requirements and in architecture that can cause major delays and pain in this process. The product manager must constantly represent the voice of the customer and user and there will be times when changes are required. It is important to point out that the cost of postponing the change needs to include the cost of the follow- on release to make the correction. There will still be times when it makes the most sense to defer the change until the next release, but in many cases it will be less expensive to course correct sooner rather than later. (Page 206)
Responding to the Market This approach has a relatively high overhead in terms of documentation and process for moving through the phases. One consequence of this is that it can take considerable time to make even relatively small changes to the software. This puts additional pressure on the product manager to ensure that they are providing a validated specification for a successful product in the first place, but it also means that the product manager will need to work with the product team to make course corrections as quickly as possible after release. (Page 206)
In many ways, the Waterfall process represents an idealistic but naïve view of the software development process, where people are able to anticipate the key issues and fully understand the requirements. When this is the case— usually only for very small projects— this approach can provide a reasonable path to a quality implementation. Unfortunately, this is rarely the case with product software. In practice, the consequence is that the product ships later than planned due to changes, and then expensive, time- consuming follow- on releases are required to correct issues once real users have a chance to see and use the software. (Page 207)
The most important thing is to ensure that during the requirements and design phases, the emphasis must be on true product discovery— identifying a product that is valuable, usable and feasible— and that the product spec is validated (by building a prototype and testing it with real users) prior to moving to the implementation phase. If you do this, you’ll not only stand a much better chance of defining an inspiring and successful product, but you’ll also save your team significant time and cost. (Page 207)
Startups are essentially all about new product creation, so they’re a terrific place for product managers to do their thing, and it’s why I love working with startups so much. Yet I believe that the prevalent model for how startups come up with their first product is terribly inefficient, and it’s why so many otherwise good ideas never get funded or make it to market. (Page 208)
Here’s how the model typically works: Someone with an idea gets some seed funding, and the first thing he does is hire some engineers to start building something. The founder will have definite ideas on what she wants, and she’ll typically act as product manager and often product designer, and the engineering team will then go from there. The company is typically operating in “stealth mode” so there’s little customer interaction. It takes much longer than originally thought for the engineering team to build something, because the requirements and the design are being figured out on the fly. After six months or so, the engineers have things in sort of an alpha or beta state, and that’s when they first show the product around. This first viewing rarely goes well, and the team starts scrambling. The run rate is high because there’s now an engineering team building this thing as fast as they can, so the money is running out and the product isn’t yet there. Maybe the company gets additional funding and a chance to get the product right, but often it doesn’t. Many startups try to get more time by outsourcing the engineering to a low- cost off- shore firm, but they’re still left with the same process and the same problems. (Page 208)
Here’s a very different approach to new product creation, one that costs dramatically less and is much more likely to yield the results you want: The founder hires a product manager, an interaction designer, and a prototyper. Sometimes the designer can also serve as prototyper, and sometimes the founder can serve as the product manager, but one way or another, you have these three functions lined up— product management, interaction design, and prototyping— and the team starts a process of very rapid 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. (Page 209)
In this model, it’s normal to create literally dozens of versions of the prototype— it will evolve daily, sometimes with minor refinements and sometimes with very significant changes. But the point is that with each iteration you are getting closer to identifying a winning product. This process typically takes between a few weeks and a few months. At the end of the process, you have (a) identified a product that you have validated with the target market, (b) a very rich prototype that serves as a living spec for the engineering team to build from, and (c) a much greater understanding of what you’re getting into, and what you’ll need to do to succeed. (Page 209)
There is a lot of cynicism out there about whether or not you can really innovate in a big company. Some believe that nearly all true innovation happens in the startup environment, and that the best a large company can do is either copy those innovations or acquire the successful startups. While I agree that it is certainly much easier to innovate in a startup, innovation most definitely can happen in larger companies as well. (Page 211)
as organizations get larger, they invariably become more conservative, and less willing to take risks. Again, this is because large companies have much more to lose than smaller companies, so they get really good at protecting what they have. But there are also substantial advantages to shipping product from a large company and, despite their risk- averse nature, your company does need you to innovate. (Page 211)
The two biggest factors influencing your ability to innovate in a large company are your corporate culture and your manager. In my experience, there is much that the typical large company could do to improve the ability of their employees to innovate. (Page 211)
Many of you have heard that at Google, engineers get to spend 20% of their time on the projects of their choice. More than 20 years ago, this was also the policy for our team at HP Labs, and we borrowed the idea from Xerox PARC. It worked then and it still works now. At HP Labs, our job was to come up with innovative technologies that the product divisions could then incorporate into commercial products. In the group I was in, we took five new products to market, and only one of them was for a technology that came from above (and that product was the one that actually failed badly in the market). The other four innovations were fruits of the 20% rule. (Page 212)
As much as we might like to think that the great product ideas are the result of great strategic planning, or that they come down from the executive team, in many cases, the best ideas come from the bottom up. What’s great about the 20% rule is that lots of ideas can be tried out. And when you inject the feeling of ownership that comes from thinking up the ideas yourselves, the ideas are pursued with more passion and creativity. If your company has the 20% rule, make sure it applies to product managers and interaction designers as well as to engineers. (Page 212)
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. In large organizations, it’s hard to get permission to officially explore ideas. However, once you have proven an idea, it’s remarkably easy to get the project funded. So long as you continue to carry out your official job responsibilities, management is usually supportive— many times they’ll even pitch in and help. (Page 213)
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. (Page 213)
The key is to get the product in front of actual target users, not early adopters, and not anyone from your company (including you). You don’t need formal usability testing labs either. You can do this informally, and you can often take the software out to the users (ideally in their native habitat— their office, their home, or the mall). (Page 214)
Remember: innovation is rarely about solving an entirely new problem. More often it is solving an existing problem in a new way. So watching people struggle with their existing solutions is a great way to highlight innovation opportunities. (Page 214)
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. Not just more efficient implementation of tasks, but eliminating tasks altogether. What is really essential, and what is there just because it’s a side effect of the way the product is designed and built? (Page 214)
Every system has an implementation model that is the basis for how the product was built. But the user doesn’t think this way— he has a conceptual model in mind for how he wants to think about this problem, and what he expects the system to present. Frustration happens when the user is presented not with something that reflects his conceptual model, but instead reflects the implementation model. (Page 215)
Many product managers view an acquisition as a failure on their part. But in truth, acquisition can be an excellent technique for innovation— especially in areas where the risks are high. In essence, the company lets dozens of startups test the waters, try out their ideas, and either succeed or fail. The few remaining companies with products that work out may be good candidates for acquisition. Not only does this sort of acquisition bring in innovative new technologies, but they also bring in new blood with new ideas that you can leverage for your own purposes. (Page 215)
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. There are many cases where the company that was acquired did not choose the highest bid, but instead the company that had the people they wanted to work with. (Page 215)
Peter Drucker said “Every organization needs one core competence: innovation.” (Page 216)
First, it’s critical to realize that an underlying dynamic in large organizations is that they are generally risk averse. This is not an accident— it’s because large companies have much more to lose than smaller companies, and it’s one of the biggest cultural changes that comes with success and growth. It’s also why it’s so much easier to innovate in a small company. So first and foremost, you need to realize that you will have to deal head- on with the many mechanisms that large companies put in place to protect what they have accumulated. Start by memorizing this paragraph. 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). (Page 217)
Learn how decisions are really made in your organization. Every organization is different. The key is to learn and accept how things get done in your organization. Don’t try to change the culture. If you want to succeed in your company, you’ll need to embrace it. Learn to love it. And be sure you look closely. Despite any formal decision processes that may exist, don’t be surprised if your company requires one key person (or a few) to buy off on any significant decision. If this is the case, at least you know who you really need to convince, and then you can work on the best way to reach that person. And you’ll need to learn how that person makes decisions, for example, does she base her decisions on a demo, or market data, or on customer commitments and testimonials? (Page 218)
Build relationships before you need them. If you prefer to go it alone, you might want to consider a startup, as large companies are all about people working with and depending on each other. You need to figure out all the people across the company that you might have to depend on to get your product designed, built, and launched. It’ll probably be a long list. But well before you need the help of these people, you should introduce yourself, ask how you can best work with them, and start getting them excited about what you’re working on. Try to figure out if there’s anything you can do to help them in their job. Make friends. (Page 218)
Long live skunk works. It really is easier to beg forgiveness than ask permission, especially in larger companies (see the point above about risk aversion). If you have a product idea, you can create a PowerPoint presentation and propose it through the proper channels, but it’s all too likely that the idea won’t go anywhere. However, if you take that idea— along with a few like- minded friends from across the company— and you flesh the idea out into a prototype, then if the idea is a good one, you’ll be stunned at how quickly the resources of the company will line up to help. Countless great products were launched this way. More on this point in the chapter on innovation, but for now, know that your idea will have a much better chance of getting traction if you can actually show the idea works, rather than just talking about it. (Page 218)
Just get it done. One of the great ironies of large companies is that even though there may be thousands of employees, it can often be impossible to get someone to help when you need them. Even when management is very willing and supportive, there may be no suitable resources available. In this case, you may need to get creative. You might, for example, be able to find some funding for a contractor, or call in some favors, or you might have to pitch in yourself. In a large company with formal processes and deliverables required, it may be easier to step in and perform the task or create the deliverable yourself rather than fight the process. I know of many cases where the product manager needed to help out with deliverables for customer support, sales training, technical writing, QA, engineering, and marketing. You have to be willing to do whatever it takes. (Page 219)
Pick your battles. The most effective people in a large organization have far more friends than enemies. Getting things done in a big company isn’t easy, and there will be many situations where you’ll have good reason to be frustrated, but you need to pick your battles carefully. Make sure you pick something worth fighting for, where the outcome truly matters, so that if any bridges are burned it’s worth it. And when you do fight, make sure you’re fighting for your product and not against another person. Try to bring the company along with you and not back your adversaries into a corner. You don’t want to win the battle only to lose the war. (Page 219)
Build consensus before important meetings where decisions are required. Always keep in mind than once someone opposes your position in a broad and public way, you have a major problem. It will not be easy for that person to publicly switch positions. In the long run, it takes much less time to build consensus beforehand when the outcome is important. In a large company, the main value of these decision meetings is for everyone to see everyone else in the same room indicate their support for your product or decision. So make sure that before any big meeting (or before sending out an important e- mail), you take some time to talk one on one with each person who will attend to ensure they have a chance to privately voice any concerns to you. You can then address their concerns directly, and get them on board and willing to indicate this publicly. (Page 220)
Be smart about how you spend your time. It is all too easy in a big company to get sucked into a week full of non- stop meetings. At the end of the week, you will have rushed from meeting to meeting and stayed up late trying to keep up with your e- mail, but you will not have actually done the things that will make a real difference to your product. Triage your meetings ruthlessly. Attend the meetings you must, but get used to trusting your colleagues to do their jobs and know that they’ll let you know if something really needs your attention. Most importantly, make sure you have the time during the week to work on the items crucial to the success of your product: your product strategy, your roadmap, the current prototype of the next release, your understanding of the competition and— especially— talking to actual users and customers. (Page 220)
Share information. Communication is hard in any organization. In a large company, however, communication is a serious challenge, and information becomes a kind of currency. Unfortunately, many people actually do treat it like currency, and hoard it rather than sharing it freely. Don’t take the view that information is power. You have more to gain by sharing it, and hopefully others will reciprocate and help keep you informed as well. So anything you can do to help your colleagues by providing useful information as soon as you get it is good for you— and good for your company. (Page 221)
Put your manager to work. In a large company, your manager can make a big difference to your success. Assuming your manager is reasonably well regarded, you should leverage his or her relationships, and use your manager to get a better understanding of the company and your management chain. Make it easy for your manager by doing your homework and providing the information he or she needs to make your case to others. Make sure your manager knows he or she can trust you talking to all levels of the organization. (Page 221)
Evangelize! In a large company, the need to evangelize never stops. You need to continuously spread the word, explain the vision and strategy, demo the prototype, and share customer feedback. Don’t underestimate the importance of this internal sales function. Make sure everyone even remotely connected with your product understands why the product is important, and how they can help. (Page 221)
Apple understands that the role of the hardware is to serve the software, and not the other way around. The software needs to know what the user wants the phone to do, so hardware technologies like multi- touch displays, and accelerometer and proximity sensors are invented to enable this. Every technology is there for a purpose. (Page 225)
The Software Serves the User Experience Almost every consumer company out there today gives lip service to the user experience, but Apple means it. Usability, interaction design, visual design, industrial design, are all front and center in the company’s priorities— and it shows. It may have taken two- and- a- half years to come up with the iPhone, but the team knew that it was all about the user experience, and they knew they had to move mountains to make the experience great. In addition, they had the talent and persistence at all levels of the company to make this happen. (Page 225)
If Apple has a secret sauce as a technology company, I believe it’s this: They understand better than anyone else the role that emotion plays in getting consumers to crave, buy, and love a product. They know how to create products that speak to these emotions in consumers. People are craving the iPhone. (Page 226)
A special is when a company gets a big check from a prospective customer or partner with the condition that you build into your product exactly what they say. (Page 228)
So what’s wrong with doing a special? One of the surest ways to derail a product company is to confuse customer requirements with product requirements. 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. (Page 228)
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. If a year from now the market changes, you need to be able to quickly change and adapt. If you are contractually obligated to keep supporting a specific way of doing things, then your business will not be as nimble as it needs to be. Remember that every version of your product will have to be built, maintained, tested, released, documented, and supported. It doesn’t take too many specials to weigh down a company to the point where it takes them months to do even the smallest release. (Page 228)
So how do you avoid the pitfalls of specials? Undeniably, it takes corporate discipline to be able to recognize specials for what they are and be willing to walk away. 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. Most customers do not want to be running on a custom version of software. They want to be running on your mainstream product— the one that gets the most attention, support and improvement. 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. And then have ready the names of a couple of system integrator/ solution provider companies that can tailor your product to meet this specific need. You may need to partner with the solution provider so that your customer doesn’t have to manage two relationships and have to worry about finger pointing if there are issues. (Page 229)
Many companies believe they need to create an entirely new market in order to do something big. The media helps fuel this. Everyone wants to know: “What’s going to be the next new thing?” 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. (Page 233)
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. (Page 233)
Remember: great product managers combine what is desirable with what is just now possible. Apple and Google understand this. Product opportunities exist everywhere, in virtually every market. But you must identify the need, and then search for new ways of applying technology to solve the problem. (Page 234)
First, as long as there are products that drive you nuts, there are opportunities for someone to do it better. How about a cell phone that doesn’t drop calls? How about a home computer that your parents can actually administer without your help? Second, what is possible is always changing. Just because something isn’t feasible today doesn’t mean it won’t be tomorrow. Third, today’s applications are tomorrow’s foundation. That’s how things work in our business. Initially, the browser was an application to look at some content on a Web site. Today the Internet is a foundation enabling applications like eBay, Skype, and PayPal. (Page 235)
The Role Of Emotion In Products I find it ironic that so many of us in the product world come from science- and business- oriented backgrounds, yet such a large part of what we do every day is really all about emotion and human psychology. Most of us may not think of our job this way, but we should. People buy and use products largely for emotional reasons. The best marketing people understand this, and the best product people ensure that their products speak to these emotions. (Page 236)
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). (Page 236)
Once you have clearly identified and prioritized the dominant buying emotions your customers bring to your product, focus on that emotion and ask yourself where else they might be able to get that need met? That’s your real competition. In many cases you’ll find that the competition you should be worrying about is not the startup or big portal that’s after the same thing you are, but rather the offline alternative. (Page 237)
In his book, Crossing the Chasm , Geoffrey Moore introduces the powerful notion of a technology adoption curve, comprised of innovators and early adopters, followed by the early majority, the late majority and, finally, the laggards. He goes on to explain how few products get beyond the early adopters (they fall into the chasm). (Page 239)
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? (Page 239)
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. (Page 240)
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. (Page 240)
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. (Page 241)
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. (Page 241)
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. (Page 242)
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. (Page 242)
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. (Page 243)
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. (Page 244)
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. (Page 245)
I think most would agree that the general state of Web site design is still in its infancy, at least as practiced by most companies. While there are some notable exceptions, many sites— even from major players— are often either very difficult to use, downright ugly, or both. (Page 246)
Two edge cases in particular struck me as interesting. On the one hand, so many graphic/ visual design firms have beautiful, artistic sites, that are difficult to read and poorly structured. On the other hand, many interaction design firms have very usable sites that are easy to navigate and find the info you need, yet are boring, primitive, and unappealing. (Page 247)
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. (Page 247)
Many teams feel that the visual design of a product or site is not really important. They argue that what matters is the functionality and the value proposition, and that things like nice colors, fonts, icons and layout are just unnecessary and superficial fluff. I strongly disagree with this view, and the more products I see, the stronger I believe in (a) the role that emotion plays in inspiring products, and (b) the direct role visual design plays in creating that emotion. (Page 247)
Below is a list of ten techniques that are especially important for large- scale consumer Internet service companies. (Page 249)
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. (Page 249)
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 chapter Personas for Product Management . (Page 250)
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. (Page 250)
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. (Page 251)
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. (Page 251)
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. (Page 251)
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. (Page 252)
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. (Page 252)
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. (Page 253)
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. (Page 253)
what I mean by the very general term enterprise software . The two key points to clarify are who the software is sold to, and what type of software product we’re talking about. Regarding who the software is sold to, the main point is that the products are sold to businesses rather than consumers. There is of course a full- spectrum of business size, and I’m intentionally not including the small office/ home office/ small business markets because, in my view, they’re really much more like the consumer market than the enterprise market (and the reason so many companies in the past tried and failed in the huge small biz market is because they didn’t realize this fact and its implications for product requirements). I do, however, include medium- size businesses in this definition even though many people reserve the term enterprise for a larger group such as the Fortune 500. But I find many of the challenges start to show with mid- size businesses. And then there’s the type of software. Enterprise infrastructure products (e.g., security software, systems management, and communications software) have some significant differences from enterprise applications (e.g., SFA, CRM, ERP), but I’ll speak to both here. (Page 255)
Here is a list of ten techniques that are especially important for enterprise software companies: (Page 256)
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. (Page 256)
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. (Page 256)
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. (Page 257)
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. (Page 257)
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. (Page 258)
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. (Page 258)
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. (Page 258)
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. (Page 259)
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. (Page 259)
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. (Page 259)
Here is how I characterize a product: People will pay for it; it delivers real and distinct value (and typically has its own SKU). Note that sometimes people pay by tolerating advertising, or by paying for support and not license fees, but one way or another they’re compensating the provider. It works well in multiple customer installations. The point here is that it’s not a special— this is not custom software. Your field and/ or channel can effectively sell it. You provide the necessary sales tools and sales training. Your company will stand behind it, providing support and adding improvements as necessary. Your customers and/ or channel and/ or services partners know how to install, configure and customize the product. (Page 261)
solutions product has all of the characteristics of a product above, plus: The software solves a business- level problem, often for specific industry verticals. The product may be based on an integration of one or more component- level products, which may come from your company or from partners, and they are pre- integrated. If appropriate, the product is certified with partners’ products as necessary (the customer needs to know the supported configurations). (Page 262)
But it’s also important to point out what a solutions product is not: A set of instructions for how to use an existing product in a new way (customer’s won’t pay for that) A set of customizations/ scripts from the field or other external source (not supportable) (Page 263)
also like solutions marketing over other forms of product marketing because solutions marketing: Speaks to the business- level problem, aligning products with business value Speaks to vertical industry segments, aligning value with a particular industry’s more specific— and sometimes regulated— needs. Showcases live customer success stories in action, in order to prove the business value Shows how to leverage products, professional services and business process knowledge or best practices to achieve business results (Page 263)
One of the most difficult— but highest leverage— types of product management is to define successful platforms. By platforms, I am referring to foundation software that is used by application developers to create end- user solutions. Examples include operating systems (e.g., Windows, MacOS, Palm OS), operating environments (e.g., Java, Flash), Web services (e.g., Amazon’s or eBay’s integration APIs), game developer platforms (e.g., XNA), and application- level platform runtimes (e.g., Facebook and Salesforce.com). (Page 265)
it’s important to point out what is not a platform. There are too many so- called “platforms” out there that are really just unfinished products. The team didn’t do the work required to provide a complete solution, so they market it as a platform and push the work off on the customer or a developer to finish. If you can’t program the platform through some form of API, and if you don’t have multiple commercial software products or services built upon your software, then you’re not a platform in the sense I’m describing. (Page 265)
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. Each of these three constituencies brings to the table very different needs and requirements. You simply can’t be a successful platform without meeting the key needs across all three. (Page 265)
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. (Page 266)
One of the biggest mistakes platform product managers make is in the prioritization of the three constituencies. Developers are the most vocal group and the easiest for the company to relate to, so they usually get considered first. The application provider is the one writing the check, so they come close behind. But the end- user is often so far removed from the platform provider that they rarely interact directly. Unfortunately, this is precisely the reverse of what’s needed. It is a big (but common) mistake to optimize for developers over the end- user. (Page 266)
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. You don’t have to look further than early Windows for an example of this. I’m not advocating platforms that make life miserable for developers, but product management is all about choices and priorities, and it’s essential to understand that the delivered application is what matters the most. (Page 267)
Support is also very difficult for platform providers. The bar is high because you’re a critical dependency for all of your customers. That said, the great thing about working on platforms is that they’re very high leverage— if you do it well, you can create a thriving ecosystem where you and your application provider partners succeed together. (Page 267)
In my more than 20 years of industry experience, I have observed many practices used to create successful and inspiring products— here are what I consider to be the 10 most important. (Page 270)
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. (Page 270)
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. (Page 270)
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. (Page 270)
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. (Page 271)
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. (Page 271)
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. (Page 271)
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. (Page 271)
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. (Page 271)
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. (Page 272)
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. (Page 272)
The strong product manager is constantly obsessed with the current and future state of her product. Here are the questions she is constantly asking herself: 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? (Page 273)
During the course of the past 20 years, Marty Cagan has served as an executive responsible for defining and building products for some of the most successful companies in the world, including Hewlett- Packard, Netscape Communications, America Online, and eBay. Before founding the Silicon Valley Product Group to pursue his interests in helping others create inspiring and successful products through his writing, speaking, and workshops, Marty was most recently senior vice- president of product management and design for eBay, where he was responsible for defining products and services for the company’s global e- commerce trading site. (Page 278)
