- March 18, 2009
- 4 Comments
No, this isn’t really an article about the 3.0 release of iPhone software. Not really.But there is a good article about it right here(its a good read). Its really about what we can learn from it. In version 3.0, Apple added 100 or so features to the iPhone OS, and 1000 developer APIs. What were these features you ask? Here’s a few of the ones that will likely draw snickers:
- cut and paste
- MMS messages with more than one picture
- Landscape view for basic apps (mail, notes, calendar, etc.)
- Opening .ics files
- Supporting calendar.dav protocol (calendar sharing)
- Push notification
Why the snickers? or yawns? Because these are largely features that other smart phones have supported for the last 2 years (since iPhone 1.0 came out).
Why would Apple put off these seemingly critical, unavoidable features? Why is Apple adding them now? What can we learn from this, that we can apply to our BPM (or indeed any) projects?
First, consider that Apple could have included all of these features in the first release – and either delayed the iPhone by presumably 6 months to a year, or Apple could have included these features in the first release, and perhaps sacrificed the features that really made the iPhone different and desireable.
Consider had Apple released iPhone 1.0 without multi-touch, without coverflow, without the touchscreen interface for virtual keyboards… would the iPhone have been a big hit? What if, in iPhone 2.0 software Apple had released these features *instead of* the App Store for the iPhone. Would we have 25,000 applications we can install? Would there be 50,000 developers registered for the iPhone? Would the iPhone seem so relevant, so useful?
Ok. hopefully you’re with me on my line of reasoning. Apple made the calculation that creating something significantly different and BETTER in some respects, would outweight the shortcomings on some of the basics in other respects. Based on rate of adoption of the phone, I’d have to say they made the right call.
In the old days, Microsoft used to do this, and in the industry jargon we called it “super subsetting” – meaning, I have provided a subset of the spec or the de-facto spec (no copy paste!), but I am providing a “super-set” set of features that no one else provides (in MSFT world that might be tight integration with Microsoft Office applications – in the iPhone world, it is multi-touch and the App Store). Without the super-set features, you can’t generate the demand for your product. Once you have demand, you have revenue. Revenue makes it easier to invest in your product. In all aspects of your product.
Thus, to the second question. Why add these features now? Because the differentiating features have proven out. Its now time to capitalize on the wide adoption by adding convenience and removing objections that existing and potential customers cite. Take away some of the competitive ammunition now that you actually have a measurable share of the market.
Soon the iPhone will look like a strict super-set of the other phones in terms of capability, with the other vendors scrambling to get their own application stores together, but lacking critical mass behind these stores to make them vibrant (with possible exception of Android’s application store). Keep in mind there is significant development cost to build these features and make sure they are quite robust. And yet, with 30 million iPhone OS devices on the market, the development costs now probably look quite modest relative to the revenue streams. Whereas, up front, these costs would have looked quite large relative to zero revenue so far.
To the third question: What can we learn? When building a BPM solution, we are often integrating with and replacing parts of legacy systems. Often one of the first requirements from the business will be that the new system does everything the old system did in order to be accepted. This is generally a bad false start to a project.
However, one of the best tactics is to figure out what the 2-3 key NEW capabilities your solution will bring to the business that are so compelling that some minor discomfort over less important details will not derail the project. You can call this marketing, but it is truly understanding where the real value opportunities are in your project.
Sometimes these capabilities are things the users will clamor for, sometimes things that the management team will clamor for, and rarely, things that IT will clamor for. Make sure that at least one of your major stakeholder groups is squarely behind a few of the wow features of your BPM project. If you don’t have that excitement in one area, my experience is that you’ll find uncomfortable scrutiny on an exact comparison of the new solution versus the old solution. Moreover, before you invest in “trueing up” your solution with all the old solution’s bells and whistles – you’d like to know that the big rocks – the major goals you are attempting to tackle with BPM – are getting addressed!
Once you *know* that those goals are being addressed, then you can go back and invest in the more mundane, but expensive, build out. This could all fall under the heading of focusing on the highest value parts first. But in reading about Apple’s 3.0 release, I couldn’t help but put it into a BPM context…