Roadmaps and overreach

8. Roadmaps and overreach

Many of the challenges faced by Symbian in its early years can be directly traced to the circumstances of the birth of the company.

In these early days, in our urgency to secure agreements with potential investors and licensees, we conveyed, consciously and unconsciously, an overly optimistic impression of our ability to deliver important new pieces of functionality. That over-optimism was probably necessary to get the company off the ground in the midst of lots of doubt and apprehension. However, as I’ll explain in the chapters ahead, the subsequent delays in delivery schedule caused our investors and licensees to impose significant changes in how the company operated. In turn, these changes actually diminished the effectiveness of the development organisation, putting further strain on the company. It would be several years before the key twin goals of predictability and high velocity could both be met.

There were two aspects to our over-optimism in 1998:

  • Conscious re-spinning of our story, to downplay known risks, and to highlight possible upsides, even though we understood these upsides to be stretch targets
  • Unconscious wishful thinking, which caused us to be more optimistic than the facts allowed, and prevented us from honestly considering the probabilities of various outcomes.

On reflection, we were unduly influenced at the time by the then-fashionable concepts of “lock-in” and “switching costs”:

  • We feared that, once a manufacturer committed to a competing smartphone operating system, and invested lots of time and money becoming familiar with it, they would be inclined to stick with that system, despite any dissatisfaction they were experiencing; the perceived costs of re-tooling with a new smartphone platform would dissuade the manufacturer from switching
  • We hoped that, even though a manufacturer might be disappointed in what Symbian initially delivered to them, the “lock-in” inertia would persuade them stay in the relationship long enough that they would, in due course, create successful products, and be happy with the outcome.

We particularly wanted to avoid companies making significant commitments to Microsoft platforms. At that time, Microsoft still had an aura of invincibility: it would get things right “by version 3, or thereabout”. To prevent any such commitment, we sought hard to sign companies to Symbian instead.

In retrospect, it’s clear that we gave too much credit to the concepts of “lock-in” and “switching costs”:

  • Companies did show themselves capable of switching between smartphone operating systems; they would typically commit to more than one at the same time
  • The experience of feeling let down, by delays in Symbian deliveries, had long consequences: companies no longer viewed Symbian as a reliable, trustworthy partner; instead, they they set about micro-managing our delivery processes.

For example, years after, while talking informally to senior managers in Japanese phone manufacturers, I heard bitter complaints: they insisted that Symbian executives had categorically promised to them that Symbian would deliver particular functionality by mid 1999, but there was no sign of the promised functionality when the time came. How dreadful. How… un-Japanese.

The first Symbian roadmap

Platforms live and die via their roadmaps. The roadmap should make it clear:

  • Which features will be delivered at particular times in the future
  • Which features will be delayed to later releases.

Customers base their own planning on their best understanding of the platform roadmap:

  • Which features they can safely rely on the platform to deliver, at a particular time
  • Which features they may need to source separately, to match their own product plans.

Attempting to deliver everything at the same time is a recipe for disaster. The platform team needs to have sufficient confidence to explain to customers that, in fact, various desirable items are being de-prioritised from the next release, but will be included in subsequent releases.

Prior to the formation of Symbian, the same principle had been followed in the delivery of the software for Protea (the Series 5 PDA):

  • The initial release of the software – at first known as “ROM 1.00” – just contained the minimal set of on-board software for the device
  • The PC connectivity software and messaging/web applications were explicitly delayed to later releases, occurring roughly three months and six months later, respectively
  • Another very substantial chunk of additional software – the EPOC implementation of the Java runtime – would clearly take longer to create, and would therefore be a key part of a projected future release, along with other desired enhancements to the Protea software, such as outlining in the Word Processor, sort in the Spreadsheet, and some completely new apps such as the “Jotter”.

Various ideas for the best representation of the EPOC roadmap came to a head in the run-up to the formation of Symbian.

[ SNIP ]

Recent Posts