Posts Tagged ‘design’
Why The Heck Can’t We Change Our Product?
I drove by the fork in the road and went straight.
— Jay-Z (see author’s endnote)
One of the most vexing product challenges is evolving the UX (user experience, and/or user UI) over long periods of time, particular when advancing a successful product with a supportive and passionate community.
If you are early and still traveling the idea maze in search of product-market fit, then most change is good change. Even in the early days of traction, most all changes are positive because they address obvious shortcomings.
Once your product is woven into the fabric of the lives of people (aka customers) then change becomes extraordinarily difficult. Actually that is probably an understatement as change might even become impossible, at least in the eyes of your very best customers.
The arguments are well-worn and well-known. “people don’t like change”…”muscle memory”…”takes more time”…”doesn’t take into account how I use the product”…”these changes are bad”…”makes it harder to doX”…”breaks the fundamental law of Y”…”what about advanced users”…”what about new users”…and so on. If you’re lucky, then the debate stays civil. But the bigger the product and the more ardent the “best” (or most vocal?) customers, well then the more things tilt to the personal and/or emotional.
Just this past week, our feeds were filled with Twitter rumored to make a big change (or even changing from Favorite to Like), Uber changing a logo, and even Apple failing to change enough. It turns out that every UI/UX change is fiercely monitored and debated. All too often this is a stressful and unpleasant experience for product designers and an extremely frustrating experience for the customers closest to the product. Even when changes are incredibly well received, often the initial response is extremely challenging.
For all of the debates, a product that fails to dramatically change is one that will certainly be bypassed by the relentless change in how technology is used.
Yet change, even of a core user experience, is an essential part of the evolution of a product. For all of the debates, a product that fails to dramatically change is one that will certainly be bypassed by the relentless change in how technology is used. We do not often consider the reality that most new products (and services) we enjoy are often quite similar to previously successful products, but with a new user experience.
Consider that the graphical interface for spreadsheets and word processors replaced whole companies built around predominantly similar capabilities in character mode interfaces. The competitive landscape for browsers was framed by having minimal interface. Today’s SaaS tools often lead with capabilities similar to legacy products expressed through consumerized experienced and cloud architecture.
Technology platform disruptions are just that, disruptive, and there’s no reason to think that the user experience should be able to smooth out a transition. There’s every reason to think that trying to make a UX transition go smoothly might be a counter-productive or even a losing strategy.
The biggest risk in product design is assuming a static world view where your winning product will continue to win with the same experience improving along the same path that got you success in the first place.
The reality is that if you are not doing more in your product you are doing less, and doing more will eventually require a redesign and rethinking over time. The corollary is that if you are only doing what you’ve always done, but a little better every time, then as a practical matter you are also doing less relative to always-emerging competitive alternatives.
The biggest risk in product design is assuming a static world view where your winning product will continue to win with the same experience improving incrementally along the same path that got you success in the first place.
There are dozens of amazing books that tell you how to design a great user experience. There are seemingly endless books and posts that are critical of existing user experiences. There are countless mock-ups that say how to do a better job at a redesign or how to fix something that is in beta or already changed (see The Homer). Few and far between, however, are the resources (or people) that guide you through a major change to user experience.
No one tells you that you’ll likely face your most difficult product design choices when your product is incredibly successful but facing existential competitive challenges — competitive challenges that your most engaged customers won’t even care about.
This essay is is presented in the following sections:
- User Experience Is Empowerment
- Everyone’s A Critic
- Pressure To Change
- 5 Ways To Prepare
- 5 Approaches To Avoid
- Reality
User Experience Is Empowerment
At the most basic human level, the mastery of a tool (a user interface or experience) is about empowerment. Being able to command and control a tool feeds a need many of us share to be in control of our environment and work.
Historically we (all) seek to be the master of our “life tools” whether an shovel, a horse, a car, a PC, or the arcane commands of a modern social network. Something magical happens for a product (and company) when it is so compelling that people spend the time and effort required to master it.At that moment, your product becomes an essential part of the lives of customers, customers who come to believe their world view is shared by “everyone”.
Those customers become your very best customers who see your tool as a path to mastering some of the ever more complex aspects of life or work.Those same people also become your harshest critics when you try to change, anything.
A Story
Permit me to share an example of how this empowerment can work, deliberately using an historic example few will remember.
Some time in the mid 1990’s I was a product (program in Microsoft lingo) manager on Office and we were trying to figure out how to transition from a consumer app (yes we used the phrase consumer app back then) to an enterprise platform (that word was new to us). There were many elements to this, but one in particular was the setup and deployment of the Office apps.
As is often the case, customers were ahead of us on the product team when it came to figuring out the most efficient way to copy the Office bits (all 50MB of them) from floppies to a file server to desktops and laptops. Customers had all sorts of things they wanted to do when “installing” Office onto a PC — changing default settings, removing unneeded files like clipart, and even choosing which drive to use for the bits. Many of those could be controlled by the setup program that was itself an app requiring human interaction, save for a few select capabilities. PC admins wanted to automate this process.
As you might imagine, admins cleverly reverse-engineered the setup script file that was used to drive the process. This was a file that did for the comma what LISP did for parentheses. It was a giant text file filled with record after record of setup information and actions, with an absurd number of columns delineated by commas. In fact, and this is a little known embarrassment, the file was so unwieldy that to edit it required a non-Microsoft editor that could handle both the text file length and the line width. Crazy as that was, a very large number of PC admins became experts in how to “deploy” Office by tweaking this SETUP.INF. I should mention, one missing comma or unmatched quote and the whole system went haywire since it was never designed to be used by anyone but the half dozen people at Microsoft who understood the system and were backed by a large number of test engineers.
We believed we had a clever idea to solve a broad range of customization, security, and even engineering challenges which was to replace the fragile text file and third party text editor with a robust database and graphical interface. Admins could then push a customized installation to a PC without being in front of it and the PC could even repair an installation if it somehow got corrupted or munged. We really put a lot of effort into solving this with a modern, thoughtful, and enterprise friendly approach. Consumers would see almost no changes.
Then came the first beta test and what could best be described as a complete disaster. Of course the customers in the beta were precisely the small same set of customers that had figured out how to hack the previous system. We had little understanding that these customers had become heroes within world of PC Admins because they could get a new PC up and running with Office in no time flat. Many had become the “goto person” for Office deployment in an era when that was a big deal. Deploying Office had become a profession.
That should have been success for us on the Office team except we changed the product so much that everything special the admins had mastered had become irrelevant. They had lost their sense of mastery over their environment.
Looked at through another lens, implicit in the change is a devaluation of the acquired knowledge and expertise of these customers.
The pain was felt by our team as well. Our goal was to make things better for admins by replacing the tedious and error prone work with a platform and slick new tools. As an added bonus the new platform greatly improved robustness and reliability and added whole new features such as install on demand. All the admins saw, however, was a big change and subsequent loss of empowerment. Looked at through another lens, implicit in the change is a devaluation of the acquired knowledge and expertise of these customers.
It would have been easy to see how to take their very specific and actionable feedback and roll the changes back to what we had before, or to introduce some bridge technology (or other “solution” discussed below). On the other hand, the competitive forces that drove these choices including web-based and browser-based tools were increasingly real. The technology shift was underway. It was clear if we did not change the product and disrupt the established processes we would have only hastened a potential disruption of our business. The market was clear about the failures of the architecture we had in place.
Everyone’s A Critic
If you ever want to go for a record on the world’s longest comment thread then author a post on user interface suggesting how a product should be improved, fixed, re-done, or just rescued. On the internet, no one knows you’re a dog but everyone is a user interface critic and/or designer. Certainly well-intentioned, each person is genuinely responding to challenges they have with a product. Some of debates over the past few months in Windows circles over the hamburger menu or the discussions around iOS’ 3D touch show the many sides to how this plays out from friends and fans alike. As I type this, Twitter even has a trending hashtag on rumored changes to the product.
Some of my favorite posts have always been the ones where someone takes the time and effort to do a rendering to improve upon an experience I worked on/managed — “this is what it should look like”. The internet and tools make it easy to turn a complex and dynamic system design into a debate about static pixels and an image or two (or twenty). The ensuing debate might be narrowly focused on specific affordances such as “the hamburger menu” or whole themes such as “skeuomorphic versus flat” design.
The presence of renderings or “design alternatives” only add stress and uncertainty to what is already an emotionally charged and highly uncertain process while at the same time creating a sense of authority or even viability. The larger the project the more such uncertainty brings trouble to the design, especially as people pile on saying “why not do that?”. It is worth noting that the internet can also be right in this regard, such as this post on iOS keyboards.
The irony is that you’re far more likely to participate in a UX discussion/debate with people with very different starting and end points than those for whom your design is intended.
There’s quite a challenge in the tech dialogs around UX. First, those that participate in the dialog are on the whole representative of power users and technology elite. More often than not, UX design is seeking to include a broader audience with a wide range of skills or even interest in using more depth functionality.
Second, the techies (to use @waltmossberg’s favorite phrase) often prefer innovations that enable shortcuts or options to existing features they see flaws with rather than doing whole new things. Techies tend to want to fix the shortcomings in what they see, which is also not always aligned with solving either broader usage challenges or even business problems. The irony is that you’re far more likely to participate in a UX discussion/debate with people with very different starting and end points than those for whom your design is intended.
While every person can be a critic (often even for products that they do not routinely use), it is also the case that every UI can become old or at least static and open to criticism. Interfaces age both internally (the team) and externally (the market). Internally, you might hit a wall on where to evolve. Customers fall into routines and usage patterns. Nothing new you do is recognized or used.
Externally, your shiny new experience that replaces some old experience (for doing slightly different or totally unrelated things) will eventually become the type of experience that gets replaced. While some think of this in terms of stylistic trends like transparency or gradients, the truth is there are functional aspects to aging as well such as interacting with touch or gestures, bundling of different feature sets, or macro trends in visual design.
When you put together the large number of critics and the certainty of your experience aging, you’re in for a challenging time to evolve your interface. Whether you have a consumer app or site with a billion users, a commerce site, a productivity tool, or a line of business app the challenges are all the same. While the scale or direct economic impact might differ, to those designers and product managers working the problem the challenges and decisions are the same, and to their customers the frustration is just as real.
Pressure To Change
Changing a user experience should in theory be no more or less difficult than a major re-plumbing or even creating the first experience. Some things make changes more difficult, or perhaps at least more open to direct criticism. With a backend change, the most visible changes might be performance or uptime (to be fair, the debates about change within product engineering are just as contested). With UX changes (additions, subtractions, reworking) everyone seems them through a more complex lens.
Changing something that people have an emotional connection to is difficult. An emotional connection creates expectations or even norms, and the natural human reaction is to defend the status quo and maintain control. The discussions of change rapidly deteriorate to preference, taste, or argument by analogy, or assertion all of which are very difficult to counter when compared to facts, stopwatches, or physics.
In my experience there are several key pressure points that drive change, beyond the most obvious of fixing what is broken. You can accept or reject these and advocate for change yourself or leave room for your competitors to capture the leadership and change. Depending on context wisdom could be found from many perspectives.
Pressure to change confronts a successful and engaging product because of:
- Evolving use cases
- Locating new capabilities
- Discovering features
- Increasing tolerance of complexity
- Isolating change leads to complex analysis of benefits
- Competing products and/or changing expectations
Evolving use cases. You might design your product to solve a specific key scenario, but over time you find a different set of use cases coming to dominate. This in turn might require rethinking the flow through the product or the features that are surfaced. In a sense this can be seen as evolving the product to meet real world usage versus theoretical usage, except it will still be a change. We see this in the amount of UX real estate legacy tools devote to print-based formatting or layout design compared to the next generation of tools that surface collaboration and communication features as primary use cases. The changes in Facebook and Facebook Messenger demonstrate this driver. A relatively minor scenario saw increased usage and strategic value driving a significant, and hotly debated, experience change.
Locating new capabilities. As new capabilities are added, most all of the time those features require some UX affordance. Almost never is there room in the existing product for the new feature. In evolving Office, we reached a point where we literally ran out of room on menus and then on toolbars (originally the goal of toolbars was to be a shortcut for things on the menus or dialog boxes, but soon features on toolbars had no counterparts in menus and dialog boxes). This challenge is even more acute in today’s mobile apps that are often “filled” from the very first release. This design challenge can be likened to trying to add a new major appliance to an existing kitchen — there is almost never room to add one until the next major redesign when flows are reconsidered. As a result, when it comes time to add UX for entirely new scenarios your product will change significantly. Recently, LinkedIn chose to invest heavily in content authoring and sharing but the core experience was aimed at jobs and resumes. The new mobile app, which was reviewed positively in many cases, changed the focus substantially to these new scenarios.
Discovering features. It is easy to want common features to be easy to use and new features to be discoverable, but those are increasingly at odds as a product evolves. The first challenge is just in finding the screen real estate for new capabilities as discussed above. More likely, however, is that new capabilities will be subordinate to existing ones in terms of surface area. This leads to affordances such as first-run overlays to explain what all the product might do or what gestures are available, which is itself added complexity (and engineering!). One also sees new capabilities with a disproportionate “front and center” placement in an effort to increase discoverability. Often this results from a “marketing” need to drive awareness of the very features being used in outbound marketing efforts.
Over time, A/B testing or usage data will then drive additional change as features are rotated out to make room for new. This all seems quite natural, but also clearly drives complexity or even confusion. This in turn raises the challenge of even changing a product in the first place. Most Google productivity tools we use experience this challenge. Gmail and Apps are increasingly complex and it is getting more difficult to discover capabilities. Historically Google had Labs features to explore new areas and now even Inbox is a whole new experience for mail.
If you ever doubt the ability for people to tolerate more complexity, then just look at the old version of any famous site, app, or program. You’d be amazed at how sparse it is.
Increasing tolerance of complexity. Everyone loves simplicity and certainly every designer’s goal in creating a system is to maintain the highest level of simplicity while providing the right functionality. Over time there is no way to remain simple as more features are added the ability for someone new to the system to command it necessarily decreases and the usage of the system’s breadth decreases. Nevertheless, people become accustom to this growing complexity. It creates a moat relative to new entrants and a barrier to change. People loved the ironically named Chrome browser when it arrived because it was so clean and simple. Few would argue that level of simplicity remains today, yet the complexity is embraced and there’s little opening for a browser that provides less functionality.
For all the criticisms directed at the complexity of Microsoft Office, few switched away to products that do less simply because they were simpler. If you ever doubt the ability for people to tolerate more complexity, then just look at the old version of any famous site, app, or program. You’d be amazed at how sparse it is. The pressure to reduce and simplify comes from everywhere with technology products, but sometimes a failure to embrace a level of complexity can prevent important and strategic change. The most adaptable part of the entire technology stack is the human being at the very top.
Isolating change leads to complex analysis of benefits. UX experience, new or changed, is almost always viewed in isolation. New UX is viewed relative to the small number of initial capabilities and the ease at which those are done compared to existing solutions (i.e. make a voice call on the original iPhone). Changes to products are viewed through the lens of “deltas” as we see in reviews time and time again — reviews look at the merits of the delta, not the merits of the product overall relative to new scenarios that might be more important and old scenarios that might be less important now (as user needs evolve). When viewed in isolation, change is amplified which then makes change more difficult to execute, absorb, or even accept.
Isolation results in intense levels of discussion among the technologists as alternatives are proposed (after the fact) even for very small changes. More importantly, this dialog amplifies the value of small changes which in the scheme of thing will do nothing to improve the business and everything to prevent larger and more strategic changes from happening. Platforms providing horizontal capabilities to broad audiences are notorious for these debates in isolation. Consider the transition iOS made to a new visual design which is now a distant memory.
Competing products and/or changing expectations. The biggest and most important driver for change are the external market forces of competition. Each of the previous drivers are all within your own world view — these are changes you are driving for products you control with inputs and feedback you can monitor. The competitors you view as strategic are incredibly important inputs relative to the longer term viability of the business.
The fascinating thing is that your best customers are the least likely to be worried about your longer term strategy, especially if they have bet their jobs and are empowered by your product. In fact, they will be just as “dismissive” of competing products or new approaches or solutions as your highly paid sales people that are continuing to close deals or the self-taught expert who can’t wait to join the product team. As a technologist you know that your product will be replaced or superseded by a new product and/or technology. It is just a matter of time.
The most important thing to consider is that it is almost never the case that your direct competitor will serve as motivation for changing expectations. The pressure to change will come from unexpected substitutes or newly crafted combinations of a subset of existing capabilities. Ironically, most all of your inputs will come from people and members of the team/company focused on your direct competitor (and the bigger your presence the more likely this will be).
5 Ways To Prepare
The first rules of product design relative to change are to expect it and to prepare for it. It is common-place to remind ourselves in product design that the enemy of the good is the perfect, but relative to evolving experience the enemy of the good is the past.
Assuming that today’s user experience encompasses the value of your product tomorrow is certain to get you in trouble (just as assuming some specific code or API is the core of your value). A comforting way to approach this is to remind yourself that before your current successful user experience there was a successful experience that was widely used. People gave up that product to learn and use your new and different product.
The following are five ways to prepare your design for a future that will require you to change:
- Solve the n+1 problem up front
- Design for the choices you know about
- Optimize only to a point
- Decide your app strategy early on
- Flat is your friend
Solve the n+1 problem up front. One of the most common times a new feature causes UX churn is when you’re adding something you knew about but didn’t have time to engineer. I call this n+1 because across the product there are places where your experience (and code) assumed a finite number of choices and then down the road you find you need one more choice. Commonly this is seen as choices like photo filters, email accounts, team/channels, formatting options, and so on. These changes are recognizable when you go from either no choice to a choice or need to switch from binary/ternary to some list.
The warning signs for this potential change come very early on because you either cut the feature or the feedback is everywhere. It is almost always the case that these are core flows in the experience so designing up front can be a big help. Incidentally, this also holds for engineering and the product architecture where the highest cost additions are often when you need to go back and engineer in a level of indirection to solve for choice where there was no architecture. Some might see this as counter to MVP approaches but nothing comes without a cost.
Design for the choices you know about. As a corollary to above, there is a design approach that says to leave room for the unknown, “just in case”. Such a design often leaves open space in the interface that stares at you like an unused parking spot at the mall. At first this seems practical, but over time this space turns into an obstacle you must work around because nothing ever seems to meet the bar as belonging in the space.
On the other hand, this also serves as a place where everyone on the team is battling to elevate their feature to this valuable “real estate”. Even more challenging, your best fans will have a million ideas for how to fill up this space (and renderings to demonstrate those ideas), and too often that amounts to using it to provide shortcuts to existing functionality. Preparing for what you don’t know by compromising the current does little to postpone the inevitable redesign and does a lot to make the current design suboptimal.
Optimize only to a point. Optimize to a point and recognize that you will change, and assume that the vast majority of input will be focused on areas you were not really expecting (someone on the team probably was expecting but not everyone). In preparing for a future of change one of the most difficult things to do in design is to recognize that where you are at a given point in time for a development cycle is good enough to ship. Stop too soon and the risk of missing is high. Stop too late and the reluctance on the team to change down the road is only increased because of sunk costs and a too much historic baggage.
The most critical rule of thumb in product design is that a product releases “as is” and does not come with all the designs you considered or could consider. When it comes time to disrupt yourself with significant changes, do not underestimate the amount of institutional inertia that will come from a few years of researching and testing every possible alternative to a design. The expression often used, “peacetime generals are always fighting the last war” applies to design and product choices as well.
Decide your app strategy early on. A strategic question facing any broad-based product will be how many mobile apps do you need. In the enterprise if you’re building a full ERP system there’s no way to have a single app, but it could also be very easy to create a sort of app shrapnel and replicate the 1500 legacy web sites that the average large corporation maintains. If your product has either a desktop or web solution and apps are being added, you have to decide early on if your app is a scenario-based companion of the primary/only way you expect people to use a service — you might be considering a mobile capture app to go with a web-based analysis app, or keeping the admin tools on the web to accompany mobile workers in apps.
It is very difficult to switch mindsets down the road so this choice is key. A valuable lesson (in disruption) was learned during the transition from desktop to web. The prevailing broad view that web apps would be supersets of desktop apps proved to be true as many believed, but it just took about three times as long as people thought. If you believe your mobile app is a companion to your site, just be prepared for a large number of customers that only want to access over mobile even if they are not doing so today.
Flat is your friend. Programmers and designers often love hierarchy — hierarchy helps our computer brains to organize and deal with complexity and most techies have no problem navigating hierarchy. Unfortunately most people long ago failed to grasp the Dewey Decimal system and search seems to win out over hierarchical organization in most every instance. Aside from that, the most frustrating changes to experience come when you reorganize a hierarchy (trust me on this one).
Hierarchy is the source of muscle memory and also where much of a sense of mastery comes from. The power users are the people that know where features are hidden or how to drill through panels to find things. Hide and Seek or Concentration are great for the right people, but a poor way to do user experience. A solid approach to avoid a future reorganization is to see how flat you can keep your experience. SEO or A/B testing (or marketing) will always push to keep things above the fold, oddly motivating hierarchy, and not favor scrolling which most everyone understands. The alternative of click/tap to a new place is way more disruptive both today and down the road.
We all wish we could be fully informed about the way we will evolve our product and the way competitors will provide a unique view into the space we are going after. That is never as easy as it could be. The above are just a few ideas to consider if you start from the mindset that once you achieve success you will end up going through a user experience change.
5 Approaches To Avoid
With a successful and deeply used product, when you do make a significant change to your experience the feedback is often swift and clear, and universal praise is exceedingly rare. As a result, the product team discussion will move from expressing frustration to proposing solutions very quickly. Even if you were expecting some pushback, it is never pleasant. At that moment, there is a limited design vocabulary available to make unplanned adjustments, perhaps even more limited than the engineering time you have to execute (assuming that as with most projects you are under pressure to complete all the new stuff).
Similarly, you might anticipate some pushback and are considering a proactive approach with proactive objection handlers or scheduled time for feedback. Regretfully, the solution set is the same since the problem is the change itself, not the way you are changing. The only difference is that the more you engage in defensive engineering efforts the less time you have to get the new work done. More importantly, time spent on salves or bridges only takes away from the existential competitive dynamic that is motivating the need for change.
These potential solutions all arise from the same place, which is that your early adopters, best customers, and front lines sales are all successful with your product and resisting a big change. The resistance is natural — the feeling of empowerment and familiarity. Remember, the reason your are making changes is because your successful product, in your best judgement, is facing an existential threat. This threat is not coming from these early voices, but from the customers you have failed to acquire or are not likely to ever acquire. You are making changes to support future growth not incrementally improving your existing customers.
While the 5 approaches outlined below are typical, they often backfire in predictable ways which is why they should be avoided:
- Add a new mode
- Offer customization
- Solve with a UI level of indirection
- Downplay the changes
- Redesign quickly
Add a new mode. Enthusiasts, marketing, and enterprise customers have no problem with change so long as you add an option they can use to get back to the old way of doing things. This feedback can be pretty sneaky. They will say that the option can be hidden and hard to get to because it is really only for power users or admins, or just an objection handler for the sales process. They might even tell you that you can take away the option after some time to adjust. By the way, another variant of this request is to just provide an option to “hide the new stuff”. You see how this is a sneaky ask — eventually there will be something in the new stuff that even these customers will want but without interfering with the existing “old” way. It certainly seems lightweight enough.
The challenge is twofold. First, once you can get back to the old way of doing things then everyone will want to know why that option exists. “Is the new way not good enough?” will be a common refrain. Second, once you have such an option you are designing for two experiences all the time. Everything you add needs to consider the old way and new way of getting to a new product areas. Not only is this super difficult, it is expensive and it takes away from forward-looking strategic needs. In general, modes, whether user-directed or contextual, are a way to postpone making a strategic choice about the future of your product and advertise your own indecisiveness.
By the way, technology enthusiasts love modes because modality (I suppose dating back to VI) implies hierarchy, control, choice, and a priori knowledge of where your are heading in the product that most people don’t have. Almost all choice and modality is ultimately ignored by customers and when the product magically switches modes, there is almost always a level of frustration that comes from the unexpected behavior changes (even think of the cleverness of having views defined by portrait or landscape which tend to be confusing in practice).
Offer customization. Customization permits you to make big changes with three mitigations.
First, you can allow people to customize your functionality one setting at a time until it returns to where it was. Often this is how a product evolves as it tries to automate previously multi-step processes. For example, if you used to manually turn off the lights at home via some IoT app but then add machine learning to guess, the first time the lights are wrong the answer will be to disable the new automation (AutoCorrect in Word was like this). You need to get something right or handle it gracefully when you’re wrong, but turning it off means it will never be successful.
Second, customization is often used to rearrange the user interface to get it back to where it was before when it was good Maybe you took away a share button to use the one provided by the OS or maybe you added a few tabs to the top level UI, well then just a switch to move things around.
Third, customization can be used for when you want to add something and the team can’t even decide whether it is a good idea or not so you add your own way to turn it off or hide it. All of these have the same downstream problems with setting a risky precedent that can’t be maintained (i.e. everything new comes with a way to change it) and adding combinatorics that can’t be managed (the testing matrix).
Making up your mind is the best approach. Longer term, the disruptive innovation will come from when the new product subsumes your product and at that time customizing how your product works will prove to be extraordinarily low-level, almost like a debugger. Think this will never happen, then look at all the options in Office that we totally sweated over. Again, technologists love customizations so you are almost certain to get positive feedback and strong encouragement to providing customization.
Solve with a UI level of indirection. The hamburger, Tools|Options, right click, sub-menus, and more are all ways of adding things without adding things or hiding things you add but don’t want to add. There’s no magic answer to where to squeeze all the things you need in a design into a (very) finite space, but for sure if you find yourself putting something new behind a level of indirection then think twice.
Once you think you can get away with “change” by putting it behind a level of indirection then you might as well not do it. Sometimes this type of approach takes place in enterprise products where you are responding to a competitive dynamic but you don’t agree with the competitor or the competitor’s approach is at odds with your overall design. The theory is to add the checkbox but not break your overall model or experience. Only you can judge whether you are seeking credit with reviewers and analysts or actual humans but be careful thinking that you have solved the problem and not just created a future problem.
The discoverability of your work hidden behind a level of indirection is minimal so always ask if you’re doing the work for customers or to make yourself feel like you’re addressing a business or customer need.
Downplay the changes. If you go through the work to understand why you are going to make a big change, then design and engineer a change, the very worst strategy is to downplay the effort when it comes time to communicate what you did.
If you make a big change and talk about it like it is a little change then many will wonder if you are confused and/or lack empathy. The challenge is that this one is the easiest of all responses since it is simply a different tone or wording in a post describing what is changing. You choose the right screen shots or feature names and things can look more familiar. When customers who were expecting the same or incremental see what you’ve done this tends to increase the backlash and the internet loves a good dose of corporate “wool over the eyes of customers”.
Since significant strategic challenges are driving this change, backing off is a worst of all worlds reaction — you send the message to the market that you’re fighting the last war, thus not engaged in the future, and customers come to expect that as well.
Redesign quickly. If how you communicate the change is the short term response, then the medium term response is to quickly redesign what you just spent a lot of time designing. How quickly can you back out the most egregious changes? How can you undo things with as little engineering work as possible? What if you just added a couple of old things back front and center? These are all things that will be rapidly floated within the team.
The most fascinating aspect of this response is that this is what the internet will do for you, both quickly and broadly. The reason is that once a new design is put forth, incremental changes to that design along the lines of “do this instead” will be offered by the community that is empowered by your product. There will almost certainly be good ideas amongst all of these, and even more likely they will be alternatives you considered (we never really learned why Apple so steadfastly refused to highlight the shift state on the iOS keyboard but it is impossible to believe this was not discussed).
Design and engineering are difficult and we all know that the likelihood of mistakes increases with the pace of reactionary change.
Reality
As this post keeps saying, the reason it is so painful and frustrating to change user experience is because right at the moment that your product has successfully reached the point of being empowering and critical to the jobs and lives of your customers it is also facing the most existential competitive and marketplace challenges.
The reality is you have to respond to the marketplace. You can choose to continue to iterate on the same path with the same customers. In the technology world that is, with as high a certainty as you can count, focused on the shrinking market. Disruption is real and it so far it is proving to be much more of a law than a theory.
Is the time to change right? Is the design you chose the right one? Are you focused on the right strategic competitors? The other reality of technology change is that most often the forces that keep a product and company from transitioning from one generation to the next are not an understanding or ability to debate these choices, but the ability to execute across product, engineering, marketing, and sales.
The really good news about all of this is that if you can create the product change and go-to-market execution, the reality is that short-term memory is a real thing, especially in a growing market. If you can make changes that secure new customers and grow or that your typical customers can adjust to without “incident” then there’s a really good chance that memory will be short term.
Those customers that chose to stick with character interfaces or would not move off a web app, got left behind by graphical and mobile users. This happens with every technology platform shift and happens within every category. Growth is the friend of change and if you’re not growing you are by definition shrinking.
I’d like to add one last reality for everyone who both made it this far and is out there critiquing new designs for products they use and love. The people working on products you love are on average as good as you, as thoughtful as you, and as informed as you. They are all open to feedback and good two-way discussion. Treat them the way you would like to be treated in the same situation.
Author’s note. I’ve never used a music lyric quote and don’t mean to steal Ben’s intro, but this quote from this song has special meaning to me in this particular situation.
This post originally appeared on Medium.
Frictionless Design Choices
No one wants friction in their products. Everyone works to reduce it. Yet it sneaks in everywhere. We collectively praise a service, app, or design that masterfully reduces friction. We also appreciate minimalism. We love when products are artfully distilled down to their essence. How do we achieve these broadly appreciated design goals?
Frictionless and minimalism are related but not necessarily the same. Often they are conflated which can lead to design debates that are difficult to resolve.
A design can be minimal but still have a great deal of friction. The Linux command line interface is a great example of minimal design with high friction. You can do everything through a single prompt, as long as you know what to type and when. The minimalism is wonderful, but the ability to get going comes with high friction. The Unix philosophy of small cooperating tools is wonderfully minimal (every tool does a small number of things and does them well), but the learning and skills required are high friction.
- Minimalist design is about reducing the surface area of an experience.
- Frictionless design is about reducing the energy required by an experience.
When debating a design choice, feature addition, or product direction it can help to clarify whether a point of view originates from a perspective of keeping things minimal or reducing friction. If people discussing a decision start from this common understanding, I bet a decision will be reached sooner. Essentially, is the debate about adding a step or experience fork, or is it about adding something at all?
Product managers need to choose features to add. That is what makes all of this so difficult. As great as it is to stay pure and within original intent, if you and the team don’t enhance the capabilities of your product then someone will do what you do, but with a couple of more things or a different factoring and you’ll be left in the dust.
Therefore the real design challenge is not simply maintaining minimalism, but enhancing a product without adding more friction. Let’s assume you built a product that does something very exciting and has a very low friction to usage and does so with a minimal feature set. The next efforts are not about just watching your product, but about deciding how to address shortcoming, enhance, or otherwise improve the product to grow users, revenue, and popularity. The risk with every change is not simply failing to maintain minimalism, but introducing friction that becomes counterproductive to your goals.
When you look back you will be amazed at how the surface area of the product has expanded and how your view of minimalism has changed. Finding the right expression of new features such that you can maintain a minimalist approach is a big part of the design challenge as well.
There’s an additional design challenge. The first people who use your product will likely be the most enthusiastic, often the most technical, and in general the most desirous of features that introduce friction. In other words you will get the most positive feedback by adding features that ultimately will result in a product with a lot more friction.
Product managers and designers need to find the right balance as the extremes of doing nothing (staying minimal) and listening to customers (adding features) will only accelerate your path to replacement either by a product with more features or a product with less friction.
Low-Friction Design Patterns
Assuming you’re adding features to a product, the following are six design patterns to follow, each essentially reducing friction in your product. They cause the need to learn, consider, futz, or otherwise not race through the product to get something done.
- Decide on a default rather than options
- Create one path to a feature or task
- Offer personalization rather than customization
- Stick with changes you make
- Build features, not futzers
- Guess correctly all the time
Decide on a default rather than options. Everything is a choice. Any choice can be A/B tested or debated as to whether it works or not. The more testing you do the more likely you are to find a cohorts of people who prefer different approaches. The natural tendency will be to add an option or setting to allow people to choose their preference or worse you might interrupt their flow to ask preference. Make a choice. Take a stand. Every option is friction in the system (and code to maintain). When we added the wheel to the mouse in Office 97 there was a split in the team over whether the wheel should scroll down or whether it should zoom in/out. From the very first release there was an option to appease the part of the team that felt zoom was more natural. Even worse, the Word team went and did a ton of work to make zoom performant since it was fairly unnatural at the time.
Create one path to a feature or task. You add a new feature all is good—you’re in X in your product and then you can do Z. Then someone points out that there are times when you are doing Y in your product and you also want to do Z. Where there was once one path to get to a feature you now think about adding a second path. Maybe that sounds easy enough. Then a few iterations down the road and you have 5 different ways to get to Z. This whole design process leads to shortcuts, floating buttons, context menus, and more. Again all of which are favored by your early adopters and add friction for everyone else, and also add code. Pick the flow and sequence and stick with it. The most famous debate of all between Windows and Mac was over right click and it still rages. But the design energy to populate context menus and the cognitive load over knowing what you can or cannot do from there is real. How many people have right clicked on a file in the Windows desktop and clicked “Send” only to be launched into some Outlook configuration dialog when it would have been frictionless to always know that insert attachment in mail works and nothing will fail.
Offer personalization rather than customization. Early adopters of a product love to customize and tweak. That’s the nature of being a tech enthusiast. The theory is that customization makes a product easier to use because every use case is different enough that the time and effort saved by customization is worth it and important. In managing a product over time, customization becomes an engineering impossibility to maintain. When you want to change behavior or add a feature but it isn’t there or moved you introduce an engineering impossibility. The ability in Office to reorganize all the toolbars and menus seemed super cool at the time. Then we wanted to introduce a new scaleable structure that would work across resolutions and input devices (the ribbon). The problem was not just the upgrade but the reality that the friction introduced in using Office by never knowing where the menus might be (at the extreme, one could open a document that would rearrange the UX) was so high the product was unusable. Enterprise customers were rearranging the product such that people couldn’t take courses or buy books on how to use Office. The constraint led to the addition of a single place for personalization (Quick Access Toolbar) which ultimately allowed for a much lower friction design overall by enabling personalized efficiency without tweaking the whole experience.
Stick with changes you make. The ultimate design choice is when you change how a feature used by lots of customers works. You are choosing to deliberately upend their flow and add friction. At the same time the job of designing a product is moving it forward to new scenarios and capabilities and sometimes that means revisiting a design choice perhaps one that is the standard. It takes guts to do this, especially because you’re not always right. Often the path is to introduce a “compatibility mode” or a way to turn your new product into the old and comfortable product. This introduces three problems. First, you have to decide what the default will be (see the first rule above). Second, you have to decide if/how to enhance the old way of doing things while you’re also adding new things. Third, you have to decide when down the road you remove the old way, but in reality that will be never because you already told customers you value it enough to keep it around. But adding compatibility mode seems so easy and customer friendly! Ultimately you’re creating a technical debt that you can never dig out of. At the same time, failing to make big changes like this almost certainly means your product will be surpassed in the marketplace. See this HBS case on the Office 2007 Ribbon design http://www.hbs.edu/faculty/Pages/item.aspx?num=34113 ($).
Build features, not futzers. Tools for creativity are well-known to have elaborate palettes for formatting, effects, and other composition controls. Often these are built on amazing “engines” that manage shapes, text, or image data. Historically, tools of creativity have prided themselves on exposing the full range of capabilities enabled by these engines. These vast palettes of features and capabilities came to define how products and compete in the marketplace. In today’s world of mobility, touch interfaces, and timely/continuous productivity people do not necessarily want to spend time futzing with all the knobs and dials and seek to minimize time from idea to presentation—call this the Instagram effect. Yet even today we see too many tools that are about debugging your work, which is vastly different than getting work done. When a person needs a chart, a table, a diagram or an image how can you enable them to build that out of high-level concepts rather than the primitives that your engine supports? I was recently talking to the founder of an analytics company struggling with customer input on tweaking visualization which was adding complexity and taking engineering time away from adding whole new classes of visualization (like maps or donut charts). You’ll receive a lot of input from early customers to enable slightly different options or adjustments which will both challenge minimalism and add friction to your product without growing the breadth of scenarios your product enables. Staying focused on delivering features will enable your product to do more.
Guess correctly all the time. Many of the latest features, especially those based on machine learning or statistical models involve taking action based on guessing what comes next. These types of features are magical, when they work. The challenge is they don’t always work and that drives a friction-filled user experience. As you expand your product to these areas you’re going to want to find the right balance of how much to add and when, and patience with guessing too much too soon is a good practice. For better or worse, customers tend to love features that guess right 100% of the time and even if you’re wrong only 1% of the time, that 1% feels like a much higher error rate. Since we know we’re going to be learning and iterating in this regard, a best practice is to consider how frictionless you can make incorrect guesses. In other words, how much energy is required to skip a suggestion, undo an action, or otherwise keep the flow going and not stop to correct what the software thought was right but wasn’t. Let’s just call this, lessons from “bullets and numbering” in Word :-)
Finally, a word of caution on what happens as you expand your customer base when it comes to adding features. Anything you want to do in a product can be “obvious” either from usage data or from customer input. The challenge in product management is to create a core set of principles or beliefs about how you want to move the product forward that allow you to maintain the essential nature of your product while adding new features. The tension between maintaining existing customers via stability or incremental improvements versus keeping pace with where the marketplace is heading is the classic design challenge in technology products.
It shouldn’t be much of a surprise, but a great deal of product bloat comes from adding the obvious feature or directly listening to customers, or by failing to stick with design patterns. Ironically, efforts to enhance products for today’s customers are often the very features that add friction, reduce minimalism, and lead to overall bloat.
Bauhaus to Bloatware
This march from Bauhaus to Bloatware is well-known in our industry. It is part of a cycle that is very difficult to avoid. It is not without irony that your best and most engaged customers are often those pushing you to move faster down this path. Most every product in every segment starts minimal and adds features over time. At each juncture in the evolution of the product there is a tension over whether additions are the right marketplace response or simply bloat.
This march (and tension) continues until some complete rethinking introduces a new minimal product addressing most of the same need but from a different perspective. The cycle then starts again. Operating systems, databases, instruction sets, peripheral connection, laptops, interfaces, word processors, and anything you can name has gone through this cycle.
This re-evolution or reimagination of a product is key to the long term viability of any technology.
By adhering to a set of design principles you are able to expand the breadth of use cases your product serves while working to avoid simply adding more friction to the core use cases.
After publication three typos were fixed and the example of personalization clarified.
Apps: Shrapnel v. Bloatware
Much is being said lately about the trend to unbundle capabilities for the web and apps. Is this a new trend, a pendulum, or another stage in the evolution of providing software solutions for work and life? Are we going to learn what some would say are lessons from a past generation of software and avoid bloatware? Perhaps we will relive some of the experiences from that era and our phones and tablets will be littered with app shrapnel as our PCs once were?
My own personal experience in product choices is marked by a near constant tension over not just bundle v. unbundle from a product perspective, but also from a business perspective. Whether on development tools, Office, Windows, or internet services I’ve experienced the unbundle <> bundle dynamic. I’ve bundled, unbundled, and had the “internal” debates about what to do when, what went well or not. If you’re interested in an early debate about bundling Office you can see the Harvard case study on the choice of “best of breed v. suite” in Finding the Suite Spot ($).
The Pendulum
This HBR article does a good job of bringing forth some of the history and describing the challenges of positioning unbundle/bundle as both a binary choice and a pendulum or Krebs-like cycle of resource conservation. Marc Andreessen does a great job in these two tweetstorms of detailing the bundle/unbundle cycle on the internet and the computer history we both grew up with (http://tweetstorm.io/user/pmarca/481554165454209027 and http://tweetstorm.io/user/pmarca/481739410895941632).
There’s one maxim in business that drives so much of the back and forth or pendulum behavior we tend to see, which is that most strategies have a complementary approach (vertical v. horizontal, direct v. indirect, integrate v. distinct, first v. third-party, product org v. discipline org, quantitative v. qualitative performance evaluation, hack v. plan, etc.) So in business depending on your roots or your history, and most importantly the context you find yourself, you are going down a path of one of more of these attributes.
Over time your competition tends to pick you apart the other way or ways. Equally likely, your ecosystem builds up around you innovating in parts where you are weaker, gaining strength, and showing off new approaches to product or market. Certainly, if you’re a new company entering an established market you will not just copy the approach of the incumbent which is why new products seem to be at the other end of one of these spectrums.
Then as you get in trouble you look around and try to figure out what to do. There’s a good chance the organization will double down on the approach that has always worked—after all as Christensen says, that is the natural energy force in an organization. That happens until a big moment of change (a major competitive success, leadership change, etc.) and then you change approaches. More often than not, your choice is to do the thing you weren’t doing before. If you’re around in the workforce long enough, you start to see things as a series of these evolutionary steps.
This is business, context is everything. There’s never a right answer in absolute, only a right answer given the context.
The moments of change, of breaking the cycle or swinging back the other way, are the moments that unleash significant improvements in the work, the product, or the workplace.
History and Customers
As consumers we adopt new technologies without realizing or thinking about whether they are bundled or unbundled, and our choices and selections for one or other are highly dependent on the context at the time. There are times when bundling is essential to the distribution of technology, just as there are times when unbundling brings with it more choice, flexibility, and opportunity. Obviously the same holds for businesses buying products, only businesses have purchasing power that can make bundled things appear unbundled or vice versa.
It is worth considering a few tech examples:
- Autos began with minimal electronics, followed by optional electronics, then increasingly elaborate integrated electronics and many now think that smartphones will be the best device for in-car electronics/apps (for example the BMW i series).
- LinkedIn began as a network for professionals to list their credentials and connect to others professionally. Recently it has bundled more and more content-based functionality.
- Mobile telephony used to have distinct local, long distance, text and then data plans, which have now been bundled into all-you-can-consume multi-device plans.
- Word processing used to have optional spell-checking and mail merge which was then bundled into single products which were then subsequently bundled into suites and also now bundle cloud services. Similarly, financial spreadsheets, data analysis, and charting were previously distinct efforts that are now bundled. Today we are seeing new tools that have different feature sets and approaches, representing some unbundling and some bundling.
- Operating systems were once highly hardware dependent, then abstracted from hardware but with optional graphical interfaces, followed by a period of bundling of OS+Graphics, followed by a bundling of OS, graphical interface, and hardware in a single package. Today with services we’re seeing different combinations of bundling and unbundling innovations.
- Microprocessors have been on a fairly continuous bundling effort relative to peripherals, graphics, and even storage.
- Modern smartphones are a wonder of bundling, first at the hardware level (SoC packaging) followed by hardware+software, then through all the devices that were previously distinct (GPS, still camera, video camera, pedometer, game controller, USB storage, and more).
There are countless examples depending on what level in the full consumer offering is being considered (i.e. product, price, place, promotion). Considering just these examples, one can easily see the positives and potential pitfalls of any of these.
Yet in looking these examples and others, one can make a few observations about how customers and teams approach bundling choices for products and services:
- People like distinct products when exploring new capabilities and product teams like building single purpose tools early in product lifecycle, out of both focus and necessity/resources.
- People like it when their favorite product adds features that previously required a separate product, especially when their favorite product is growing in usage. Product teams love to add more features to existing products when those features map to obvious needs.
- People have some threshold for when an integrated product turns into an overwhelming product, but that “line in the sand” is impossible to define a priori and depends a great deal on how products are evolving around your product. Mobile phone plans today are great, but many are very unhappy with Cable TV bundles.
- Competition can come from a bundle that you were previously not considering **or** competition can come from unbundling the product you make.
- Product managers often reach a point where they can no longer solve the problem of adding new features while seeing them get used and also getting credit for innovating.
- Macro factors can radically alter your own views of what could/should be bundled. If your business does not have a software component and your competitors add one, attempting to bundle that functionality could be quite challenging (technically, organizationally). If the platform you target (autos, spectrum, screens) undergoes a major change in capability then so too does your view of bundling or unbundling.
These examples and observations make one thing perfectly clear: whether to bundle or unbundle features depends a great deal on context and customer scenarios and so the choices require a great deal of product management thought. The path to bundle or unbundle is not linear, predictable, or reactionary but a genuine opportunity and need for solid product thought.
Strategic questions
On the one hand, considering whether to bundle or unbundle innovations might just be “do what we can that is differentiated”. In practice there are some key strategy questions that come up time and time again when talking to product folks.
- Discoverability. The most critical strategic question to bundle or unbundle is whether the new work will be discoverable by intended customers. In a new product, the early waves of innovative features often make sense bundled. Over time, just responding to customers means you’ll be bundling in new capabilities (whether organic or competitive).
- Usability. When faced with a new feature or business approach, the usability of this approach is a key factor in your choice. If you’re unable to develop a user experience that permits successful execution of the desired outcome, then it doesn’t really matter whether your bundled or unbundled.
- Depth. When making the choice to bundle or unbundle you have to think through how much you plan on innovating in the spaces. If you’re setting yourself up for a long-term head to head on depth versus believing you are “checking a box” you have different choices. Incumbents often view the best path to fending off a disruptive unbundled feature as adding a checkbox to compete (to avoid the trauma of a major change in approach). Marketing often has an urgency that drives a need for market response and that can be represented as an unbundled “add-on that no one cares about” or “a checkbox that can be communicated” — that might sound cynical until you’ve been through a sales cycle losing out to a “feature as a product”.
- Business economics. If you charge directly for your product or service (or freemium), then there will be a strong incentive to bundle more and more into your existing offering. Sales will generally prefer to add more features at the current price. Marketing will potentially advocate for a new pricing level to increase revenue. If you choose to unbundle and develop a new product, side-by-side or companion, then you’ll need to consider what your attach rate might be. A bundled solution essentially sees a 100% attach rate to your existing product whereas a whole new product brings with it the need to generate demand and subsequent purchase or usage. An advertising-based service will see increased surface area for an unbundled solution but will also dilute usage. A web-based service allows for cross-linking and easy connection between two different properties, but apps will require separate downloads and minimal cross-app connections.
- Usage economics. It might sound strange separating out business from usage, since especially in a SaaS world they are the same thing. In practice, if you’re revenue is tied to usage directly (page views, transactions, etc.) then your design needs to factor in how you measure and drive usage of the features, bundled or unbundled. If you’re economics are not tied directly to usage you will have more strategic latitude to consider how your offering plays out bundled v. unbundled (assuming your boss lets you keep working on something no one uses).
Product management approach
Should you add that new feature or capability to your existing product or should you create a new destination (app, site)? Should you break out a feature because unbundling is the new normal or will that just break everything? Those are the core questions any PM faces as a product grows.
One tip: do not claim that one approach (bundle v. unbundle) is good for users and the other approach is only good for business. In other words, bundle v. unbundle cannot be distilled down to pro-user or anti-user, or more importantly marketing v. product. The best product people know that context is everything and that positioning a choice as A against B is counter productive—everyone is on the same team and has the same broad goals. As difficult as it is, working through these questions with as much dialog as possible and as much “walk in the other’s shoes” is absolutely critical.
There are many natural forces at play that will drive one way or another.
For example, most organic product development will tend to expand the existing product as it builds on the infrastructure and momentum already present.
Most new acquisitions will tend towards acquiring unbundled solutions, aka competition, though in the enterprise space one can expect significant calls to integrate even disparate technologies.
Part of being a good PM is to step back and go through a thoughtful process about whether to bundle or unbundle new capabilities. The following are some design choices.
- Advertising new features in proportion to expected usage. There’s a general view to advertise a new feature in the UX in an excessively prominent manner. You want people to know you fixed or added a feature. At the unbundle extreme this means a whole new app and a trend to shrapnel. In the bundle extreme this means a big UX to drive you to a new thing. The most critical choice is really making sure that you are designing the access to the feature to be in relative proportion to how much you expect your customer base to use something.
- Plan for “n+1” in all experience choices. As you make the choice to bundle or unbundle, know ahead of time that this will not be the first place you make this choice. If you’re adding a new app today then chances are that will become the way you solve things down the road. If you’re adding new UX access to a feature then plan on more depth in that feature or more peer features. Is the choice you are making scalable for the growth in creativity and innovation you expect?
- Integrate or connect in one direction, not both. If you bundle or unbundle there will be a relentless push to promote the connection between elements of the product or service. Demo flows, top-level UX, even deep linking between apps. At some extreme if you bundle n items, it might not be unrealistic to go down a path where every n is connected to every other n-1 and vice versa. This is incredibly common in line of business apps/modules.
- Bundle and innovate, don’t bundle and deprecate. If you make a choice to bundle a capability into your mainline effort, do not bundle it to make it go away. Bundle it and think of it as just as important as other things you do. This dynamic appears when your competition does something you don’t like so you hope to have a checkbox and make the competitor go away. This never happens.
- Designing for good enough leaves you open to disruption. Closely related to deprecating while bundling is the idea that a “tie is a win”. Once you’re established you often think that you can continue to win against a competitor with an integrated implementation that is “good enough”. That might work in short-term marketing but over time, if the area is important you’ll lose.
- Expect hardware to be relentlessly bundled. If you connect to hardware in any way, then you’ll be faced with a relentless march towards bundling. Hardware naturally bundles because of the economics of manufacturing, the surplus of transistors, and the need to reduce power and surface area. Never bet on hardware or peripherals staying unbundled for long.
- Expanding software depth is easy, but breadth often adds more value. Engineers and product managers love to round out features, add more depth, more customization, and more incremental improvements. This is where the customer feedback loop is really clear. In terms of growing the business and attracting new customers, expansion in breadth is almost always a better approach so long as you “bundle” features that seem natural. Over indexing on depth, particularly early in a product life-cycle leaves you open to a competitor that does you plus other valuable things, no matter how much you think you’re unbundling approach is cleaner and simpler.
- Defined categories do not remain defined for long. In enterprise products the “category” or “magic quadrant” is everything. In practice, these very definitions are always in transition. Be in the lookout for being redefined by an action of bundling or unbundling.
- Assume sales and marketing will prefer new capability to be bundled, or maybe not. Finally to highlight how contextual this is, there is no default as to how outbound efforts will prefer you approach the problem. It is not necessarily the opposite of what you are doing or the same as a competitor. For example, if your sales force economics are such that they are strongly connected to a single product and sales motion, it will be clear that bundling will be preferred no matter what a competitor is up to. At an extreme, even an unbundled feature will be used as a closer or a discount, particularly in the enterprise. Conversely, even if your competition is highly bundled, you’re own outbound efforts might be structured such that unbundling is a competitive and sales win. You just never know. Most importantly, the first reaction isn’t the way to base your approach—spend the time to engage and debate.
To bundle or unbundle is a complex question that goes beyond the simplistic view that minimal design makes for good products. Take the time to engage broadly across the team, organization, and to project forward where you want to be as these are some of the most critical design choices you will make.
–Steven Sinofsky @stevesi
The Price Is Right: For Early-Stage SaaS Companies, It Needs To Be
Nothing is more critical to a software-as-a-service (SaaS) business than pricing strategy. Pricing is the moment of truth for a new product … and doubly so when it is a company’s first product. But far more often than not, I’ve observed new startups leaving “money on the table” when it comes to pricing enterprise products. I’ve seen founders say their product saves hundreds of thousands of dollars — yet their product is priced as if it’s only saving thousands of dollars.
One reason for this is assuming the need to price and program similarly to competitive products. With a potentially disruptive product, however, falling into the trap of pricing like a legacy competitor not only leaves money on the table — but it could fail to surface your differentiation. Said another way, your product is your price and how you price your product reflects value from the buyer perspective as well as what your company believes is valuable. SaaS products also have the advantage that they are priced not just for the service they offer, but for the potential of saving massive capex/opex spent directly by the customer.
From your business perspective, SaaS products have a level of stickiness that would be the envy of the packaged-and on-premise software generation.
Since the uncertainty and social science aspects of pricing can be uncomfortable, especially for technical founders, here is a framework — from the perspective of a product manager — to consider when pricing new SaaS products. The product manager role is critical in SaaS because the ability to fine-tune the monetization of the product is closely tied to its features and implementation. The product needs to be designed with such flexibility in mind when it comes to making features available, prioritizing features, or even just choosing where to spend engineering time.
Just remember that “business isn’t physics”, as Bill Gurley notes in his excellent post on some of the metrics here. Andreessen Horowitz also has a detailed primer on understanding SaaS valuations as great background for pricing discussions. Because pricing is math, there’s a tendency to create the spreadsheet model and assume it will all work. But there’s also a ton of psychology that comes into play: beyond math, pricing involves judgment, vision, and flexibility.
How do you solve an unsolvable problem? Bound it.
In a new business, it’s easy to spend money, but the combination of a new product and the unknown cost of acquiring customers leads to an “unsolvable” problem. One approach is to take lean/iterative methods and apply them to finding the right pricing fit. This post is about a framework to arrive at such early prices, which will change. (This is very different from what happens in an existing company with existing customers, where you really only get one shot at pricing something right).
The business side of SaaS involves a complex array of variables such as customer lifetime value (LTV), customer/subscriber acquisition cost (CAC), average revenue per user (ARPU), cost of goods sold (COGS), and churn; as well as pricing models such as freemium, tiered, and time based. Then, depending on whether you’re targeting consumers or enterprises, there are very different sales models that influence your pricing approach (for example, business products invite complexity, especially when dealing with purchasing managers). Similarly, the product side of SaaS is a complex set of equations related to usage patterns, scenarios, and variable costs of a large number of resources.
The most critical costs are related to customer acquisition and sales/marketing expense — which can appear to erase any potential for profit by traditional accounting measures — so the key to early-stage SaaS businesses is to focus on understanding customer acquisition costs relative to the estimated long term value of a customer. Since we don’t know how much it will cost to acquire a customer yet, we will just have to move forward assuming some budget (along with some allocation for margin in the ultimate price relative to this long term value). This post focuses on the pricing models relative to product and features and assumes a higher level view of customer acquisition costs and long term value.
One way to approach this is to establish upper and lower bounds on pricing:
A lower bound for your pricing
The lower bound represents your costs to serve a customer your product. One common example is the basic costs of spinning up the IaaS/PaaS elements of what you do — creating accounts, allocating minimal resources, other infrastructure, and then subsequent usage.
It might be convenient to think of this lower bound as what you could offer for “free” to some customers. You might make some assumptions about the use of variable resources such as compute, egress, storage, etc. in order to arrive at this lower bound. (Note, since this is a product-centric view these bounds are absent the allocation for fixed and variable costs outside the product/technology, so do not not include opex, S&M, etc.)
It is important to understand this bound across the full breadth of your product. While you might initially view some features as “premium”, you also want to assume that over time capabilities will migrate from advanced to essential and you will fill in new features at the top. I think it is a good exercise to consider the full product as a base case initially.
An upper bound for your pricing
The upper bound represents your costs to serve a “depth” user: in this case, the customer using the parts of your product that drive ongoing costs to scale (for example, this customer is using increasingly more bandwidth, storage, or compute). Now this is where you can look at what you offer relative to your competition, and want to understand if you have scale attributes that are better/worse/same. By knowing this you can begin to separate out variables for your model.
Presumably in developing your product, you created a unique architectural approach relative to existing competitors. Do you scale better for more tenants, use storage more effectively, or maybe your mobile app is more efficient at bandwidth? The importance of knowing your own strengths and weaknesses will inform what variables to use in your pricing.
You can also think of your upper bound as a competitive foil — the stronger you are on some attribute, the more you should use this attribute to differentiate your offering. This might allow you to charge more for capabilities that are just too expensive for your competition.
These are the core attributes for pricing
When you’re pricing a new offering, it is worth understanding where your product is today relative to a core set of potential pricing attributes.
Whether it is Bronze/Silver/Gold, Free/Select/Premium, Trial/Select/Premium, or Individual/Business/Enterprise, the norm for SaaS is to offer a “3xN” matrix of 3 pricing plans and N attributes — as inthese examples. The more mature a SaaS product, the more rows and columns its matrix has. (One SaaS product I researched had five top-level features organized into an array of 27 price points based on combinations of the three to five of the features and number of users.)
A broad range of SaaS products can be considered across the following core service attributes:
Features
If your product lends itself to dividing the features themselves — such as import/export, visualization, view/edit, or connectivity to other products — into good-better-best then differentiating price points here might work. In a freemium model, dividing must-have features among free v. paid users can be a customer-hostile way to differentiate or optimize pricing, so beware.
The reason to hesitate on this dimension is because customers understand that you’re basically just inhibiting access to code that is already there and hence being draconian. Another reason to be cautious with this model is that as usage of the product deepens over time, paid features will tend to get pulled into lower-priced tiers — which means you need to fill in new features/prices with every release or update. As easy as it is to communicate general-use features in pricing tiers, there’s a level of distaste with this approach for many customers.
Administration/IT
One of the most common approaches to differentiating a SaaS product designed for business is to separate out the IT-focused features as a pricing attribute. These could be features for security, audit, identity integration, domain names, sharing, control, management, etc. Businesses understand what it is like to both value and pay for these features.
Commonly this approach is used to rectify a product that has become viral within an enterprise, so be careful about how you approach an enterprise with pricing here. Otherwise you might come across as an arsonist-firefighter who is offering to contain the very situation you knowingly created.
Scale in consumption
Another broadly used SaaS pricing attribute is storage consumption (even for products for which storage is not a primary attribute): It’s easy to measure, easy to articulate, and is relatively expensive. The benefit of using storage is that people “get it” to some degree. It also gets cheaper faster than people can consume it (and in most scenarios customers need to be doing something fairly extreme to consume vast amounts of storage). At the same time, the platform companies have been steadily increasing free storage or ultra-low priced storage as a base, no-frills service so simply using storage as a one-dimensional offering might not work. With a new SaaS product, be sure to consider ways to avoid basing costs on storage given challenges.
One novel approach seen recently is using third-party storage and letting the customer establish a paying relationship such that storage is not part of the pricing of your product, since that way you do not serve as a pure pass-through for a visibly priced third-party element of your product. There are many novel attributes in modern software that can be used as consumption variables; one relatively new one is to use depth consumption of APIs/calls as a price tiering structure. (Box, where I’m an advisor, recently announced pricing for Box APIs as an example.) Developer-oriented products work especially well for consumption pricing because developers understand the product architecture and what can drive costs, even if those costs are variable with usage.
Scale in consumers
SaaS products used by small teams, cross-organizations, or that just scale with more members collaborating/sharing/using are almost always priced by number of unique users (and subsequent integration with organization-based directories). Pricing this variable is straightforward and over time you will see distribution of engagement and resource usage that will further let you refine the discrete price points.
Because most products priced this way also want to encourage more users/usage, carefully consider where you put the first step or two. But large-scale customers like this approach because it allows for predictable pricing on a metric they understand: number of employees/users. In general, you can think of this as per-seat pricing but can also apply to device end-points, servers/CPUs, VMs, etc.
Segmenting your customers
Every product is used by different customer segments — whether measured by size of organization, industry segment, geography, or type of individual within an organization. Common pricing tier labels here include “government”, “non-profit”, “academic”, “healthcare”, “small business”, and so on.
As a product matures, you will almost certainly either label or expand your pricing tiers to account for this. Before you jump into this level of differentiation, however, you want to gain more data on usage — are you seeing customers across some set of segments, and are they using the product differently? More importantly, do you see a path to develop differentiation that allows you to target and sustain these segments (or are you just optimizing revenue along these lines)? Some products are designed only for specific segments like education, which allows you to further refine within them: e.g., public, private, post-secondary, etc.
But one customer segment that is almost always special is the engaged technical user. These folks can push a product through an organization when required, or develop custom solutions on your platform that either deliver or enhance the value of your work.
Developers are key in this regard. For any platform-oriented product, it is worth considering how you offer developers the ability to experiment with and use the full product in a development environment at a very low price. One way to accomplish this is to separate out usage-as-development versus usage-as-production, and price accordingly.
* * *
As a new offering with any established competitors, pricing will be the easiest point of attack. And if you are a disruptive product, you want to have the deepest possible understanding of the value you are bringing to the table so you can maximize the initial pricing model. So the most important suggestion for pricing I have here is to wait until the last possible moment to price and announce.
Even for enterprise products, things like round-numbers, 9′s, and discounts all matter. Do keep in mind that discounting will be substantial in enterprise products with direct sales and 50% or more off “list” price is not uncommon (and often required). That’s not an excuse to bloat the price, but it is important for purchasing managers and for empowering your salesforce that you enable a level of customization — and know what variables you are using to do so.
Some say that you can never change or raise your prices once you’re out of the gate. Always keep in mind that once you have customers, price changes or product composition relative to price are never viewed as positive changes, even if you think for some customers you are lowering the price. And when you do change your prices, always offer existing customers time to adapt and grandfather them in (at least). Finally, remember to engineer a product framework that can support pricing flexibility.
Create the model, use the model, but don’t let the model do your thinking. Price carefully!
–Steven Sinofsky (@stevesi)
This post originally appeared on TechCrunch.
Everyone starts with simplicity, no-one ends there and that’s OK
Designing a user experience for many millions of people is a unique job that a relatively small number of people practice. The responsibility of such an undertaking is immense, stressful, and one that can be all-consuming. Cold sweats, sick to your stomach, and a constant feeling of messing up are the norm for those that take on these challenges.
But someone has to do it!
This week brought quite a few big design changes that have folks talking including twitter adding mute, gmail testing out a major revamp, and iOS 8 bringing “Surface split-screen to iPad”.
Everyone starts with simplicity, then what?
At introduction almost every successful product champions simplicity as a design and execution goal. Products are declared simple, minimal, and tailored to specific uses. Almost no one argues against these attributes and when marketing goes to position a tech product, invariably these attributes bubble up to the top of the favorable list. That’s because of the inherent and expected complexity of tech products as a starting point.
At introduction almost every successful product champions simplicity as a design and execution goal.
But where to go next? Tech products that are simple can start off well, but three things exist immediately after launch.
- A customer need to address feedback and “fix” things that might be simple but are not quite there yet.
- A product need to remain competitive with the products that follow your introduction touting the same simplicity but also do a few more things (reading the reviews of your product will always demonstrate examples of wish lists)
- A business need to develop new products that can enhance revenue, margins, or maintain price points in the face of commoditization.
Tech products, particularly software products, are unique in that there is an almost natural tendency to organically add or to absorb features from competitive or adjacent products. Unlike physical hardware products that have COGS and BOM challenges, the incremental cost of software is simply limited to R&D (and operational costs for SaaS). That means when faced with the above existential properties, tech products will get new features pretty rapidly.
These new features will do constant battle with the simplicity of the initial release. Some argue that this is just bloat and invariably ruins products. Certainly from a design perspective this is a massive challenge. It takes enormous discipline. On the other hand, there are very few examples of software-based products that remain static. To remain static in features is to open yourself up to commoditization or disruption—a static target is an easy target.
Example: Palm Pilot
The introduction of the Palm Pilot (http://en.wikipedia.org/wiki/PalmPilot) is a fascinating historic example of simplicity leading to isolation and expiration of a product. The designers of the product did an amazing job building an amazing product. All day battery life, simplicity, specific and purpose-built as the first truly modern and truly mobile productivity tool used by the masses.
I remember in 1998 the Palm Pilot was standard issue for all new MBA students when I taught. Shortly after that time, I recall a panel discussion with one of the original designers of the product. At the time the pitch was overarching simplicity and ease of use. Everyone agreed. Then there was an audience question that changed the dynamic.
Most leading edge folks at this time were carrying Motorola flip phones along with the calendar/notes/contacts in their Palm Pilot. The problem was every time they wanted to make a call, it was a multi-step process that involved looking up a number on the Palm Pilot and juggling the two devices while typing into the phone. While this was vastly easier than going back to your desktop or attempting to pull an 8lb laptop out of your bag, it was a usability disaster.
The question was simply—when could I have all the Palm Pilot functionality on my phone? Lots of words about how you could sync (with a cable, not the cloud that didn’t yet exist), but a hardcore answer about how adding a fifth function to the Palm, a phone, would overload the functionality and make the product too complex and unusable. So the phone would never converge with things like your contacts and calendar.
Honest, that was the answer.
The problem was I was sitting there with my pre-production blackberry merrily connecting in real-time to my calendar, contacts, and email on my Exchange server. It was incredibly clear that the need of a non-converged device with a static copy of some of the important mobile tasks was no longer useful.
A pattern for how things evolve in practice
This challenge in software product design happens time and time again. It is the very nature of disruption. The new product does some things brilliantly well and simply, but is “missing” features people value from an existing product or an adjacent product.
Designers face the choice of adding new capabilities and potentially challenging the beauty of the initial release or facing competition and disruption from new competitors without that same strongly held belief. Marketing, channel, business and pricing can defend against these for a while but ultimately the ease and costs of just adding features in software will win.
The tension between user interface design and the realities and capabilities of software leads to a fairly predictable pattern for how tech/software products evolve. We can think of this pattern as evolution in five stages:
- Introduce
- Optimize
- Deliberate
- Succumb
- Mature or Renew
Introduce. First you introduce a new product. In your view it is a thing of beauty. Whether you spent 3 years or 3 months, you are convinced it has exactly the right features done exactly the right way, though you know there are ton of things on your “to do” list. Even if you are practicing lean methodologies you are pretty sure you got it right in your heart even though there is a lot of learning to follow. Your design embodies simplicity in design and messaging. Once your product starts to get used and you have the luxury of people relying on your work you begin to see the holes and maybe even misfires in your experience design. Optimize. You have a lot of work to do to reconcile your “to do” list with what actual people using your product. It turns out that what you thought the product was missing is pretty different than what everyone else thought the product was missing. You shrug this off and take the feedback seriously because you have real-world people using your product. Quite often the innovations introduced at this stage are formalizations for how people were using your product. Add-ins, customizations, or just conventions that enhanced usage become the sorts of things you formalize in the product. You very quickly iterate and get to a much more robust, reliable, stable, and usable version of what you had originally envisioned. This becomes the foundation of your product.
Deliberate. Evolving your product at this stage is very fun. While you believe you have a product that embodies your vision, with usage you begin to see broader usage and scenarios as part of your product. There might be third parties that do similar things as you but with a slightly different or much improved take on a specific mechanism you have in your product. Because you have become a leader with your product in “the way” things are done, when you decide to introduce an innovation it comes as a deliberate and thoughtful extension of your experience. Rarely do you see pushback from a broad base of customers when something new is introduced at this stage in your product’s evolution. In fact you often are seen as taking the product to a new level and providing a broader context in which your whole category or class of products should evolve. You are basking in the glow of innovating in the user experience of your space—you have come to define the category and now you’re defining the category to include new elements of user-experience.
Succumb. The feedback your product is receiving is growing, both positive and negative. As your product is used more and more, the usage scenarios and skill-levels of your customers change dramatically. Your product is used in ways you could never imagine and customers are asking for your product to do things you would never have imagined they would ask. If your product becomes essential for some scenario, then people will ask for your product to take on attributes and features of other familiar products (if you share photos, then you’re likely to be asked for photo editing for example; if you communicate, then before long you will be asked for rules and filters; if you type then you will be asked for more and more formatting, spelling, and entry features). If during the previous stage you really believed you had achieved a level of almost Bauhaus minimalism about your product, this is the stage when you feel a relentless pressure to add more. You’re hearing from customers, pundits, press and more about the must-haves and must-dos. This is by far the most stressful time in product development—you can’t just step back and not change things, but you constantly feel like changes are all part of a slippery slope. You constantly find yourself struggling between the minimalist view of the product you have been perfecting and the need from different types of customers for seemingly contradictory types of features. It is why at this stage as a designer you feel like you are succumbing to feedback and introducing features that you know some people will value and others will see the other way or maybe just not even notice—you feel like you’re bloating your simple product. These are the hardest decisions to make and are the price of success. If you try to hang on to simplicity, you will see competitors pass you by or you’ll see engagement stagnate.
Mature or Renew. The natural evolution of most every product involves a fairly long period of incorporating features in the previous stage—you add some new things, incrementally change some existing things, and in general are working to find a path through the maze of contradictory feedback and complex market needs. Over time your product will develop a different personality and unique set of assets, but is going to be far from that original version. While you might have hundreds of millions of customers, at some point the experience of your product is such that the market collectively demands an overhaul. The challenge of course is that the collective market is very different than any one individual or an organization (for enterprise products). The latter two, unlike the aggregate view of the market, do not necessarily embrace change. This point in the evolution of your product is where you face disruption—the telltale signs of reduced engagement, alternative tools and experiences, or just a lack of energy in your ecosystem are signs that your product is overdue for improvements, new features and more. Software affords you the chance to reimagine your product and presents you with the opportunity at this time. Of course with hundreds of millions of customers, a very large number in absolute will not want any change at all. That’s why this stage of evolution is a choice—you can incrementally mature your product design or you can choose to renew your product design. These two are really that very rare of “either-or” choices. As a product designer, you will be faced with a big set of decisions when you have to design what comes next for a mature product. Be careful what you wish for you as your design might be so successful that one day you face the prospect of redesigning it in the context of a significant customer base.
Products reaching a mature stage face a fork in the road.
Products reaching a mature stage face a fork in the road—one where you can renew or watch your product slowly shrink in relevance. This might seem dramatic, but the velocity of change in the technology world combined with the ease of switching shows that one day what might seem like “the way things are done” will risk becoming “the way things used to be” much sooner than expected.
Disruption and technology transitions are part of the context of designing products and experiences.
From search home pages, to photo editors, word processors, operating systems, music players, and more these stages are all part of the evolution of a user experience. The beauty of software interface is that unlike the physical world you are given the chance to move things around, change, and improve the product for little to no manufacturing cost, but at each stage you have to work through the cost of change to customers.
No other product in history has had the ability to be used by so many yet be so flexible in how it is used.
Simplicity in design is what we all strive for and often how we begin a product lifecycle. With success, maintaining simplicity over time while also remaining competitive is where design and product management are really challenged.
The “soft” of software makes this challenge even more acute and the pressures to add or change a product even more difficult to resist.
–Steven Sinofsky (@stevesi)
Designing for BYO, a product manager view
Many companies I work with are creating tools to enhance workplace or personal productivity depends on the “bring your own” or BYO movement to get their product bootstrapped or to just get in the door. Once in the door, the product design challenges of BYO begin.
After those first customers they count on broader, viral, usage within a company to drive revenue growth. While they likely built your product with the notion that “customer equals purchaser” once this changes to “business equals purchaser”, you are going to get a whole different level of feedback.
My guess is most every app and service is both excited and terrified to get to the moment when there is a choice between cozying up to IT and risking alienating your newly minted enthusiasts. It is, by all accounts, a choice. Most I talk to feel like they will navigate this by focusing on customers first and hope to overwhelm the negatives often associated with IT.
Walk that fine line to enable your product to be at some state of détente with IT.
Get over it. Not entirely of course, but there’s some subtly at play. At some point you are going to face a fork in the road; navigate enterprise management or face existential challenges. You can choose to be managed without your cooperation or worse blocked and literally unable to access important assets that your product requires. Alternatively, you might also choose to walk that fine line to enable your product to be at some state of détente with IT.
I know that sounds awful and while I am sure there are some exceptions (in both organizations and products), this is by far the most normal path. It doesn’t have to be a sell-out, but when done well you can bet that you’re going to be in great position to advance the state of the art and contribute positively to enterprise infrastructure.
In fact, as I was typing this post there was this thoughtful article on putting customers first in business apps.
The essence of BYO is that one can easily acquire and begin to use a device, product or service without IT involvement of any kind. You might need to know the server name for email or maybe how to export data from a line of business system, but otherwise the device or app can tap into the necessary resources without first going through IT and/or purchasing. Even better, these tools likely make it very easy to share information with coworkers or collaborators at other organizations. All folks need is a free email account as a gateway to sharing.
Of course all this ease of use has at least two main IT downsides.
First and foremost is security of the network overall. Devices on a network, running code of unknown origin, tapping into servers is a big risk. What can be transmitted by those devices and apps concerns IT. Inbound PDF attachments or simple USB sticks seemed harmless enough at first until they became a massive vectors.
Second, the data and servers being accessed contain information that you need to use but do not own. These are corporate assets and managing and tracking those is a fiduciary responsibility for IT and in some cases such as HIPPA or SEC regulations the penalties for messing up are severe. That simple case of putting something like logmein or internet messaging can potentially become a significant liability.
My own personal experience “helps” me to see this pattern. Working on Microsoft Office in the early days, we were very clearly a “bottom up adoption” product. People were going to stores and buying the product with their own money and creating amazing looking documents they would bring into work (often on PCs bought with personal funds at those same stores). Pretty soon groups of people were using corporate expense accounts to acquire “5 packs” of Office. Then over time, Microsoft grew an enterprise sales force that could offer large deals.
That’s the sales side, but on the product side the management and deployment of the product (deployment being decidedly old school now) became unwieldy. As a result, the late 1990’s saw a movement to reduce so called “TCO” or total cost of ownership. TCO mandated a vast number of controls across the entire platform and from that grew a whole generation of features from the registry, to logon scripts, to the, now, dreaded “corporate desktop”. TCO reached an epic volume as it described owning a $1500 PC as a $20,000 per year expense to companies.
While I was dragged kicking and screaming to deliver features that I felt could be used to make the product worse, the reality was at the time this is also what grew the business. The tradeoffs, debates, and design choices were all very real.
In a startup, these choices are much more existential than they were for us back then. Given the hurdles to overcome to become a widely used tool, there’s a good chance you might want to be more proactive about how your product fits with BYO.
As a product manager facing this decision point, you have this intense belief that IT wants to make your product worse, harder to use, and to basically ruin your good work. The fact that so few built-for-IT products have the design sense, usability, or approachability of apps and services focused on consumers only reinforces this.
While there are dozens of potential traps and pitfalls that can result in a product falling out of favor, it is a good idea to consider a few important design choices you can make now that will enable your consumer and BYO product to be viewed through a positive light. It is important that these design choices be considered product assets rather than object handlers.
Ultimately, if you design a product to be used in business where you can charge more it should be better, not worse, than a product used in the consumer space. It used to be that the business versions of products charged more so they could do less and be harder to use and acquire. The SaaS and App models invert this. Phil Libin, founder of Evernote, says it best when he says “business class means superior and we challenge ourselves to make our product better when you upgrade to the business version”.
Business class means superior and we challenge ourselves to make our product better when you upgrade to the business version. — Phil Libin, Evernote
The following are five product areas to consider when it comes to making a product business ready:
- Identity and authentication. The first thing a business needs from a product is that employees should sign into the product using the business-owned credentials (such as Active Directory). This allows IT to send a clear message to the individual that they are operating in a business context. This needs to include authentication mechanisms used at the organization and enforce associated password policy and security. At the same time, you owe it to your own ease of use that stand-alone credentials can be used, especially for collaboration. How you manage the bridge and the commingling of credentials depends on the flow of assets through your product.
- Network usage. IT organizations guard their network across several dimensions. Platform providers make it possible to use VPN (secured with enterprise credentials) or other access methods for WiFi. Your product should use well-known/documented ports and be clear with IT about what travels over the wire and in what volumes. Techniques like polling, using obscure ports, and more will only hinder your product usage.
- Changes related to re-orgs. In an organization of any size employees quit, vendors are fired, or staffing on a project just changes. If your product is used across a group of people then IT will want to be there to assist in supporting these changes within your product. How can content remaining on devices be recalled or how can a person lose permissions to content are important design choices you can make in building a product that it BYO friendly.
- Content “ownership”. If your product creates or consumes content then your product owes it to IT to participate in the content management responsibility of the organization. At one extreme, the clipboard exists on IT apps and in every other app so you can dodge this question by saying it isn’t your exclusive responsibility. On the other hand, by having mechanisms for IT to have some telemetry and actions on content then you invite your product to be desired by IT, not just challenged. More than any other area this is where many potential solutions exist and many possible ways to make the product worse or upgrade to business class.
- Features. Products are more than editors and tools for sharing, so there are going to be unique features in your product. Some of those unique features will intersect in ways that might run counter to a business policy. Sometimes this could be simple such as an ability to generate email notifications which might be frowned upon. Other times it might be complex as a feature runs directly afoul of regulatory compliance. At some level there are going to be features you give IT permission to enable/disable. No area is more challenging of course and thinking hard about the design tradeoffs when a feature might not be there is important. A feature like password protection might be great for consumers but becomes a huge problem for IT when personnel change. Alternatively, you might have a feature that becomes a “must use” and if that’s the case you want to consider how something you might have thought of as optional becomes permanent. For example, you might optionally support a confirmation email when adding new people to a project and IT might require that email be sent to produce a record of access changes.
There are many other avenues to consider. I think it is possible to make a product better when enabled for business even if you start from the very solid business and design foundation of customer first.
The modern mechanisms for administering IT control are vastly superior to the PC era mechanisms. The idea of running arbitrary code, tweaking every aspect of the UI, or installing add-ins that alter base functionality of a product are long gone. These approaches showed how great products can be made unfamiliar, hard to use, and less robust even with the best intentions Worse, the mechanisms developed to enable these approaches proved to be vectors for security problems, performance challenges, and in general sources of unpredictability and unreliability.
Today’s devices support state-based management, app stores, and security contexts that greatly improve the ability to deliver upgraded business features. To many, these tools are not yet enough. The platform vendors are carefully balancing the approaches they introduce with the known downsides by the old approaches.
There’s a disruption in the way devices, apps, and information are managed, but that does not necessarily mean an elimination.
–Steven Sinofsky
Look at me! More thoughts on notifications
Hunter Walk shared some thoughts on notifications and the challenges he and (certainly through twitter) many people see. Many of the companies I’ve met with see design challenges in how much and when to offer up notifications. There’s a long history of trying different approaches and modalities to notifications and so it seems worth some additional perspective for those familiar with what we see today on modern mobile platforms.
Notifications are one of those features where everyone has an opinion, and rightfully so. The feature is so visible and for just about everyone seems so close to being helpful but yet always off by just a little. There’s a general UX principle that is worth considering, which is anytime you push some feature on your customer you really want it to be right (correct, useful, helpful) for him/her 100% of the time. If not, chances are your customer will recall the negatives of the feature far more than the positives. This applies to notifications, autocorrect, form completion, and more. If you find yourself putting a lot of design energy into how your customer can undo or dismiss your best guess at what was intended, then you’re probably being too aggressive.
Anytime you push some feature on your customer you really want it to be right for him/her 100% of the time.
In some ways, today’s Notification Centers are the extreme case of “we’re collectively going to be wrong so often that we’re just going to put stuff in one place” or “there’s just so much we app developers have to tell you that the platforms are squeezing it all into one place to avoid cluttering up the platform itself”.
It is as if it isn’t enough we have to manage all of our apps, bookmarks, and preferences, we now have to manage all the ways apps tell us stuff we might want to know. Hunter’s raised the complaint (to a chorus of agreement) that after a two weeks, you have to go in and turn off notifications on a new app. Of course this improves battery life, reduces chatter, and then as some noted causes you to start to ignore the app.
What’s an app developer to do?
What to do?
In the PC era a lot of effort went into honing the design of verbs and interaction. It took a decade to develop the right approaches to menus, toolbars, status bars, panes, and more. That’s because many apps were essentially a large set of verbs this was the big design challenge. The rough equivalent to this design challenge is the role of notifications in mobile. That’s because in a mobile world many apps exist to be essentially a stream of information.
Notifications suffer a clear tension between platform pm and the app pm.
Platform pm wants to contain apps to the app experience, extending the walled-garden such that apps don’t interfere with other apps. By definition a notification is a way for one app to interfere with other apps. Platform pm sees notifications as necessary far less frequently than app pm might. This leads to a set of APIs that offer a clear, albeit limited, view of what a notification is and what it can do. This seems reasonable and we all want the platform folks maintaining a global view of consistency in approach and control.
App pm sees the world through the lens of their app. The assumption is that someone downloading and using an app has made a choice to count on that app for the purpose it was designed, and so whether it is an airline app alerting you to a flight (or a potential discount on a future flight), a bank with a balance alert (or advertising a new bank feature), or a communication tool letting you know of some inbound message (or alerting you that a friend is now on line) the app pm sees any of these as worthwhile reasons to interfere with your flow or context. On all platforms, apps often design their own type of notifications that get used while you are using the app (for in app purchase or feature advertising) because the platform is not rich enough. All this seems legitimate, and certainly at the time of initial designs.
Over time the initial designs from both parties tend to lead to an expansion in the ability to interrupt you. Each subsequent release of a platform almost always adds more capabilities to enhance and customize notifications in an effort to offer more while also trying to keep the noise in the system manageable. Each app adds more and more notifications in an effort to more deeply engage with customers and likely to encourage customers to use more surface area of the app.
Many who use iOS 7 have spent quite a bit of time mired notification customization. Here is an overview of the iOS 7 features, both the notifications and notification center, worth a look if you’re on Android or not sure of the impressive depth that Apple designed for notification. Android is probably not quite at the same level of consistency and control, though as you might expect there are several apps that can help you customize notifications of other apps.
Design Challenge
At the extreme we end up with two core design challenges.
Notification spam. This one is easy. Too many apps just think too much of what is going on is important to you. Like too much of any design the burden falls to app product managers to just be more thoughtful. Like so many elements of any platform, when there is a view that making money depends on getting folks to use more of a product or spend more time in a product, the platform starts to look a bit like “surface area to be exploited”. Like the old Start Menu and desktop in Windows, the more places an app can “infuse” itself and invade your space the better. On Android we see this in the share item menu as another bit of surface area to be gamed or exploited.
Notification action. The most common issue with notification is that your flow is interrupted and then you seem to be pulled into a state of distraction until you deal with the inbound notice. We each have our own human based algorithms for how to cope. We always jump on SMS. We (almost) always ignore a ringing phone. We wish we could find a way for some app or another to stop bugging us so we uninstall it.
On iOS there is very little you can do to a notification other than dismiss it or just jump directly to the app or place in the app that generated the notification. Modal or must-act notifications are generally discouraged. The resulting notification center then turns into a list to read that spans a bunch of apps and for some ends up to be a list of stuff you’ve already seen popup or in context or just a reminder to get to the app.
On Android, the design takes a different approach which is to enable notifications that can take actions. This is where the elegance of notifications is really stretched, but in a way that many find appealing. For example, when you receive a new mail message the gmail notification lets you archive it based on reading the initial content or various SMS clients offer you the ability to reply.
On Windows Phone, one has the additional option of pivoting notifications by person on your home screen so you can glance and see that there is activity by person. This has a natural appeal when there are a small set of folks you care deeply about but as a general purpose mechanism it might not scale particularly well.
The core challenge with offering verbs with notifications is almost “classic” in that one can never off the right set of verbs because eventually the design turns into attempting to implement the a substantial number of features of the app in the notification. Mail is a great challenge: delete, file, reply, flag, etc. all become possible verbs. Each usage pattern in aggregate leads to the whole mail experience. The more users you have the larger the group of customers that don’t like the subset of verbs you picked.
Ultimately taking action based on a notification turns into a bit of a frustration in that the notification centers essentially offer a new way to launch all your apps. What was a nice feature turns into a level of indirection almost all the time.
Opportunity
Therein is the opportunity. In a world where many people are almost constantly glancing at their phones and wanting to know more about what is going on in their digital lives and a world where almost every app represents an endless stream of information along with in-app notifications, it seems that notifications need a different level of semantics.
For example, with just a few friends Facebook always has something new to see so why notify you of the obvious. For many, Twitter is essentially a notification engine. Mail certainly is a constant stream, arguably of decreasing importance. In other words, it isn’t even clear what makes sense to notify you about when the natural behavior is to periodically launch apps to see what’s new within the app context and apps are generating new information all the time.
Similarly, if most everyone knows that when you are talking to another human you both have to turn your phones upside down to avoid being distracted (or sharing private information), then there’s a good chance we’ve collectively missed the mark notifications. The iOS “do not disturb” is an awesome feature but yet it seems to undo all the work in both the notification center and in the apps.
My view is that a feature that requires us to customize it before it becomes useful or less annoying is defaulted the wrong way. Of course this is literally impossible with a product used by more than a few people, since any design at all will have both critics and shortcomings. However, it is possible to default to “out of the way” and then provide a mechanism for people to decide what they might want to be notified about once a usage pattern is established.
For example, I might assert that for an app like mail, sms, Facebook, or Twitter the simple iOS badge is enough. We are all in and out of these apps enough during the day that a specific notification is redundant with the in-app notifications already there.
Each app can almost certainly step back and either know a priori or offer a mechanism that puts people in control of their experience with notifications. It is almost certainly the case that if we’re bouncing in and out of apps all the time but really do want to know if SMS comes from a loved one amongst the 100’s of SMS many get each day, that is likely the way to design a feature.
It is easy to imagine using more context (loved the twitter suggestion to not notify while driving/moving fast). It is easy to imagine more machine learning applied to notifications. But I think we can start from a fresh perspective that the mechanisms provided are just being over-used to begin with when we look at modern usage patterns.
–Steven Sinofsky (@stevesi)
Designing for exponential trends of 2014
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!
–Steven
10 Observations from Tokyo’s CE scene
I love visiting Tokyo and have been lucky enough to visit dozens of times over many years. The consumer electronics industry has certainly had ups and downs recently, but a constant has been the leading edge consumer and business adoption of new technologies. From PCs in the workplace to broadband at home and smartphones (a subject of many humorous team meetings back pre-bubble when I clearly didn’t get it and was content with the magic of my BB 850!) Japan has always had a leading adoption curve even when not necessarily producing the products used globally.
This visit was about visiting the University of Tokyo and meeting with some entrepreneurs. That, however, doesn’t stop me from spending time observing what CE is being used in the workplace, on the subway, and most importantly for sale in the big stores such as Yodobashi, Bic, and Labi and of course the traditional stalls at Akihabara. The rapid adoption, market size, and proximity to Korea and China often mean many of the products seen are not yet widely available in the US/Europe or are just making their way over. There’s a good chance what is emphasized in the (really) big retail space is often a leading indicator for what will show up at CES in January.
If you’re not familiar with Yodobashi, here’s the flagship store in Akihabara — over 250,000 sq ft and visited by 10’s of millions of people every year. I was once fortunate enough to visit the underground operations center, and as a kid who grew up in Orlando it sure feels a lot like the secret underground tunnels of the Magic Kingdom!
With that in mind here are 10 observations (all on a single page). This is not statistical in any way, just what caught my eye.
- Ishikawa Oku lab. The main focus of the trip was to visit University of Tokyo. Included in that was a wonderful visit with Professor Ishikawa-san and his lab which conducts research on exploring parallel, high-speed, and real-time operations for sensory information processing. What is so amazing about this work is that it has been going on for 20 years starting with very small and very slow digital sensors and now with Moore’s law applied to image capture along with parallel processing amazing things are possible such as can be seen in some of these Youtube videos (with > 5 million views), see http://www.youtube.com/ishikawalab. More about the lab http://www.k2.t.u-tokyo.ac.jp/index-e.html.
- 4K Displays. Upon stepping off the escalator on the video floor, one is confronted with massive numbers of massive 4K displays. Every manufacturer has displays and touts 4K resolution along with their requisite tricks at upscaling. The prices are still relatively high but the selection is much broader than readily seen in the US. Last year 4K was new at CES and it seems reasonable to suspect that the show floor will be all 4K. As a footnote relative to last year, 3D was downplayed significantly. In addition, there are numerous 4K cameras on sale now, more so than the US.
- Digital still. The Fuji X and Leica rangefinder digital cameras are getting a lot of floorspace and it was not uncommon to see tourists snapping photos (for example in Meiji Garden). The point and shoot displays feature far fewer models with an emphasis on attributes that differentiate them from phones such as waterproof or ruggedized. There’s an element of nostalgia, in Japan in particular, driving a renewed popularity in this form factor.
- Nikon Df. This is a “new” DSLR with the same sensor as the D-800/D4 that is packaged in a retro form factor. The Nikon Df is definitely only for collectors but there was a lot of excitement for the availability on November 21. It further emphasized the nostalgia elements of photography as the form factor has so dramatically shifted to mobile phones.
- Apple presence in store. The Apple presence in the main stores was almost overwhelming. Much of the first floor and the strategic main entry of Yodobashi were occupied by the Apple store-within-a-store. There were large crowds and as you often see with fans of products, they are shopping the very products they own and are holding in their hands. There has always been a fairly consistent appreciation of the Apple design aesthetic and overall quality of hardware but the widespread usage did not seem to follow. To be balanced, one would have to take note of the substantial presence of the Nexus 5 in the stores, which was substantially and well-visited.
- PCs. The size of the PC display area, relative to mobile and iOS accessories, definitely increased over the past 7 months since I last visited. There were quite a large number of All-In-One designs (which have always been popular in Japan, yet somehow could never quite leap across the Pacific until Windows 8). There were a lot of very new Ultrabooks running Haswell chips from all the major vendors in the US, Japan, and China. Surface was prominently displayed.
- iPhone popularity. There was a ubiquity of the iPhone that is new. Android had gained a very strong foothold over the national brands that came with the transition to nationwide LTE. Last year there was a large Android footprint through Samsung handsets that was fairly visible on display and in use. While the Android footprint is clearly there, the very fast rise of iPhone, particularly the easily spotted iPhone 5s was impressive. The vast expanse of iPhone accessories for sale nearly everywhere supports the opportunity. A driver for this is that the leading carrier (DoCoMo) is now an iPhone supplier. Returning from town, I saw this article speaking to the rise of iOS in Japan recently, iPhone 5S/C made up 76% of new smartphone sales in Japan this October.
- Samsung Galaxy J. Aside from the Nexus 5, the Android phone being pushed quite a bit was the Samsung Galaxy J. This is a model only in Asia right now. It was quite nice. It sports an ID more iPhone-like (squared edges), available in 5c-like colors, along with the latest QC processor, 5″ HD display, and so on. It is still not running Kitkat of course. For me in the store, it felt better than a Galaxy S. Given the intricacies of the US market, I don’t know if we’ll see this one any time soon. The Galaxy Note can be seen “in the wild” quite often and there seems to be quite a lot of interest based on what devices on display people would stop and interact with.
- Tablets. Tablets were omnipresent. They were signage in stores, menus in restaurants, in use on the subway, and in use at every place where people were sitting down and eating/drinking/talking. While in the US we are used to asking “where are all the Android tablets”, I saw a lot of 7″ Android tablets in use in all of those places. One wouldn’t expect the low-priced import models to be visible but there are many Japan OEMs selling Android tablets that could be spotted. I also saw quite a few iPad Minis in use, particularly among students on the trains.
- Digital video. As with compact digital cameras, there was a rather extreme reduction in the number of dedicated video recorders. That said, GoPro cameras had a lot of retail space and accessories were well placed. For example, there were GoPros connected to all sorts of gear/showing off all sorts of accessories at Tokyu Hand (the world’s most amazing store, imho). Professional HD and UHD cameras are on display in stores which is cool to see, for example Red and Arri. One of the neatest uses of video which is available stateside but I had not seen is the Sony DEV-50 binoculars/camera. It is pricey (USD$2000) but also pretty cool if you’ve got the need for it. They have reasonable sensors, support 3D, and more. The only challenge is stability which make sense given the equivalent focal length, but there is image stabilization which helps quite a bit in most circumstances.
There were many other exciting and interesting products one could see in this most wired and gadget friendly city. One always is on the lookout for that unique gift this holiday season, so I found my stocking-stuffer. Below you can see a very effective EMF shielding baseball hat (note, only 90% effective). As a backup stocking-stuffer, all gloves purchased in Japan appear to be designed with resistive touch screens in mind :-)
–Steven Sinofsky
PS: Here’s me with some super fun students in a class on Entrepreneurship and Innovation at the University of Tokyo.
On the exploitation of APIs
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.
History
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.
Modern example
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).
Reality
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.
–Steven
28-10-13 Fixed a couple of typos.
Learning by Shipping 