Chapter 4
THE FINE LINE BETWEEN SUCCESS AND FAILURE
The practice of product management may have its roots in Neil McElroy and bath soap at P&G, but that hasn’t prevented some of the highest-profile companies from creating doomed consumer products. You may remember some of these classic failures:
- New Coke was designed to compete with the sweeter-tasting Pepsi, but sparked such an outcry from loyal customers that it was promptly withdrawn and replaced by the original recipe.
- The Sony Betamax lost the feature war to VHS because it couldn’t fit a movie on a single tape.
- The Ford Edsel couldn’t live up to Ford’s sustained prelaunch hype, had a name that sounded like “pretzel,” and looked just plain weird.*
Or what about the stomach-churning mental associations caused by ill-advised brand extensions such as Bengay Aspirin (that familiar, scented pain relief cream—in my mouth), Life Savers soda (sickly-sweet liquid candy—yuck), and Frito-Lay Lemonade (mmm, salty potato chip goodness, but in a sweet drink)? Each of these wonders was presumably thought at the time by its respective owner to be the “next big thing” for the brand, and each failed miserably. The litany of failed products is long and populated by failures that range from the outright laughable—celery-flavored Jell-O;1 what kid (or self-respecting vegetarian) was going to eat that?—to the perversely tragic—in the 1970s and ’80s, lawn darts were a fun and popular outdoor game, but they caused thousands of disfiguring injuries and three deaths before the Consumer Product Safety Commission eventually banned them.2
Consumer products have a notoriously high failure rate because their success requires mass-market appeal. They generally have to sell in very large quantities to offset the high costs of research and development, approval, and distribution for sale. This makes me glad that I work mainly with software products; in many respects they’re much simpler to bring to market. In chapter 2, we looked at the Segway as a textbook example of a solution in search of a market problem. It failed to fulfill the original vision for the product for several common reasons: like the Ford Edsel, it couldn’t live up to its hype; it was not needed by as large a segment of the market as its creators thought; and the creators neglected to check their assumptions, the main one being that it would be legal to ride. If we could just perform more effective, up-front research, perhaps the percentage of products that fail—the statistics for which vary wildly from one in three to nine in ten3—would be drastically reduced. But as the case of New Coke showcased so glaringly, the painful fact is that sometimes even extensive market research and product testing lead us astray. Coca-Cola had conducted two hundred thousand consumer taste tests to confirm that their new formula tasted better than classic Coke, but they had failed to appreciate the bigger picture of consumer devotion to the brand.
Schadenfreude over “What were they thinking?” failures is almost irresistible, and every product manager has his own list of favorite flops. Among my personal favorites is the attempt by French ballpoint pen manufacturer BIC to introduce a terrifically patronizing range of pens branded “for her,” leading to some of the most amusingly sarcastic reviews ever written on Amazon.4 I also still chuckle about Coca-Cola’s doomed attempt to introduce Dasani water to the UK. Right from the start, things went badly. Dasani’s advertising inadvisably claimed the product was full of “spunk,” the meaning of which in the UK is quite different from in the U.S. (referring to a bodily fluid generated during a certain “spunky” activity between couples, which shall not be named here).5 The press had no end of fun with that. Then a spokesperson let slip in an interview that the water was actually purified, remineralized tap water. That sounded somehow perverse. The final nail in the coffin was the revelation that some of the supplies had been contaminated with the chemical compound bromate, which is suspected of being a carcinogen.6 The PR damage was done. Dasani lasted just five weeks in the UK before being withdrawn.
Every product manager should know that failure is always a possibility, even with the most brilliant product concept and engineering. Just think again about that comparison of Segway and Glass and how hard it is before launch to determine whether a product like Glass will take off in the mass market. In this chapter, keeping in mind the lessons learned about assessing consumer demand and working effectively with the product team, we’ll first take a look at an additional set of the most common ways in which product creation goes off the rails. Sometimes the key problems are not so much in the initial assessment of what the consumer needs, but in bringing the product to the right market at the right time, ensuring it will be profitable, and orchestrating a polished and coordinated launch. Although the product manager can never entirely control the whole product process, and no product manager can ensure success, no matter how experienced she is or how remarkable her knack for knowing the market, we do have a core set of practices with which we can do the best possible job of keeping the process of development and launch on course.
As mentioned before, there are many established frameworks for the product management process, each with its own best practices and formula, but in my experience, no two companies I’ve worked with have followed these methods in exactly the same way. That’s why, as I’ve been doing throughout this book, I’ll introduce the fundamentals rather than presenting a methodology to follow slavishly. In my experience, it’s best for product managers to cherry-pick the right tools for a given company and job. The good news is that you will be able to employ the basic practices I’ll be covering here irrespective of the framework you’re using. And if the product doesn’t manage to navigate to the right side of the fine line between success and failure, when you’ve applied these practices, you, your team, and higher-ups will know that the failure wasn’t due to your simply allowing the wheels to fall off.
I started the chapter by referring to a set of notorious packaged goods failures. Well, the world of software products has its own special repository of unfortunate releases, and while some of them seem to have been clearly destined for consumer rejection right from launch—Apple Maps comes readily to mind—others have more complicated reasons for failure. Let’s take a look at the most common reasons that products fall flat, with a special eye to some issues that are specific to software development and launch.
THE WHOLE PRODUCT MUST BE READY
When you think of the quality of a product, it’s important that you think about not just the product your development team has built, but the whole product in the Crossing the Chasm sense, meaning the associated customer services, partners, and distribution channels as well. An otherwise perfect launch can be ruined by just one aspect of the whole product experience failing—this is why it’s so difficult to get right. If you think about it this way, there are many ways in which a product can end up falling well below the required standard. It might be that the product only goes partway toward solving the desired problem, or the design is confusing to customers, or the product has been rushed out the door prematurely before the company, partners, and distributors are ready, or it still contains many defects. Time pressure can arise if the company sets itself a deadline (arbitrary or otherwise) and refuses to be flexible with it. Embarrassing premature launches can also happen if the company is too focused on responding to its competitors’ movements, rather than having the confidence to hold on until the product is ready for release.
Apple Maps was a perfect example of this, and a rare launch misfire for the company. Despite initial coziness—Google’s then-CEO Eric Schmidt had been on Apple’s board at one point—relations between Apple and Google had become strained since Google released Android. Steve Jobs was livid, accusing Google of stealing Apple’s ideas and saying he was going to “destroy Android.”7 The sticking point was that Google Maps had turn-by-turn navigation on Android, but not on iOS, and Google wasn’t in the mood to give away one of Android’s key advantages.8 So with the release of iOS 6 in September 2012, Apple removed Google Maps from its App Store and replaced it with Apple’s own software. However, as it soon became clear, Apple Maps had been rushed out the door and was far from ready. Landmarks like the Golden Gate Bridge were misplaced by miles, the Brooklyn Bridge looked like it had melted,9 and trusting users were lured onto airport runways10 and into the Australian desert.11 The app had failed in its primary task—to help its users navigate accurately from point A to point B—so a few months later, Apple had to backtrack and allow Google Maps back into the App Store, whereupon Google’s product became the most popular download overnight.
But wouldn’t you consider Apple Maps to be a minimum viable product? Aren’t MVPs just substandard products rushed out to market? Well, no, not if you’re doing what you’re meant to. If you remember, the key word is viable, by which we mean commercially viable. The product may solve only one small problem for a small niche market in a basic way, but it should still solve that problem completely; customers should be willing to part with hard cash for it to solve that problem.
Maps was a high-profile failure of product quality and uncharacteristic of Apple’s usual attention to detail, but we see this exact problem happen time and time again with other companies. Either the core product itself is subpar, or a good product is let down by a painful whole-product experience. First impressions matter—don’t rush a launch if the whole product is not ready.
MISSING YOUR WINDOW
While there’s no benefit in rushing something out before it’s ready, dawdling longer than you have to before entering a market can also be a sure path to failure, particularly if the market is a short-lived fad. Equally, jumping late into a well-established market is a little like diving into shark-infested waters—you’ve got to have a pretty serious advantage tucked away to survive for long against all those experienced competitors. While you’re holding back, perhaps still plowing through a backlog of requirements that long ago ceased to be “must-have” for launch, your competitors will be launching more minimal but perfectly acceptable products that satisfy the market needs better than your nonexistent product. Or you may find that you’ve been in lockdown for so long building your product that when you finally emerge, blinking, into the sunlight, your customers’ needs have evolved and your new product is already obsolete. It’s one problem to enter the right market late, but it’s an entirely different problem to pick the wrong market to enter in the first place. The market itself may be going away: you don’t see many developers rushing to build native BlackBerry apps, for instance.
Thinking back to the Kano model, you’ll remember that over time, distinctive delighters become linear satisfiers, then baseline features. This means a late-entry product must do more from the outset just to be permitted to compete in the market; differentiation from competing products will be more difficult, and commoditization means profit margins will be tighter. It’s always a better idea to find the clear water of niche markets in which only your product can compete, even if only to begin with.
Keep a sense of urgency when planning to enter a new market. You don’t necessarily have to be first, but you certainly don’t want to be last. Be ruthless about initially delivering the minimum set of product features required to satisfy a basic market need completely, then learn from the feedback and iterate quickly to improve in the right areas.
STRETCHING OUTSIDE YOUR EXPERTISE
Many companies have tried to extend a brand farther than it should stretch—recall the attempts to sell consumers Life Savers soda and Frito-Lay Lemonade. In the computing products terrain, think of the Facebook phone. This isn’t to say that brands don’t have to extend into new areas, but they should do so by growing their expertise. Of course, this is much easier said than done, and sometimes companies just have to get into a new business and polish their expertise as they go. Microsoft is a good case in point. Its first-generation Surface tablet was largely a market failure, but the company made improvements for the next generation, and the Surface 2 was better received. It was important for Microsoft to build its consumer products business while the home PC market declined, and this was a calculated effort.
But you can also misstep badly if you naïvely attempt to enter a market too far removed from your company’s area of expertise. Such initiatives often end up as distractions from your core product strategy and stretch resources and investment as you set about learning how the market works. There’s a good reason most big players enter new markets by acquiring smaller, specialist firms—as Apple did with both iTunes and the iPod, and as Microsoft did with Nokia: it’s the quickest way to gain niche market expertise, albeit a more costly option.
MAKING A FLAWED BUSINESS CASE
While a business case for your product will never be an exact predictor of the future, you should still be wary of models that depend on an unreasonably high sale price for mass adoption in the market or, conversely, indicate slim or nonexistent profits. You might recall the example earlier of Iron Mountain’s “successful” backup service that lost money on every customer. Poor execution on the product delivery meant a crucial data compression feature was omitted, which in turn raised the operating costs sufficiently to negate the profit margin. A similar problem can arise if the sales team or retailers lack confidence in the product and are unable to articulate its value to different market segments or if competitive pressures result in a price war.
Another potential pitfall arises when even moderate success will be insufficient. If your business case relies on achieving exponential growth for the product to be considered a success, it’s going to be much harder to achieve the high rate of customer acquisition needed. When thinking about the business model for your product, pay attention to the factors that may have the most impact on your profitability. Build three business cases: the best case (every variable factor is in your favor), the worst case (the reverse), and the most likely case. If the difference between best and worst cases is vast, there’s still too much variability and risk in your model. Similarly, if only the very best case is profitable, pay attention to the red flag this presents.
Model the best, worst, and most likely cases…
… and watch out for red flags like slim profitability. (Courtesy of Jock Busuttil)
WHAT WE HAVE HERE IS A FAILURE TO COMMUNICATE
One of the reasons product management is such a pivotal role in an organization is that without it, there would be no one who both appreciated the respective challenges and needs of each department and was responsible for actively sharing relevant information with all of them. People are rarely comfortable admitting they don’t understand something, which is often why the building of good software is a mysterious process to many business executives. Products fail as a result of poor internal communication, when the left hand of an organization is unaware of what the right hand is doing—and has no interest in finding out. You must therefore speak frequently with all the different departments involved in the planning, creation, and delivery of your products. This can be one of the truly difficult parts of the job, because some people on the team may be reluctant to apprise you of problems they’re running into and others will resent you for asking. As we discussed in chapter 3, if you’re not communicating effectively across the company, the wheels will begin to fall off as each department starts diverging and doing its own thing rather than following the product plan. Not sure who you need to be talking to? Grab a company directory and cross your own name out. That’s your list.
Meet with each team frequently enough that you can gather timely intelligence from them, keep them informed about relevant upcoming dates and product milestones, and ensure that any problems they have with the product—or indeed any problems they’re causing—can be rectified before they blow up into something altogether less convenient. For some teams, this will mean a meeting every month; for others it may mean weekly or, in times of crisis, even daily meetings.
As we saw with the launch of Dasani’s water in the UK, products can also fail as a result of ineffective or ill-judged external communication, whether through advertising, public relations, or social media. Ideally, the PR specialists you work with should be diligent enough to understand the product and its benefits, to tailor international launches to avoid embarrassing cultural gaffes, to coordinate messages across all communication channels, and to target the right messages to the right audiences. It’s also a good sign if the launch campaign does not rely solely on the success of PR to sell the product, with budget available for other initiatives to promote the product not just at launch but later in the product’s life as well.
To ensure a coordinated launch, make it your responsibility to prepare all the departments and partners involved in advance. Provide them with relevant information, in the form they need, at the right time to use it. It’s also your job to whip everyone into a frenzy of excitement and expectation, which peaks with the launch of your product. (Just enough hype, though—you don’t want the grand unveiling to be an embarrassing anti-climax, as befell Segway.)
LEARN FROM YOUR SUCCESSES
With the odd exception, like that of the Maps app, Apple has always been annoyingly good at product launches. When it launched the first iPad, the company sold one million units within the first twenty-eight days. More tellingly, it had also made sure the whole product was ready for launch: from the ecosystem of five thousand iPad apps already available, customers made twelve million downloads and bought 1.5 million ebooks from the iBookstore within the same period. And if you’re thinking that the iPad launch success was due only to the product being a game changer, think again.
Looking at the iPhone’s performance over the years, it’s clear that Apple is good and getting better at launching product updates as well: This improvement was not due purely to the acquisition of new customers. Apple was able to drive 77 percent of its day-one sales of the iPhone 4 from existing iPhone customers seeking an upgrade. I’m deeply envious—it’s every product manager’s dream to see his product fly off the shelves so quickly after launch. Then again, not every company is as good at preparing for a product launch as Apple. Apple is successful because it readies its people across the globe and coordinates all the moving parts for a single coherent and well-executed launch event.
Product Model: iPhone
Release Date: June 29, 2007
Launch Figures: 1M in 74 days
Launch Countries: 1
Average Sales per Day per Country: 14,000
Product Model: iPhone 3G
Release Date: July 11, 2008
Launch Figures: 1M in 3 days
Launch Countries: 22
Average Sales per Day per Country: 15,000
Product Model: iPhone 3GS
Release Date: June 19, 2009
Launch Figures: 1M in 3 days
Launch Countries: 8
Average Sales per Day per Country: 42,000
Product Model: iPhone 4
Release Date: June 24, 2010
Launch Figures: 1.7M in 3 days
Launch Countries: 5
Average Sales per Day per Country: 113,000
Product Model: iPhone 4S
Release Date: October 14, 2011
Launch Figures: 4M in 3 days
Launch Countries: 7
Average Sales per Day per Country: 190,000
Product Model: iPhone 5
Release Date: September 29, 2012
Launch Figures: 5M in 3 days
Launch Countries: 9
Average Sales per Day per Country: 185,000
Product Model: iPhone 5S and 5C
Release Date: September 20, 2013
Launch Figures: 9M in 3 days
Launch Countries: 11
Average Sales per Day per Country: 273,000
Sources: Piper Jaffray; AppleInsider; Apple.
Apple may make it look easy, but in practice a successful launch can be very difficult to orchestrate. I’ve found you can boost your chances of success by making a checklist of things that each internal department, your customers, and the partners will need to know and when. It won’t be a short list. Naturally, these items will be specific to your own company, so work with your teams to create the list you need. Keep your launch checklist at hand and review progress at least weekly as you approach the launch date. Then, before the launch, assess how prepared your company, customers, partners, and target market are for the forthcoming launch by verifying whether they’ve digested the information you’ve sent out. You could also check with your distributors or sales team to find out how many preorders have been taken. After your launch, the data you’ve gathered will allow you to analyze the rate of sales, the proportion of existing customers upgrading, and the effectiveness of different channels to market, so you can repeat your success and improve your performance for next time.
CUSTOMERS AREN’T READY OR WILLING TO UPGRADE
A particularly challenging issue with software is that nothing ever stands still. We have to constantly contend with technological innovation in the ecosystem of products our product depends on or is designed to complement. We end up releasing an updated version of our product either to take advantage of a new opportunity or to respond to a significant change. But while we may become accustomed to change, our customers may not be so willing to move with the times. Even if you’re shipping desktop or server software (as opposed to cloud-based web apps), eventually the operating system version on which your product runs will go away, and, in extreme cases, if you haven’t stayed up to date the cost (and practicality) of porting ancient software to a new operating system may be prohibitive.
I once observed this very problem firsthand at a software supplier whose few remaining mainframe customers (mostly banks) had finally gotten around to upgrading their systems. They soon discovered that the original software didn’t run on the new mainframe server. Although the software had lain untouched all these years, the customers had been paying for software maintenance throughout and so requested an updated version from the supplier. The complication was that the supplier had unwisely gambled on the customers’ glacial pace of change and made its entire mainframe development team redundant several years earlier. The company no longer possessed the technical knowledge in-house to update the software in question. The options available were to lose the mainframe customers (expensive—particularly if they requested a refund for all those years of pointless software maintenance payments), to migrate the customers onto a working version of the software on a different operating system (impractical for the customers), or to find and recruit the necessary developers to update the software (time-consuming and costly). In the long run, the gamble of ignoring the customers stranded on the old version of the software (while the maintenance payments continued to roll in) had most certainly not paid off.
There are often perfectly sensible reasons why a customer may not want or be able to move up to the latest version every time you release. As Microsoft found out when they launched Windows Vista, aside from the user interface annoyances12 and initial lack of support for printers and other peripherals,13 the real killer of widespread adoption—particularly in the lucrative corporate market—was Vista’s significantly increased hardware requirements over its predecessor, Windows XP. When deciding whether to upgrade everyone’s desktops and laptops, corporate IT departments were having to factor in not just the operating system license costs, but also the wholesale costs of replacing aging machines with higher-spec hardware.14 With IT budgets squeezed, the vast majority elected to skip Vista entirely when it was released in 2006 and wait until Windows 7 appeared. Several years later, over a quarter of users15 were still clinging to XP right up until Microsoft finally killed it off in April 2014, possibly because the prospect of upgrading to Windows 8 was just as unappealing.
The timing of upgrades can be a major hurdle for some organizations. Rather than making changes as needed, the more risk-averse restrict major hardware and software alterations in their data centers to specific and relatively infrequent windows of opportunity. Some organizations have quarterly change windows; others have them annually or even less frequently, causing the changes needed to pile up in advance of each window. This often results in a highly complex upgrade process that requires weeks (if not months) of costly planning effort to execute correctly. So the controls these companies put in place to mitigate the risk of large changes can themselves cause the very problems they’re meant to prevent.16 If your customers have this kind of change management process in place, they’re likely to take your product upgrades far less frequently than you release them, and so will need to make much bigger upgrade leaps each time. Correspondingly, any end-of-life schedule you create for your software may need to factor in the lead time needed before an appropriate window of opportunity opens up for your customers to perform their product upgrades.
You might think that cloud-based products pose less of a problem. After all, rather than each customer having their own separate copy of your product, everyone uses your central system, which you host and can update as you please. Well, not quite. Centrally hosted cloud services may make concerns such as the customer’s operating system largely irrelevant, but you’ll probably still need to have some concept of versioning as you continue to evolve your product. The convergence of web technologies to common standards may have made it easier to support multiple web browsers with a single product version, but at some point you’ll want to make a significant change that will force you to decide whether to drop support for an outdated browser with idiosyncratic behaviors or continue to support it with a lower-tech version of your product alongside the more advanced mainstream version. Or perhaps you’ll need to retire a feature entirely because it’s preventing you from reworking some other aspect of your product. On the plus side, at least you’ll be able to monitor directly who’s using which feature with which browser and use that information to help you decide what to do.
A trickier problem arises when your customers are integrating directly with an application programming interface17 (API) you provide. Think of your product’s API as being the common language spoken by your product and your customers’ systems, with the different functions the API provides being like the vocabulary. When you need to make a change to an existing function, it’s a bit like suddenly deriding to substrate one wurzel for an apricot.* (Ahem.) Quite confusing, you’ll agree. So it shouldn’t be surprising that your customers’ willingness to upgrade their integrations when you release a new version of your API will depend on how deeply they’ve integrated their systems with yours. You end up back at square one: you have to support multiple versions of your API in parallel until you can encourage your customers to upgrade their integrations to use the most recent version, and you still need to decide how long you’re going to continue to maintain those older versions. Even cloud products need an end-of-life schedule.
One final gem of a reason why customers may refuse to upgrade to the latest version: discovering some salesperson has invented and sold them an “enterprise support contract” (committing the company to perpetual support for a particular product version), netted the sizable commission, then quit the company shortly thereafter before anyone realized what he’d done. As I learned the hard way, that makes for a fun day at the office.
YOUR CRUFT CATCHES UP WITH YOU
end-of-life /
nd 
v l
f/ v. to discontinue; drop; decommission; put out of misery; send to sleep with the fishes; take round the back and shoot; send the way of the Norwegian Blue.
Product managers are full of contradictions: if we’re not busting our asses to launch something, we’re trying to kill our older products off. It may seem a little abrupt to leap straight from product launch to end of life, but the two go hand-in-hand. Like Apple with its iPhone customers, you ideally want your customers to move up to the newest version of the product, so for every major launch you need to be encouraging laggards to upgrade so that you can safely kill off the older product features or versions. But as we saw with Microsoft’s launch of Windows Vista, this is easier said than done. It’s important not to let the challenge make you complacent about identifying products that ought to be put out to pasture. Retiring a product is just like launching a product in reverse; much of your process and communication for orchestrating a successful product launch can be reused. And when you do need to put a product down, there are ways to do it humanely.
Many software companies have an annoying habit of accumulating “cruft.” Cruft is that unpleasant mixture of dust, fluff, and other detritus that gathers in the corner of your sofa, underneath the cushions. It’s also a fairly accurate description of all those legacy features or versions of your products that accumulate over time and are equally troublesome to get rid of. It is important to have a regular cleaning schedule to prevent the chronic buildup of cruft. In product terms, this means having a defined, published end-of-life process.
The key to a successful end-of-life program is transparency. If you’re open with both internal stakeholders and customers about your plans to decommission products, there will be no unexpected surprises. And if everyone knows what’s going to happen, they’ll (hopefully) be more likely to accept progress as the status quo and fall into the routine of planning for it. It’s therefore a good idea to determine how your end-of-life policy will work and share that with your customers. It doesn’t need to be particularly complex; it just needs to clearly set out the mechanics of when and how you will retire products.
If you have several products that release new versions on a regular, periodic basis—perhaps you push out updates to your customers automatically—you may want to define a rolling end-of-life policy so you only ever have to support and maintain a small number of the most recent versions. This kind of rolling schedule could look something like the next figure.
A rolling end-of-life schedule (Courtesy of Jock Busuttil)
In the diagram, when a major new version of a product is released, the version two releases ago moves into a six-month phase-out period and then is decommissioned. The advantage of this method is that your customers should always know that new releases automatically trigger older versions to move into the end-of-life process. Alternatively, if you release a relatively small and manageable number of products, or update them infrequently, you may want to retire them at your discretion. If you do adopt the latter model, its inherent unpredictability will make it much more important that you ensure your customers receive adequate warning to plan their upgrade.
THE SECOND ALBUM PROBLEM
Particularly for startups, another common problem is meeting high expectations set by a first product with the next product. Many successful startups suffer from the tricky “second album” problem. Like a breakthrough musician whose first album came out of nowhere and captured the mood of the moment perfectly, a startup may have had a first product that solved a market problem so neatly, and at just the right time, that in retrospect it is difficult to see how it possibly could have failed. Then it comes to the second product, but in the intervening time, a few things have changed about the company. For one, it’s no longer a startup. It’s an established business with a large, paying customer base to keep happy and a whole bunch of staff in formal departments, whereas before it was a ragtag handful of people all collaborating in the same room. The cofounders are busy dealing with their investors and advisors, perhaps debating whether to float the company publicly. They’ve lost touch with their roots, their market. They no longer inhabit the same world as their users, so they no longer have that direct source of insight that led them to hit the nail on the head with their first product. This is usually the point at which they conceive of their second product. As with the breakthrough musician who’s left her roots behind for high-profile gigs, interviews, and parties, the follow-up simply lacks authenticity. Or, in product terms, it’s based on the flawed assumption that the cofounders are still in tune with the sentiment of their market. And since the expectations of the market were raised by the first product, the follow-up product not only has to resonate with the audience, but also has to be even better to meet those new expectations. It’s no wonder that the second product (or album) is often a let-down.
That’s quite a daunting set of problems to watch out for, and of course it’s not exhaustive. There are many more ways for a product to fail than there are products. So the question is, how does a product manager keep on top of all of these things, make sure the development and launch are proceeding apace, and avoid pitfalls?
BEING AGILE
Traditional product development employed a “closed-box” approach that offered little insight into progress and typically could only sacrifice quality, as both time (i.e., money) and the scope of requirements were set in stone. The process was understandably stressful for the hard-pressed development team, who often had the unappealing choice to either fail against the criteria set by senior management or deliver substandard products. In contrast, Agile development offers stakeholders a more granular and transparent view of progress, and offers the development team the flexibility to hit deadlines while maintaining quality, as long as the scope is left to the best judgment of the product owner. The stress of meeting deadlines is therefore shouldered by the product owner, but she is empowered to manage the team’s work to allow a timely delivery. “Good enough to launch” doesn’t have to mean “build everything, including the kitchen sink.”
One of the most common styles of Agile product development is Scrum, which is explained succinctly by its creators, Ken Schwaber and Jeff Sutherland, in The Scrum Guide.18 Product manager and Agile coach Roman Pichler describes the main differences between the traditional (“Old School”) and Agile (“New School”) methods of product management on his blog:19
Old School: Several roles, such as product marketer, product manager, and project manager, share the responsibility for bringing the product to life.
New School: One person—the product owner—is in charge of the product and leads the project.
Old School: Product managers are detached from the development teams, separated by process, department, and facility boundaries.
New School: The product owner is a member of the Scrum team and works closely with the Scrum master and team on an ongoing basis.
Old School: Extensive market research, product planning, and business analysis are carried out up front.
New School: Minimum up-front work is expended to create a vision that describes what the product will roughly look like and do.
Old School: Up-front product discovery and definition: requirements are detailed and frozen early on.
New School: Product discovery is an ongoing process; requirements emerge. There is no definition phase and the product backlog evolves based on customer and user feedback.
Old School: Customer feedback is received late, in market testing and after product launch.
New School: Early and frequent releases together with sprint review meetings generate valuable customer and user feedback that helps create a product customers love.
In Scrum, a product is developed over several sprints. A sprint is a time-boxed period of development, usually a month or less but always the same length, during which a potentially releasable product increment is created. The product owner is a specific role within Scrum, usually played by the product manager, that is solely responsible for determining which items go on the sprint backlog, a list of discrete, specific, and bite-sized pieces of work for the product. For each item on the backlog, the product owner and development team together describe in user stories how and why the intended user persona needs to interact with the product. Together they also score the relative complexity of each user story in story points. Backlog items are intended to be small items of work because those are easier to estimate and complete than one massive piece of work (an epic—so-called because it’s a very large user story). The product owner ensures the team tackles the highest-priority items first by placing them at the top of the backlog. Scrum establishes a routine for the development team that makes sprints predictable and allows the developers to focus on what they do best—building product. As you’ve hopefully noticed by now, a product manager has a variety of responsibilities, of which being the product owner is but one, so good time management is needed to avoid having the product owner role take up all your attention.
Once your development team has settled into its routine (or cadence), you can measure its velocity each sprint as a means of predicting when a product will be ready. Velocity is simply a measure of how many backlog items the team can implement in a given time, as measured by totaling the story points of the items completed. You may find, as I have, that the more frequent release of incremental product updates can mean that nobody (neither your company nor your customers) notices their arrival. It’s therefore a good idea to make a bigger splash (a formal launch) every now and again to draw your market’s attention to the improvements you’ve made, even if they’ve already been released into the wild and particularly if there’s a coherent story or theme behind a group of improvements. If you know your team can generally do about twenty story points’ worth of work in a two-week sprint, and you know there are roughly sixty points’ worth of work outstanding that must be done before you can make your big-splash product announcement, then you also know that your launch is roughly six weeks away, all things being equal. This approach assumes you’re not changing the development team members around each time and that they’re reasonably good at estimating story points (which they should be after a few sprints).
Bear in mind a couple of important points. It’s natural for velocity to vary a little from sprint to sprint, so think of it more as a rule of thumb than a to-the-minute-accurate predictor of product delivery time.20 Also, Agile processes tend to focus on providing detail on short-term activities (current and next sprints at most), so you won’t have detailed estimates for far-off items. This approach is sometimes known as horizon planning. It saves you time in the long run because your plan is continually evolving as you learn more about your product and market from incremental releases, so there’s no point in planning far ahead in more detail than is necessary.
PRIOR PREPARATION AND PRODUCT PLANNING PREVENT POOR PERFORMANCE
Your overall product strategy is the combination of many different activities with short-term, medium-term, and long-term focuses, such as determining future product requirements based on your ongoing market research or reviewing pricing strategy in light of changes to the market and competitor activity. You can zoom in on each of these activities and find more detail—for feature requirements you might be thinking about the user personas they apply to, breaking epics into smaller user stories, and guerrilla testing your assumptions with a few customers and a quick product mockup before you move into developing them.
There are many different activities competing for a product manager’s attention. (Courtesy of Jock Busuttil)
Seeking Out Lightbulb Moments
Another day, another fire to put out—it’s all too easy to get lost in the day-to-day tasks. But your market research is never done. One of the best ways to be blindsided by product problems is to hide at your desk and fiddle with spreadsheets and documents all day. The foundation of good product management is to get out there and talk to people. With the crush of work from managing internal stakeholders and the ongoing development process, one of the biggest challenges for product managers can be finding the time to escape to speak to the market regularly. You need to keep on with your wide-angled research by listening to the challenges faced by potential and existing customers, partners, suppliers, and regulators, in some cases; you should always be on the lookout for clues that may lead to good, new product ideas. But you should also be taking the opportunity to focus on validating the more specific assumptions you’re making about products already under way—does this feature or that process work as intuitively and smoothly as users would expect?
There’s no hard and fast rule for how often you need to get out there, but if you can manage to have at least a few decent conversations each week, that will increase your likelihood of experiencing “lightbulb” moments. These are the moments that highlight that you’ve been thinking about the market or your product in a particularly constrained way without even realizing it—like in cartoons, the metaphorical lightbulb illuminates above your head. Lightbulb moments are immensely positive experiences because they expand your world view and open up a wealth of creative options that you’d previously not even considered. The more lightbulb moments you experience, the better.
Then, to close the feedback loop, periodically test your thinking. There’s a saying that you only truly understand something when you’re able to explain it to someone else. So go back to your market and internal stakeholders with what you’ve learned to check whether you’re on the right track. You could write articles for your company’s blog and seek feedback; you could run seminars in person or online; you could engage in conversation with your market on social media or on relevant discussion groups. There’s really no excuse these days for failing to present and discuss your ideas on a regular basis. Your objective is to pinpoint the ideas that will form the bases of potential new products or features. You can simply add new features low down on your product backlog until further investigation raises their priority. For new products, I recommend using a tool like the Business Model Canvas,21 shown in the next figure, to structure your thoughts quickly without the need for a lengthy business case document.
The Business Model Canvas (Courtesy of Business Model Foundry AG)
In order to achieve the right flow of new ideas, I’d recommend you aim to research and present at least one new idea each month. Making time for such regular presentations may seem impractical, but it’s important to keep in mind that if you hide indoors while a current suite of products is in development, you won’t be learning anything new and you’ll almost certainly miss a change in the market or competitors for the products you’re working furiously to launch.
Communicating Your Product Plan with a Roadmap
If the features are the “what” of the product, the roadmap is the “when.” Your product roadmap serves a number of purposes. At its most basic, a roadmap is a communication tool for coordinating different groups of people. Just as a GPS unit guides you while driving to avoid traffic, your roadmap will be an invaluable aid to guiding your product’s progression around unexpected holdups. This is why it’s so important for there to be a degree of flexibility in the plan to allow for items being delivered later (or sooner) than expected—circumstances change. If you give people an idea of what they can expect from your product in the future, they’re able to plan their own related activities around it. Your development team will need to know what’s coming up in the medium to long term. The design decisions they’re making now may depend on the direction in which your product’s heading. They might need to hire people with specific skill sets if, for example, you’re planning to introduce a new iPhone app later in the year. In much the same way, other teams within your organization will need to plan ahead to prepare for a major product release.
With all its various audiences and their differing information needs, a roadmap has to be a reasonably high-level view of how the product will evolve over time. You could use your roadmap to highlight both when new features will arrive and when it will be possible to address a new market segment. You can think of your roadmap as the story arc of your product, with major themed product releases being like chapters of a book, development sprints like sections, and individual product requirements like paragraphs, all consistent with your overall vision. But unlike with a book, you only need to worry about filling in the detail for a chapter or two at a time. Things change, not least because you’re continually learning from the market, so there’s little point in planning a release in detail for two years from now. Once you have your roadmap as a high-level timing guide allowing each team within your company to plan ahead, you can dive into the detail needed to satisfy different teams’ processes on the more immediate items. You might have a roadmap item to introduce a native iPhone app, so as that item approaches you will need to supply much more detail than the roadmap provides: user stories and mockups to the designers and developers, benefits and features to the marketing team, pricing and licensing details to the sales team or partners, and so on.
Some roadmaps have specific dates on them and read a little like Gantt charts. If you’re bound by very specific deadlines—perhaps your product needs some special certification, assessed only once a year, before it can be sold—this can be a perfectly reasonable approach. In other situations, such as in a startup, your primary constraint is money, rather than time, so you strive to do as much as you can before the money runs out. Ideally, the guiding factor for releasing a product should be when it’s ready. But if you’re time bound, when progress is behind schedule and it’s coming down to the crunch, remember that you’ll have to start sacrificing features from scope (or quality—not recommended) to keep to the deadline. If you’re working in an Agile way, you should have a reasonably good idea of how quickly the current development sprint is progressing, and your sprint backlog will already have the most important requirements at the top of the list to be done first. Mind the Product cofounder Janna Bastow provides a similar roadmap as shown in the next figure in the form of an Excel template.22
Not everyone agrees with the time-based approach to roadmapping, which may seem bizarre; after all, isn’t roadmapping about planning how long products will take to develop and when to launch? Veteran product manager and former space engineer Simon Cast points out in his blog post “Roadmapping Without Dates” that by setting such firm dates, you can shoot yourself in the foot.23 Estimated dates have by nature a degree of variability, and product managers recognize that fact, so the point at which a specific date is added to a roadmap is also the point at which everyone except the product manager believes the item in question will be delivered. It doesn’t matter how you caveat the date (“It’s a plan, not a promise”), it becomes gospel. Suddenly, you are judged by whether you meet the entirely fictitious dates, and that judgment doesn’t take into account changing priorities or potential holdups.
A time-based style of roadmap (Courtesy of Janna Bastow, who provided a similar roadmap as a simple Excel template: “Tame Your Roadmap,” Mind the Product, September 27, 2011, http://www.mindtheproduct.com/2011/09/tame-your-roadmap/)
Cast describes how ProdPad, the company he cofounded with Janna Bastow, started with the date-based approach but later moved to a no-dates roadmap divided into less specific timings: current, near-term, and future.24 This approach can often require a change of corporate mindset in much the same way that Agile product development does.
Product management tools such as ProdPad will generate these kinds of no-dates roadmaps for you. (Courtesy of ProdPad)
Of course, you do need to have a long-term destination defined for your product, along with a rough idea of when you expect to arrive there, but if you can work with more flexibility this way, you are better able to change course and make adjustments as may be needed due to market changes or development bottlenecks. New information will often become available and priorities will change, so you’re going to have to review your roadmap at least every month to adjust course if necessary.
When Correcting Course, Tell People
If you do need to change the route midway, make sure there’s a good set of reasons for doing so and write them down. Flexibility and good decision-making are far more important than clairvoyance (or blind luck). Test the assumptions you’re basing your decisions on as quickly as possible to reduce risk without sacrificing your agility in the face of change. Then always be sure to come up with a new plan, rather than just raising a red flag that there’s a problem. Update your stakeholders, customers, and partners on what’s coming up, why it’s important for them, and when it’s coming. It doesn’t necessarily matter if things move around on the roadmap as long as everyone is kept up to date, and those who need to know why things have changed understand the reasoning. There’s a beautiful example of a customer-facing roadmap over at FreeAgent that allows people to vote on the features they’re interested in; note that it has no dates, either—items are listed simply as “At Depot,” “En Route,” or “Delivered.”25
Bear in mind also that the more complex your ecosystem of dependent partners and customers is, the more warning you need to give about changes. If, for example, hundreds of customers and partners have integrated your product directly into their own systems, arbitrarily changing it without warning in a way that would break their integrations would not make you flavor of the month. It’s vital that you be sure you’re giving sufficient warning to the people who will be affected most by roadmap changes and that you confirm they’ve understood the implications. It’s also useful to measure their reactions to forthcoming items as a sense check—are they in favor, dead set against, or simply not interested either way? What you learn will inform how you prioritize future items on your roadmap, but remember that you can’t please all of the people all of the time—compromises and sacrifices are sometimes necessary.
AVOID EPIC FAILURES BY PRACTICING SMALLER ONES
There’s a reason why trainee pilots start out by repeating hundreds of takeoffs and landings: those are two of the riskiest parts of the entire flight. They both demand a high cognitive workload that is only increased by poor weather conditions, and if something goes wrong with the aircraft at these crucial times, there are precious few seconds for the pilot to react to and deal with the situation safely. So pilots practice and practice and practice. Then they practice some more. They practice engine failures immediately after takeoff, when the aircraft doesn’t even have enough height or speed to turn back to land on the runway, and they practice landings without engines or working flaps or radios. They do this not because the likelihood of any or all of these things happening is high, but because the consequences can be so dire. Rather than avoiding the riskiest elements of a flight, pilots take those elements of risk and meet them head-on.
Working as a product manager in technology is—thankfully—almost never a matter of life and death. This, however, can make us complacent. One way to avoid this danger—which can lead to unexpected surprises when a product goes badly off the rails—is to regularly simulate failures. Eric Ries’s Lean Startup methodology speaks of “failing fast,” the idea that if you’re uncertain whether your idea’s going to work, it’s better to find out quickly and cheaply. Such controlled failure gives us the opportunity to learn how to recover quickly from a failure and, ideally, how to avoid making the mistake in the first place. You only need to roll out a poorly tested release on a Friday evening once to learn that customers don’t appreciate a weekend’s disrupted service. But if you’re regularly practicing your process for rolling back a flawed release, then it’s far less of a problem to manage when it ends up happening for real.
Some product people even provoke failure in their live systems as a way to present more opportunities to learn. Google has teams of people devoted to exploring innovative ways to bring down their own services on the basis that if someone’s going to try it, their preference is that it’s a Google employee rather than a cybercriminal. Netflix, the online TV and film streaming service, has gone one step further and created a piece of software called the Chaos Monkey that deliberately knocks out components to test their automated disaster recovery. Cory Bennett, a senior software engineer at Netflix, and Ariel Tseitlin, former director of cloud solutions at Netflix, introduce the Chaos Monkey:
In most cases, we have designed our applications to continue working when an instance goes offline, but in those special cases that they don’t, we want to make sure there are people around to resolve and learn from any problems. With this in mind, Chaos Monkey only runs within a limited set of hours with the intent that engineers will be alert and able to respond.
Failures happen and they inevitably happen when least desired or expected. If your application can’t tolerate an instance failure would you rather find out by being paged at 3am [sic] or when you’re in the office and have had your morning coffee? Even if you are confident that your architecture can tolerate an instance failure, are you sure it will still be able to next week? How about next month?26
HOW TO RESPOND TO A CRISIS
No matter how much we practice failing, there’s no way around the fact that some snafus are inevitable. When the worst does happen, we have to think fast to figure out how to resolve the problem. We can end up panicking ineffectually rather than falling back on our training and reacting calmly. But we don’t have to live in fear of failure—or of taking risks. In The Power of Habit Charles Duhigg describes NASA’s response to failing:
Some departments at NASA, for instance, were overhauling themselves by deliberately instituting organizational routines that encouraged engineers to take more risks. When unmanned rockets exploded on takeoff, department heads would applaud, so that everyone would know their division had tried and failed, but at least they had tried. Eventually, mission control filled with applause every time something expensive blew up.27
A crisis—literally a “turning point”—can also be an opportunity in disguise. (However, I would hasten to add that the oft-cited meme that claims the Chinese word for “crisis” is made up of the words “danger” and “opportunity” is complete bunk.28) It presents you with the chance to demonstrate your true colors by the way you perform under pressure. Furthermore, sometimes only a crisis can disrupt the equilibrium of a company stuck in a habitual rut, permitting positive change to occur. Later in The Power of Habit, Duhigg describes how repeated surgical errors at Rhode Island Hospital became a catalyst to overhaul safety procedures in 2009, improving staff relations and reducing the “wrong-site” errors rate to zero in the process. (Wrong-site errors are situations in which the surgeon operates on the wrong side or site of the body.) He also explains how the tragic 1987 fire at King’s Cross station allowed London Underground to break down the silos of bureaucracy in order to make passenger safety its primary concern.
So how should you respond to a crisis? First and foremost, keep your head while all about you are losing theirs. You can expect a great deal of managerial pressure on you to act. Keep your nerve. Knee-jerk reactions and snap decisions will lack sufficient information and be likely to exacerbate the problem. Instead, take control of the situation by making yourself its owner; ultimately, most people want someone to take the heat from them, so they will be more than happy to relinquish responsibility to you. Overcommunicate throughout: If you’re investigating something, explain what and where it is. If you’re testing a potential fix, detail who’s running the test and when you’ll know the outcome. Provide your bosses with such frequent updates—even if only to report no change—that they beg you to stop. Remember that in the absence of information, people make up something to fill the void, and it’s usually wrong. Avoid the blame game, as it’s never constructive, and instead focus on figuring out the immediate cause of the problem and rectifying it. In doing so, you may uncover a deeper malaise that will need longer-term attention, but put this to one side for now.
Once you have a potential fix for the problem, test it first; there’s nothing worse than raising people’s hopes for a resolution only to dash them soon after. Roll out the fix to a small segment of those affected as a further test; you don’t want to start a different fire inadvertently. When you’re satisfied that you’ve solved the problem without significant side effects, roll out the fix to everyone else. Then pull together the people from the disciplines involved whom you’ll need to resolve the underlying problem permanently. Again, avoid the blame game. Was it a one-off or a systematic problem? What do you need to start or stop doing to prevent it from happening again? If you can’t prevent it, how can you receive earlier warning when the problem is still in its incipient stages? Ensure that the necessary improvements are implemented as quickly as possible; wait too long and the collective pain will subside, meaning people will lose the impetus to change. It’s a little like how parents teach young children not to do daft things and hurt themselves; the lesson can only be learned while the scuffed knees still ache.
Sometimes people misunderstand the Lean concept of failing fast as giving them carte blanche to try out lots of different things really quickly (good), but in a haphazard, scattergun manner (bad) and without learning from each failure (worse). As Marc Andreessen said in an interview with the Wall Street Journal,
This whole thing where failure is somehow good in Silicon Valley, or failure is OK, or failure is wonderful, or failure is part of the process, is just a bunch of nonsense, and is actually a destructive sort of meme because it gives people an easy excuse to give up. If you look at a lot of the great successes in corporate history and in technology, they required real determination and real staying power.29
I can understand the sentiment Ries is trying to convey by using the word failure: taking a risk is not, in itself, a bad thing; fear of failure should not stop you from having a go anyway. However, some people can’t get past the word because they’ve been conditioned to avoid failure at all costs, when really all it represents is the concept of invalidating a hypothesis or demonstrating with evidence that a held assumption was false. So maybe instead of failing fast, it’s better for us to think of learning fast. You’re only going to fail for sure if you learn nothing as you go along.
As I’ve mentioned before, product managers’ ability to absorb knowledge is one of their most important traits, and this ability includes learning from mistakes. I was once interviewing candidates for a senior product manager role and was listening to one candidate tell his backstory of how he’d driven his previous company into the ground by forsaking all his other customers to risk everything on a single massive deal that never came through. When I asked him what he’d do differently next time, he replied, “Nothing.” He didn’t make it to the second round. Even in failure, there should always be something you can learn that will allow you to improve for next time. While describing Google X’s rapid prototyping process for Glass, Tom Chi explained how he told his team to think not in terms of failing, but in terms of learning:
I don’t believe in failing fast. Failing is just an approximation of learning. You can fail a lot without learning at all. And you can learn a lot without failing at all.… Don’t tell me this experiment failed or that experiment failed, tell me what was the twelve percent that worked.30
There may be a fine line between success and failure, but you can choose to step over the line on your own terms. And when things do go wrong—and they will from time to time—your training and experience will enable you to be the one calm head and voice of reason in the room. That’s what being a product manager allows you to do.