The Cost of Apple's Approach to Product
- July 19, 2010
- 7 Comments
In a previous post, I argued that (contrary to Alain Breillatt’s expert perspective) Apple’s approach to product actually saves money rather than “wastes” money. What most people would look at as waste, I would look at as costly-wrong-turn-avoided. If you understand the arguments behind technical debt or process debt, the idea that a bad design (or more than the minimum necessary number of designs) is expensive makes perfect sense. This argument was an exercise in looking at the R&D process around one future product – the 10:3:1 ratio of product design weed-outs, for example. In another post, we looked at the big picture R&D spending versus revenue and profit growth – and in this wide angle lens, it is hard to argue with the idea that Apple’s R&D is quite efficient.
Recent events and a few good blog posts bring some additional data and perspective to bear on this. First, we have the Tyner Blaine post, The High Costs of Building the Wrong Product, which is a fantastic explanation of the concepts discussed between myself and Alain Breillatt. As Scott Sehlhorst writes for Tyner Blaine:
There’s an analog to the market dynamics of making poor product decisions – executing with poor quality. Many research studies and articles have identified the market impacts of poor quality. This has become so well accepted that people today cite it like a law of physics (one example here based on this 1988 IEEE research by Barry Boehm and Philip Papaccio) as the “1-10-100 rule.” The primary conclusion of that research is that ten dollars spent on fixing bugs:
- Costs and saves $10 when you catch (and fix) the bug during implementation.
- Avoids $100 in costs when you catch the bug during QA and send the product back to development (then test again).
- Avoids $1,000 in costs versus waiting until your customers catch the bug in the field, causing the team to remedy the problems, rush out a patch release, and/or go to heroic lengths to manage a PR problem.
This is an opportunity in front of your product team – a 100x payback from investing in quality during the development process. Of course, be pragmatic about it – if the cost of testing exceeds the cost of bugs, don’t test.
We just recently witnessed the cost of a “bug” in the final version of a very popular product. Apple has taken it on the chin in PR because of this. Imagine the launch coverage absent this issue – the press and blog coverage would have found something to complain about, but this issue was almost too easy for them to focus on.
Now, imagine that Apple had developed, say, one of the many bad Android phones. There are Android phones that review well. But had Apple wasted the resources to build one of the ones that wasn’t good – that is quite a cost, isn’t it? To reputation for one. But there are marketing costs, support costs, potentially recall costs (analysts were estimating north of $1B in recall costs to Apple if it came to that). The Droid X is already getting criticism for its bad User Interface (allegedly, worse than the default Android 2.1 interface – though I don’t claim to be an expert on that). What is the cost to Moto’s business to develop “a bad product” or, a product with a few really bad bugs? People often compare Apple to “Android” – but actually each Android handset maker is a separate competitor. Each one has to invest significant energy into developing their handsets. As long as Apple has significant volume advantages over any single competitor, they should enjoy economies of scale that the other manufacturers don’t.
TechCrunch has an excellent article detailing Apple’s surprising vertical integration benefit. I say surprising, because in economics we’re generally taught that vertical integration is less efficient than specialization. Apple seems to buck that trend. Steve Cheney writes:
Perhaps the best example of this so far is FaceTime, Apple’s take on video-calling. FaceTime makes video-calling on the Android-based Sprint HTC EVO look silly, because the EVO awkwardly requires users to sign up and download a third-party app, then launch it every time they want to talk. Normal people simply won’t do this.
Apple eliminated this friction by innovating at the confluence of hardware and software—hit one button mid-call and the feature just works. It really is amazing (yes, I am channeling Steve Jobs).
Once Apple does release a product, they really know how to market it. In this FaceTime ad compaign, they do a great job of not marketing technical specs and instead marketing human value. This is what makes the difference between evangelizing your product and just geeking out. Not every body likes it – but think back to when the iPod commercials were ubiquitous. They didn’t market the # of songs so much, nor the quality of the build (though it was high), nor the RAM, nor the CPU speed. They marketed people dancing in their heads while going about their every day life (the shadows are dancing while the person calmly walks to the subway). Sell the benefit, sell the humanity.
Back to the TechCrunch article… the author argues that Apple actually benefits from feature bloat in component vendors. For one, they get to strip out unnecessary features from their designs (which aids battery life, for example). For another, Apple gets an inside track view of what is coming down the pipeline in these components that their competitors depend upon. And then Apple has degrees of freedom to decide how to respond.
Good food for thought for anyone running a product business.