Tag Product Management

On Failure

I’m fascinated by the stories of company failures. For me (as I’d hope it is for most) it’s not professional jealousy but rather a opportunity to learn. Another plus -learning from the mistakes of others is a lot less painful than learning from your own.

Companies succeed through a combination of hard work, good luck and timing, but how does a well established company at the top of it’s game manage to lose it’s way?

Survivorship Bias is the theory that we tend to focus on success stories and not examine enough the ones that ended in failure. Alasdair Croll brought up a great example at a LeanUX talk I recently attended. As the story goes, during the Second World War the Allies studied the bullet hole patterns in returning bombers with the intent of adding additional armour to those areas. Then someone pointed out that these were the planes that made it back, and in fact what they should be doing is adding protection to the undamaged areas. Planes that suffered damage in these areas were the ones that didn’t come home, so their vulnerabilities weren’t studied.

So, to extend the analogy to business, let’s look at some former high fliers and see where they took the heaviest fire.  

When I was cutting my teeth in print design in the mid-’90s QuarkXpress claimed to have 95% market share of the graphic design/layout market. Quark and Photoshop were pretty much all we used. But through a series of compounding strategic mistakes, Quark opened the door for InDesign to completely take over the market. This excellent post by former Vice Magazine art director Dave Girard spells out Quarks downfall in great detail. It’s a fascinating story.

Once or twice a month, Daring Fireball’s John Gruber digs into a topic with a feature-length post. In Microsoft, Past and Future Gruber suggests that ‘Peak Microsoft’ occurred sometime around the year 2000, when Windows, like Quark, had 95% of the market for desktop operating systems. But signs that Microsoft has been unable to evolve to the new computing landscape, claims Gruber, are everywhere. 15 months in, Windows 8 sales are a third lower than Windows 7 during the same period. Chief architect of Windows 8 Steven Sinofsky, fired. Ballmer has stepped down.


As the Upton Sinclair quote goes; “It is difficult to get a man to understand something, when his salary depends on his not understanding it”. Gruber suggests Ballmer is guilty of this, not accepting how fundamentally the iPhone changed the landscape, not believing the sweeping change in how iPads and smartphones would create a post-PC market, and that Microsoft couldn’t capitalize accepting how fundamentally the iPhone changed the landscape, not seeing early on how iPads and smartphones would create a post-PC market, and later, his inability to effectively lead Microsoft through that change.



image credit: @lmanul

The open hostility of the various decisions at Microsoft is widely known. How this has affected Microsoft’s ability to innovate and respond to the market has rarely been better illustrated than a 2010 NYTimes Op-Ed by former MS VP Dick Brass. (read: Microsoft’s Creative Destruction)


“When we were building the tablet PC in 2001, the vice president in charge of Office at the time decided he didn’t like the concept. The tablet required a stylus, and he much preferred keyboards to pens and thought our efforts doomed. To guarantee they were, he refused to modify the popular Office applications to work properly with the tablet.

So once again, even though our tablet had the enthusiastic support of top management and had cost hundreds of millions to develop, it was essentially allowed to be sabotaged. To this day, you still can’t use Office directly on a Tablet PC. And despite the certainty that an Apple tablet was coming this year, the tablet group at Microsoft was eliminated.”

Consider that. Microsoft had a 10-year jump on Apple in building a tablet computer, and spent hundreds of millions of dollars doing so. And yet Microsoft’s top executives failed to address internal – INTERNAL – conflicts that doomed a project costing hundreds of millions of dollars to failure. Not only did they fail to manage the internal conflicts, they failed to grasp what these conflicts meant to the success of their project.


 Here is one of my personal favourite stories on this theme. Think of how absurd it is that Sony, dominant in electronics in the 70’s, and inventors of the ubiquitous Walkman cassette player in the 80’s, somehow missed the market for personal MP3 players. While Sony hardly qualifies as a failed empire, the story of how they fell from such a dominant position in the consumer electronics sector is fascinating, and it goes back to the loss of Sony’s Betamax format to the VHS standard.




Sony’s strategic mistake was to bet that Betamax’s superior picture quality would win the day, while the competing VHS consortium invested heavily in exclusive or first-rights content deals. Consumers voted for the more tangible benefit – better access to content – over the less tangible picture quality. Eventually Sony effectively exited the consumer VCR market (though the Beta technology continued to have a good run as an industrial format, where quality was an issue and pre-recorded content wasn’t).


Believing they had made a strategic mistake in not having control over a significant content library, Sony’s US division spent over $5B in 1987 and 1989 to purchase CBS records and Columbia Pictures. Sony’s goal was to use content as the carrot to encourage consumers to adopt new recording formats they had developed, including DAT and MiniDisc.


