Remembering Microsoft's Zune: 4 Product-Planning Lessons for Entrepreneurs
Grow Your Business, Not Your Inbox
Come March, users who purchased Zune Marketplace music prior to its replacement in 2012 by Xbox Music will no longer be able to listen to those DRM files. (Fortunately, Microsoft will let users download non-DRM mp3 versions of their songs, at music.microsoft.com.)
Zune, launched just over 10 years ago, stands as one of Microsoft’s few true failures. Despite the tens of millions of dollars it spent across multiple marketing campaigns, Microsoft discontinued its line of portable media players after six sluggish years. Even in its heyday, Zune struggled to capture even one-eighth of the iPod’s market share.
Why did Zune, backed by the Microsoft tech juggernaut, fail to find its foothold? One problem was timing. When Zune debuted, Apple had captured nearly the entire mp3 market and would announce the first-generation iPhone -- which would lead the smartphone market to quash standalone mp3 players altogether -- just months later.
But unfavorable timing can be forgiven if your product offers new features that set it apart. And there lies the second problem that doomed Zune: It just wasn’t different enough from the iPod. Microsoft executive Robbie Bach, who headed Zune, later called it a “chasing” product, which, he said, gave customers little motivation to swap their iPods for Microsoft’s offering.
How could Microsoft have avoided this? How could any company now or in the future? The answer lies in . . . proper product planning.
Plan more prosperous products.
Before you build your technology product -- or any product, really -- take these four steps to avoid spending millions developing something customers don’t want:
1. Pick a problem.
The first challenge to a new product isn’t conceptualizing the product itself: It’s choosing a problem to solve. If you can’t articulate the customer pain point you want to alleviate, in one or two sentences, return to the drawing board until you and other stakeholders can.
At UnitedHealth Group, for instance, Unmesh Srivastava, director of innovation and transformation, understands that costs are a primary problem for healthcare consumers. “Every year, the United States spends trillions of dollars -- approximately 17.5 percent of its gross domestic product -- on healthcare expenses,” Srivastava told me recently. “To address crisis-level costs, our Optum Care program has introduced innovations in revenue cycle management, care delivery and healthcare-cost containment.”
The second challenge product developers face is not understanding whose problem the product might solve. A great invention with poor market fit might be a revolutionary discovery, but it’ll flop at release. Microsoft dug Zune’s grave by inadequately identifying a problem for Zune to solve. While Zune had some capabilities the iPod didn’t, potential users -- many of whom had already bought an iPod -- simply didn’t think the product addressed a pressing need.
2. Prototype an answer.
Although Microsoft prototyped Zune, it evidently didn’t do so adequately. If it had, Microsoft would have learned prior to release that consumers didn’t truly value Zune’s features. The company assumed they did, and that was its downfall.
There’s nothing like a prototype to ferret out risky assumptions. Create one before you begin the product's actual design or development, to level stakeholders’ expectations and limit scope creep. Once the prototype is finished, get it in front of target audience members to find out if it does, indeed, address the problem you identified earlier.
Yeti, my company, recently prototyped a user engagement app for PlayStation. By exploring different user flows and gathering feedback, we found that the prototype gave us the confidence and direction we needed to continue the product's development.
3. Match a market.
Prototypes don’t just put risky assumptions under the spotlight -- they also shine a light on the product’s market.
With Zune, Microsoft targeted the high end of the iPod’s market, hoping to capture users wanting more in a portable media player. Instead, interestingly enough, Zune displaced Microsoft partners’ comparatively low-end PlaysForSure devices -- effectively eating its own market share.
So, test your own prototype with various demographics. By learning exactly who might buy your product, you can learn more about these consumers' needs, forecast a price point and gain insights about marketing channels.
Use this information to plan future iterations: Prioritize features desired by the product’s primary users, and create a secondary list of features that might help broaden the product’s user base.
4. Construct a road map.
The final step in product planning -- road mapping -- is really a series of steps. Road maps focus vision and constrain actions, as product development proceeds.
Begin by creating an agile road map. This document will typically offer a one- or two-week plan for completing a product’s most important features -- those desired by individuals within the product’s primary market. Next, architect a release road map. By bundling multiple agile road maps, the release road map will plan for the next release and prescribe the agile sprints needed to get there.
Finally, develop a product life cycle road map. This long-term road map will shift over time to account for market conditions, business needs and user feedback. It’s comprised of multiple release road maps, mapping a product from ground zero to versions 2, 3 and so on. A product road map template can help you get started.
Every company, from entrepreneurial startup to corporate giants such as Microsoft, feels pressure to rush its products to market. First-mover advantage helps, resources are precious and profitability can’t come soon enough.
But when users don’t buy the product, being first won't matter; saving a few thousand dollars by moving up the release date won't matter. The only thing that will matter is whether customers believe your product solves an important problem for them better than other solutions on the market.
Zune may soon be gone, but for product developers, its lessons won’t soon be forgotten.