Posts Tagged ‘platform’
Today’s WSJ has a book excerpt about the demise of RIM/Blackberry. It is a fascinating story but also has a core lesson for product managers (including myself) which is the lesson of “don’t forget all the parts move”.
While hindsight is always 20/20, when you are faced with a potentially disruptive situation you have to take a step back and revisit nearly all of your assumptions, foundational or peripheral, because whether you see it or not, they are all going to face intense reinvention.
In disruptive theory we always talk about the core concept that disruptive products are better in some things but worse in many of the things (tasks, use cases, features) that are currently in use by the incumbent product. This is the basis of the disruption itself. In reading the excerpt it is clear that out of the gate this reality was how the RIM executives chose to view the iPhone as introduced as targeting a different market segment or different use cases:
If the iPhone gained traction, RIM’s senior executives believed, it would be with consumers who cared more about YouTube and other Internet escapes than efficiency and security. RIM’s core business customers valued BlackBerry’s secure and efficient communication systems. Offering mobile access to broader Internet content, says Mr. Conlee, “was not a space where we parked our business.”
There’s a natural business reaction to want to see a new entrant through the lens of a subset of your existing market. Once you can do that you get more comfortable doing battle in a small way rather than head-on. You feel your market size will trump a “niche” player.
The problem is that such perspective assumes a static view of the market. You’re assuming that all the other attributes of your implementation will remain advantaged and the new competitor will fail to translate that single advantage into a broader attack.
What happens, almost all the time, in technology is that disruptive entrants gain ecosystem momentum. There’s a finite bandwidth in the best people (engineers, partners, channel) to improve, integrate, promote products. Once the new product appears compelling in some way then there’s a race to gain a perceived first mover advantage. Or said another way, the leaders of the old world were already established and so a new platform yields a new chance to a leader. There’s a mad dash to execute whether you’re building leather cases, integrating line of business systems, or selling the product.
When I read that first quote, I thought how crazy to think that the rest of the internet, which includes email and messaging, would not race to try to establish new leadership in the space. The assumption that everyone is sitting still is flawed. Or just as likely, many of those incumbents will choose to assume their small part of the blackberry world will move ahead unscathed.
In a platform transition, everything is up for grabs. If you’re the platform you have to change everything and not just a few little things. First, no matter what you do the change is still going to happen. It means that you don’t have the option of doing nothing. Once a new platform gains momentum and you start losing your partners (of all kinds) or can no longer attract the top talent to the platform you have seen the warning sign and so has everyone else.
As Blackberry learned, you can’t take the path of trying to just change a few things and hope that taking what you perceive as the one missing piece and adding it to your platform will make the competitor go away. You can see how this worked in the example of the Storm device introduction, which aimed to add a bigger screen while maintaining the Blackberry keyboard feel. In other words, the perception was that it was the screen that was the thing that differentiated the device.
The browser was painfully slow, the clickable screen didn’t respond well in the corners and the device often froze and reset. Like most tech companies launching a glitchy product, RIM played for time. Verizon stoked sales with heavy subsidies, while RIM’s engineers raced to introduce software upgrades to eliminate Storm’s many bugs. “It was the best-selling initial product we ever had,” says Mr. Lazaridis, with 1 million devices sold in the first two months. “We couldn’t meet demand.”
Storm’s success was fleeting. By the time Mr. Balsillie was summoned to Verizon’s Basking Ridge, N.J., headquarters in the spring of 2009 to review the carrier’s sales data, RIM’s senior executives knew Storm was a wipeout. Virtually every one of the 1 million Storm phones shipped in 2008 needed replacing, Verizon’s chief marketing officer, John Stratton, told Mr. Balsillie. Many of the replacements were being returned as well. Storm was a complete failure, and Mr. Stratton wanted RIM to pay.
Of course we know now that there were many more elements of the iPhone that changed and it was no single feature or attribute. Every platform shift involves two steps:
- Introduction of a new platform that does some new things but does many existing things in a suboptimal way.
- Evolution of the new platform to achieve all those old scenarios but in new ways that often look like “hey we had that back then”. For example, consider the rise of secure messaging, mobile device management, and new implementations of email. All of these could be viewed as “Blackberry features” just done in a totally different way.
That’s why all the parts are moving, because everything you ever did will get revisited in a new context with a new implementation even if it (a) means the use case goes unanswered for a while and (b) the execution ends up being slightly different.
On a personal note, I was a Blackberry user from the earliest days (because our team made Outlook and the initial Blackberry was a client-side integration). When I saw the iPhone I was one of those people fixated on the keyboard. I was certain it would fail because I couldn’t peck out emails as fast as I could on Blackberry. In fact, I even remember talking about how Windows phones at the time had touchscreens so if that became popular we would have that as well. That summer, I waited on line to pick up my iPhone and was convinced of the future in just a few minutes.
You would have thought I would have been prepared. Previously, I had experienced a similar lesson. I had yet to be convinced of the utility of the internet on a phone, which the iPhone too solved. Of course my lens was clouded by the execution of the phones I used most (Blackberry and Windows) and the fact that the internet didn’t want to work on small screens and without Flash. I would visit Japan several times a year and see the DoCoMo i-mode phones and was a big skeptic—my friends from Japan still make fun of me for not seeing the future (by the way, at that time SMS had yet to even gain traction in the US and friends from Europe found that mysterious). What I failed to recognize was that in the i-mode implementation a full ecosystem solved the problem by moving all the parts around. Of course i-mode got disrupted when the whole of the internet moved to mobile. So perhaps it wasn’t just me. No matter what happens, someone always said it would. But saying it would happen and acting are very different things. Though I do recall many exchanges with Blackberry execs trying to convince them to have a great browser once I used the iPhone.
The lesson always comes back to underestimating the power of ecosystem momentum and the desire and ability of new players to do new things on a new platform.
A while back I made a list of all the moving parts of the Blackberry collapse. You can read it here, Disruption and woulda, coulda, shoulda.
Rather than predict anything that will suddenly appear at the end of 2014, this post offers some trends that are likely to double by some measure this next year.
This will turn out to be an exponential year in many technologies and what seems far-fetched could very easily be trends that are doubling in relatively short periods of time. We humans generally have a tough time modeling things doubling (why so many companies and products did not figure out how to embrace Moore’s law or the rise of mobile).
To fully embrace exponential change means looking at the assumptions in product development and considering how optimizations for the near term might prove to be futile when facing significant change. Within each trend, design or product choices are offered that might be worth considering in light of the trend.
- Low-cost/high-function devices. The seemingly endless march of the exponential Moore’s law will continue but include more than compute. Devices will put transistors to work for sensors, rich graphics, and discrete processors. These devices will continue to drop precipitously in price to what seem today like ridiculous levels such as we’ve seen at discount super stores this holiday shopping season in the US. If automobiles are any indication, we should not assume low price is equivalent to low quality for the long-term, as manufacturing becomes more capable of delivering quality at low price. The desire to aspire an even higher level of quality will remain for many and continue to support many price points and volumes. At the same time, the usage patterns across price points will vary dramatically and we will continue to see exponential growth in-depth usage as we have this holiday season with high-value devices. This makes for a fairly dramatic split and leaves a lot open to interpretation when it comes to market share in devices. Design: First, it is worth considering target customers with more granularity when looking at share, as the pure number of devices might not determine how much your service will get used, at least in the near term. Second, don’t expect differences in capability across price points to last very long as the pace of pulling capabilities from higher price points to lower will be relentless.
- Cloud productivity. Cloud (SaaS) productivity tools will routinely see exponential growth in active users. Tools that enable continuous productivity will rapidly expand beyond tech early adopters as viral effects of collaboration kick in. Products such as Asana, Quip, Paper, Mixpanel, Lucidchart, Haikudeck or others will see viral expansion kick-in. Established tools such as Evernote, Box, Dropbox, WhatsApp, and more with high active usage will see major increases in cross-organization work as they grow to become essential tools for whole organizations. Design: Don’t assume traditional productivity tools and assume new employees, vendors, and recent grads will default to cloud-first productivity.
- Cloud first becomes cloud-only. Enterprise software in 2013 was a dialog about on-premises or cloud. In 2014, the call for on-premises will rapidly shift to a footnote in the evolution of cloud. The capabilities of cloud-based services will have grown to such a degree, particularly in terms of collaboration and sharing, that they will dwarf anything that can be done within the confines of a single enterprise. Enterprises will look at the exponential growth in scale of multi-tenant systems and see these as assets that cannot be duplicated by even the largest enterprises. Design: Don’t distract with attempting to architect or committing to on-premises.
- WWAN communication tools. WWAN/4G messaging will come to dominate in usage by direct or integrated tools (WhatsApp, WeChat, iMessage, and more) relative to email and SMS. Email will increasingly be viewed as “fax” and SMS will be used for “official” communications and “form letters” as person to person begins to use much richer and more expressive (fun) tools. This shift contributes to the ability to switch to data-only larger screen devices. Design: Skip email notifications, rely on SMS only when critical (security and verification), and assume heterogeneity for messaging choices. Expect to see more tools building in messaging capabilities with context scoped to the app.
- Cross-platform challenge. This is the year that cross-platform development for the major modern platforms will become increasingly challenging and products will need to be developed with this in mind. It will become increasingly unwieldy to develop for both iOS and Android and natively integrate effectively and competitively with the platform. Visual changes and integration functionality will be such that “cross-platform layers” might appear to be a good choice today only to prove to be short-lived and obstacles to rapid and competitive development. New apps that are cross-platform “today” will see increasing gaps between releases on each platform and will see functionality not quite “right” for platforms. Ultimately, developers will need to pick their lead platforms or have substantial code bases across platforms and face the challenge of keeping functionality in sync. Design: Avoid attempting to abstract platforms as these are moving targets, and assume dual-platform is nearly 2X the work of a single platform for any amount of user experience and platform integration.
- Small screen/big screen divergence. With increasing use of cloud productivity, more products will arrive that are designed exclusively for larger screen devices. Platform creators will increasingly face challenges of maintaining the identical user experience for “phones” and for phablets and larger. Larger screen tablets will be more able to work with keyboard accessories that will further drive a desire for apps tuned along these lines along with changes to underlying platforms to more fully leverage more screen real estate. The converse will be that scenarios around larger screen tablets will shift away from apps designed for small screen phones–thus resetting the way apps are counted and valued. Design: Productivity scenarios should be considering committing to large screen design and leave room for potential of keyboard or other input peripherals.
- Urban living is digital living. With demographic shifts in urban living and new influx of urban residents, we will see a rapid rise in digital-only lives. Mobile platforms will be part of nearly every purchase or transaction. Anything requiring reservations, tickets, physical resources, delivery, or scheduling will only win the hearts and minds of the new urban if available via mobile. While today it seems inconvenient if one needs to resort to “analog” to use a service, 2014 is a year in which every service has a choice and those that don’t exist in a mobile world won’t be picked. Design: Consumer products and services will only exist if they can be acquired via mobile.
- Sharing becomes normal. With the resources available for sharing exceeding those available in traditional ways, 2014 will be the year in which sharing becomes normal and preferred for assets that are infrequently used and/or expensive. Government and corporate structures will be re-evaluated relative to sharing from autos to office space and more. Budget pressures, rapid increase in software capabilities, and environmental impact all contribute to this change. Design: Can your business share resources? What are you using that could be shared? Is the asset you sell or rent something that runs the risk of aggregation and sharing by a new entry?
- Phablets are normal. Today’s phablets seem like a tweener or oddity to some–between a large phone and a small tablet. In practice the desire to have one device serve as both your legacy phone (voice and SMS) as well as your main “goto” device for productivity and communication will become increasingly important. The reduction in the need for legacy communication will fuel the need to pivot closer to a larger screen all the time. Improvements in voice input and collaboration tools will make this scenario even more practical. In the short-term, the ability to pair a larger screen tablet with your phone-sized device for voice or SMS may arise in an effort to always use one device, and similarly smaller tablets will be able to assume phone functionality. Design: Don’t ignore the potential of this screen size combined with full connectivity as the single device, particularly in mobile first markets where this form has early traction.
- Storage quotas go away. While for most any uses today this is true in practice, 2014 will be a year in which any individual will see alternatives for unlimited cloud storage. Email, files, photos, applications, mobile backup and more will be embedded in the price of devices or services with additional capabilities beyond gigabytes. Design: Design for disk space usage in the cloud as you do on a mobile client, which is to say worry much more about battery life and user experience than saving a megabyte.
Amara’s Law states “we tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run”. We will see 2014 not as one year of progress, but as the culmination of the past 15 years of development of the consumer internet as “it all comes together” with incredibly rapid adoption of products and technologies that at once become more affordable, more ubiquitous, and more necessary for our work and personal lives.
It looks like 2014 is shaping up to be the long-term of 2000 that we might have underestimated.
Stay tuned and Happy New Year!
LinkedIn engineer Martin Kleppmann wrote a wonderful post detailing the magical and thoughtful engineering behind the new LinkedIn Intro iOS app. I was literally verklepmpt reading the post–thinking about all those nights trying different things until he (and the team) ultimately achieved what he set out to do, what his management hoped he would do, and what folks at LinkedIn felt would be great for LinkedIn customers.
The internet has done what the internet does which is to unleash indignation upon Martin, LinkedIn, and thus the cycle begins. The post was updated with caveats and disclaimers. It is now riding atop of techmeme. Privacy. Security. etc.
Whether those concerns are legitimate or not (after all this is a massive public company based on the trust of a network), the reality is this app points out a longstanding architectural challenge in API design. The rise of modern operating systems (iOS, Android, Windows RT, and more) have inherent advantages over the PC-era operating systems (OS X, Windows, Linux) when it comes to maintaining the integrity as designed of the system overall. Yet we’re not done innovating around this challenge.
I remember my very first exploit. I figured out how to use a disk sector editor on CP/M and modified the operating system to remove the file delete command, ERA. I managed to do this by just nulling out the “ERA” string in what appeared to me to be the command table. I was so proud of myself I (attempted) to show my father my success.
The folks that put the command table there were just solving a problem. It was not an API to CP/M, or was it? The sector editor was really a tool for recovering information from defective floppies, or was it? My goal was to make a floppy with WordStar on it that I could give to my father to use but would be safe from him accidentally deleting a file. My intention was good. I used information and tools available to me in ways that the system architects clearly did not intend. I stood on the top step of a ladder. I used a screwdriver as a pry bar. I used a wrench as a hammer.
The history of the PC architecture is filled with examples of APIs exposed for one purpose put to use for another purpose. In fact, the power of the PC platform is a result of inventors bringing technology to market with one purpose in mind and then seeing it get used for other purposes. Whether hardware or software, unintended uses of extensibility have come to define the flexibility, utility, and durability of the PC architecture. There are so many examples: the first terminate and stay resident programs in MS-DOS, the Z80 softcard for the Apple ][, drawing low voltage power from USB to power a coffee warmer, all the way to that most favorite shell extension in Windows or OS X extension that adds that missing feature from Finder.
These are easily described and high-level uses of extensibility. Your everyday computing experience is literally filled with uses of underlying extensibility that were not foreseen by the original designers. In fact, I would go as far as to say that if computers and software were only allowed to do things that the original designers intended, computing would be particularly boring.
Yet it would also be free of viruses, malware, DLL hell, system rot, and TV commercials promising to make your PC faster.
Take for example, the role of extensibility in email, Outlook even in particular. The original design for Outlook had a wonderful API that enabled one to create an add-in that would automate routine tasks in Outlook. You could for example have a program that would automatically send out a notification email to the appropriate contacts based on some action you would take. You could also receive useful email attachments that could streamline tasks just by opening them (for example, before we all had a PDF reader it was very common to receive an executable that when opened would self-extract a document along with a viewer). These became a huge part of the value of the platform and an important part of the utility of the PC in the workplace at the time.
Then one day in 1999 we all (literally) received email from our friend Melissa. This was a virus that spread by using these same APIs for an obviously terrible usage. What this code did was nothing different than all those add-ins did, but it did it at Internet scale to everyone in an unsuspecting way.
Thus was born the age of “consent” on PCs. When you think about all those messages you see today (“use your location”, “change your default”, “access your address book”) you see the direct descendants of Melissa. A follow on virus professed broad love for all of us, I LOVE YOU. From that came the (perceived) draconian steps of simply disabling much of the extensibility/utility described above.
What else could be done? A ladder is always going to have a top step–some people will step on it. The vast majority will get work done and be fine.
From my perspective, it doesn’t matter how one perceives something on a spectrum from good to “bad”–the challenge is APIs get used for many different things and developers are always going to push the limits of what they do. LinkedIn Intro is not a virus. It is not a tool to invade your privacy. It is simply a clever (ne hack) that uses existing extensibility in new ways. There’s no defense against this. The system was not poorly designed. Even though there was no intent to do what Intro did when those services were designed, there is simply no way to prevent clever uses anymore than you can prevent me from using my screwdriver as a pry bar.
I wanted to offer a modern example that for me sums up the exploitation of APIs and also how challenging this problem is.
On Android an app can add one or more sharing targets. In fact Android APIs were even improved to make it easier in release after release and now it is simply a declarative step of a couple of lines of XML and some code.
As a result, many Play apps add several share targets. I installed a printing app that added 4 different ways to share (Share link, share to Chrome, share email, share over Bluetooth). All of these seemed perfectly legitimate and I’m sure the designers thought they were just making their product easier to use. Obviously, I must want to use the functionality since I went to the Play store, downloaded it and everything. I bet the folks that designed this are quite proud of how many taps they saved for these key scenarios.
After 20 apps, my share list is crazy. Of course sharing with twitter is now a lot of scrolling because the list is alphabetical. Lucky for me the Messages app bubbles up the most recent target to a shortcut in the action bar. But that seems a bit like a kludge.
Then along comes Andmade Share. It is another Play app that lets me customize the share list and remove things. Phew. Except now I am the manager of a sharing list and every time I install an app I have to go and “fix” my share target list.
Ironically, the Andmade app uses almost precisely the same extensibility to manage the sharing list as is used to pollute it. So hypothetically restricting/disabling the ability of apps to add share targets also prevents this utility from working.
The system could also be much more rigorous about what can be added. For example, apps could only add a single share target (Windows 8) or the OS could just not allow apps to add more (essentially iOS). But 99% of uses are legitimate. All are harmless. So even in “modern” times with modern software, the API surface area can be exploited and lead to a degraded user experience even if that experience degrades in a relatively benign way.
Anyone that ever complained about startup programs or shell extensions is just seeing the results of developers using extensibility. Whether it is used or abused is a matter of perspective. Whether is degrades the overall system is dependent on many factors and also on perspective (since every benefit has a potential cost, if you benefit from a feature then you’re ok with the cost).
There will be calls to remove the app from the app store. Sure that can be done. Steps will be taken to close off extensibility mechanisms that got used in ways far off the intended usage patterns. There will be cost and unintended side effects of those actions. Realistically, what was done by LinkedIn (or a myriad of examples) was done with the best of intentions (and a lot of hard work). Realistically, what was done was exploiting the extensibility of the system in a way never considered by the designers (or most users).
This leads to 5 realities of system design:
Everything is an API. Every bit of a system is an API. From the layout of files, to the places settings are stored, to actual published APIs, everything in a system as it is released serves as an interface to people who want to extend, customize, or modify your work. Services don’t escape this because APIs are in a cloud behind REST APIs. For example, reverse engineering packets or scraping HTML is no different — the HTML used by a site can come to be relied on essentially as an API. The Windows registry is just a place to store stuff–the fact that people went in and modified it outside the intended parameters is what caused problems, not the existence of a place to store stuff. Cookies? Just a mechanism.
APIs can’t tell you the full intent. APIs are simply tools. The documentation and examples show you the mainstream or an intended use of an API. But they don’t tell you all the intended uses or even the limits of using an API. As a platform provider, falling back on documentation is fairly impossible considering both the history of software platforms (and most of the success of a platform coming from people using it in a creative ways) and the reality that no one could read all the documentation that would have to explain all the uses of a single API when there are literally tens of thousands of extensibility points (plus all the undocumented ones, see #1).
Once discovered, any clever use of an API will be replicated by many actors for good or not. Once one developer finds a way to get something done by working through the clever mechanism of extensibility, if there’s value to it then others will follow. If one share target is good, then having 5 must be 5 times better. The system through some means will ultimately need to find a way to control the very way extensibility or APIs are used. Whether this is through policy or code is a matter of choice. We haven’t seen the last “Intro” at least until some action is taken for iOS.
Platform providers carry the burden of maintaining APIs over time. Since the vast majority of actors are doing valuable things you maintain an API or extensibility point–that’s what constitutes a platform promise. Some of your APIs are “undocumented” but end up being conventions or just happenstance. When you produce a platform, try as hard as you want to define what is the official platform and what isn’t but your implied promise is ultimately to maintain the integrity of everything overall.
Using extensibility will produce good and bad results, but what is good and bad will depend highly on the context. It might seem easy to judge something broadly on the internet as good or bad. In reality, downloading an app and opt-ing in. What should you really warn about and how? To me this seems remarkably difficult. I am not sure we’re in a better place because every action on my modern device has a potential warning message or a choice from a very long list I need to manage.
We’re not there yet collectively as an industry on balancing the extensibility of platforms and the desire for safety, security, performance, predictability, and more. Modern platforms are a huge step in a better direction.
Let’s be careful collectively about how we move forward when faced with a pattern we’re all familiar with.
28-10-13 Fixed a couple of typos.