But neither format caught on with western consumers, and the significant library of content Sony had amassed became a millstone in how the company adapted to the rise of file sharing and the MP3 format, which undermined the ability to extract revue from content. Despite clear evidence that there was a huge market for a Walkman-like MP3 player to hold the billions of music files being shared by music fans, Sony muddled along with other manufactures developing MP3 players that held a couple of dozen songs at best. Adoption was hobbled by Sony’s DRM requirements – any songs you put on the device had to be encoded in Sony’s proprietary format.


Sony as a company was hamstrung by it’s unwillingness to allow it’s separate divisions to compete openly against each other. In fact, at one point during the Napster era, an association of major record labels (including Sony Music) launched a suit against multiple electronic manufacturers (including Sony Electronics). Sony was, in effect suing itself.


We own the market. Undoubtedly Quark, Microsoft and Sony made that statement repeatedly during the good times – and they were always wrong. A company does not control a market. A company with 95% share of a given market is only there by the grace of its customers. Should a better or cheaper competitor be successful at communicating its benefits to new customers, market share shifts, sometimes dramatically so.
Mobile phone design before and after iPhone introduction in 2007


The folly of these business empires is mistaking dominance for power. The automotive Big Three failing to respond to the superior quality of Asian imports. Blackberry for chasing new markets while failing to aggressively innovate to deliver new value to its existing customers. The music industry, for attempting to litigate out of existence a technology that customers clearly loved. Customers hold the power. They always have. A company that is not organized from the top down at ensuring they are responding to the market is an empire ripe for a fall.

The Hidden World of Experience Design

UK blogger and UX designer Peter Smart’s excellent post proposing an industry-wide rethink of the humble boarding pass is a perfect example of what is increasingly referred to as ‘experience design’.

There is no shortage of real-life examples of products and services we encounter every day that suck. Where product teams (which include designers) bring value to the companies we work for is in evaluating our products based on the experience of using them (see eat your own dog food) and working to improve the suck factors.

Experience design goes beyond typical product design by taking a broader view of how using the product makes you feel – sounds a little airy-fairy I know – but think about the last time you purchased something from an Apple store. Do you remember how it felt to walk out of a packed store with your purchase without wasting any time lining up at the cash register? By rethinking the retail experience by providing floor staff with handheld checkout terminals, Apple substantively changed how customers feel about the Apple store experience.

This is not the first time airline boarding passes have been called out for a redesign, but Peter Smart puts the key focus on usability and experience, not about simply cleaning up the design. Smart’s proposal also works within some very practical constraints: the boarding pass is still the same standard size and information is still printed in black ink. The little design touches – adding the destination weather at arrival time and leveraging the existing perforation so the boarding pass fits perfectly in a passport with just the Flight number and departure gate showing – those are the clever bits that make all the difference.


Jack Dorsey understands experience design. The co-founder of Twitter and CEO of payment startup Square recently spoke in detail about the mission of Square: not just to make payments easier, but to reinvent the experience of digital payments.

The biggest challenge with experience design is that we need to uncover parts of the customer experience that are often hidden – because we take them for granted. Status quo is the enabler of poor experience design. Boarding passes haven’t changed much in decades, and they function reasonably well. But if you fly often enough, you might re-imagine how a better boarding pass could make the experience better. Dorsey talks about coming at the experience design of Square from the perspective of a consumer, not a merchant, despite merchants being Square’s direct customers. Putting a lot of thought into what many would treat as an afterthought – the payment receipt – shows a commitment  to evaluate every customer touchpoint and make improvements that contribute to the overall experience.

As a digital product team we arguably have complete control over customer experience on the digital side of the business. At the Globe and Mail, where I work, we have roughly a million unique visitors each day navigating our web site on any number of devices, using one of our native apps, or signing up for a subscription service online. Every screen, menu and click is part of the overall Globe experience. Every detail is the result of the decisions we make, and collectively that defines the experience.

So sweat the small stuff. Details matter. Constantly evaluate every customer  interaction point, and rank improvements on a PICK chart. Talk to you customers regularly to understand their hassle maps. Incorporate grey label customer feedback tools like UserVoice or GetSatisfaction right into your digital products – believe me they will be a hundred times better, faster and cheaper than anything you could build yourself. I’m also a fan of Net Promoter as a simple, trackable metric of customer satisfaction – it will tell you if you are moving the needle in the right direction and give you verbatim customer feedback you might otherwise miss.

Experience design isn’t an entirely new concept – in some ways it’s no more than a new coat of paint on the old adage about the customer always being right. But with better tools to understand the customer experience and the ability to quickly deliver iterative improvement a on digital products, our ability to respond has never been better.

How Spotify Develops Products

Here’s something well worth downloading. Henrick Kniberg, an ‘Agile Coach’ at Spotify put together an extensive overview of the product development process the company uses (h/t @gmacgregor).

Spotify’s core product dev principals:

We create innovative products while managing risk by prototyping early and cheaply.

We don’t launch on date, we launch on quality.

We ensure that our products go from being great at launch to becoming amazing, by relentlessly tweaking after launch.

And 4 stages of product development:

Think It = figure out what type of product we are building and why.
Build It = create a minimum viable product that is ready for real users.
Ship It = gradually roll out to 100% of all users, while measuring and improving.
Tweak It = Continuously improve the product. This is really an end state; the product stays in Tweak It until it is shut down or reimagined (= back to Think It)

Regardless of how you or your company does product development, there is lots of worthwhile reading here.

Probably one of the biggest shifts in thinking is in getting away from working towards a launch date, and instead shipping when the product is ready. As detailed in the Ship It stage, this doesn’t mean endless development cycles trying to perfect every last detail (done dangerously, in the absence of actual users to validate your assumptions). The short goal is to produce an MVP 1 good enough to ship to a small percentage of users to observe and gather data to determine what refinements need to be made. The actual ‘Launch’ is the day you promote your product on the home page and the press releases go out, even though many of your users were aware of what you’ve been working on for some time. Isn’t putting out the right product (that works) far more important to the company than hitting a self-imposed internal launch date that none of your customers know about?

The second thing I think is traditionally overlooked is the commitment to the ‘Tweak It’ phase, which is particularly challenging if your organization is very project/budget focused. Managing commitment to ongoing improvements to active products is a tough nut to crack – certainly it’s much better if your organization has resources organized around products, not projects (as I’ve written previously).

Henrick has produces lots of great stuff on product development process and scaling Agile – here’s a YT vid on the role of the product Owner (hey – that’s me!) within an Agile team:

…and here’s a post on how to scale Agile within a large organization posted at Henrick’s own consultancy blog.


  1. Minimum Viable Product

Product-based development vs. Project-based development

A few months ago my director and I had lunch with a couple of colleagues from another big media company where I had worked as a product manager for a few years. They were interested in adopting Agile as a more nimble and cost-effective software development process, which is something the Globe and Mail started right around the time I arrived. The conversation brought me back to my previous role and the challenges of their ‘project-based’ development process.
In that world, projects would be identified and approved by senior management, assigned a priority and then handed down to the digital production team. Resources were organized as a matrix, so there was a design and UX team, a developer team, a platform team and so on. Sometimes a project manager would be assigned, otherwise the product manager would need to fill that role. The constant challenge was hanging on to your resources. If a higher-priority project came along and they need your designer, or developer or whatever, they got them, leaving you to scramble to fill the hole and keep your project on track.
It’s done differently at the Globe. In a nutshell, we have cross-functional Agile teams organized around products, so all the key components of the business – the publishing CMS, the video platform, community/social/comments, or advertising products (the newest product team, which I’m currently running) – have a dedicated Agile team responsible for those products.
The assignment of the teams is meant to be flexible to meet the needs of the business. If the organization finds it isn’t effectively addressing the inevitable site glitches and performance issues, it can reorganize resources to create a critical issues team. If you want to treat mobile not as a separate product category, but as an integral part of the editorial platform, then create a single team with mobile expertise that has responsibility for both web and mobile platforms.
But this is pretty obvious stuff. Agile is pretty much the new standard for software development, and if your company is not iterating on some version of Agile, you should probably find employment somewhere that is. The real advantage of creating product based teams is that the teams take ownership of the product. They stick with the platform and become the experts on its stresses, capabilities and potential. With the proper management structure in place, the broad, non-prescriptive business goals of senior management are communicated to the product teams, and the team members collaborate with business stakeholders to work out the best way to achieve those goals. Projects are scoped and budgeted based on estimates and technical input from the people who will be doing the work. When you’re handed a budget, a set of requirements and a delivery date without the input of the team doing the work, you’re probably in trouble (also see Iron Triangle).
Anyone working in digital knows the phrase ‘knowledge economy’ but too often the core of that idea is overlooked in how digital companies organize themselves. It’s been over a hundred years since Frederick Taylor published The Principles of Scientific Management, yet many (most?) companies are still organized around the idea that senior management understands exactly what needs to be done, and the manager’s job is to make sure the employees execute their tasks as efficiently as possible.
But in the knowledge economy, the power is reversed – or at least more evenly distributed. The keys to a successful product lie with the people on the front line – the coders, designers, your QA and infrastructure team. They have the actual expertise to execute, and the job of management is to empower them with information and the environment that they can execute successfully in.

Once your digital department exceeds a few dozen people it’s impossible for the people at the top of the org chart to know best to resolve technical problems or make the hundreds of UX decisions that go into a good digital products. The great idea or elegant solution is far more likely to come from a clever UW intern than your VP of Digital (something our VP of Digital surely would agree with). And the role of senior management then, is to communicate the business needs and create the environment where the experts on the platform can effectively figure out the solution. This is another area where Agile really excels – but we’ll leave the for another post.

Reading List:

Agile Software Development, Principles, Patterns, and Practices Robert C. Martin – a great all-round guide to the nuts and bolts of working with Agile.

Succeeding with Agile: Software Development Using Scrum Mike Cohn – more focused on how to adopt Agile within an organization. Essential for managers and up if your organization is adopting or thinking about Agile.