EFTA00682758.pdf

From: Steven Sinofsky To: Jeffrey Epstein O> Subject: Fw: [New post] Conversation #38— disrupt or die Date: Tue, 14 May 2013 02:07:49 +0000 Importance: Normal Sent from Surface RT Check out From: Learning by Shipping Sent: Wednesday, May 8, 2013 4:09 PM To: Respond to this post by replying above this line New post on Learning by Shipping Conversation #38— disrupt or die by Steven Sinofsky I glthCAM164QK Anyone worth their salt in product development knows that listening to customers through any and all means possible is the means to innovation. Wait a minute, anyone worth their salt in product development knows that listening to customers leads to a faster horse. Deciding your own product choices within these varying perspectives is perhaps the seminal challenge in product development, tech products or otherwise. This truly is a tyranny of or but one in which changing the rules of the game is the very objective. In this discussion, which is such a common dialog in the halls of HBS as well tech companies everywhere it should probably be a numbered conversation (for this blog let's call this Conversation #38 for shorthand—disrupt or die). For a recent discussion about why it is so difficult for large companies to face changes in the marketplace, see this post Why Corporate Giants Fail to Change. "Disrupt or die" or "disrupt and die"? Failure to evolve a product as technologies change or as customer scenarios change is sure to lead to obsolescence or elimination from the marketplace. It is difficult to go a day in tech product development without hearing about technology disruption or "innovator's dilemma'. The biggest fear we all have in tech is failing to keep up with the changing landscape of technologies and customers, and how those intersect. EFTA00682758 At the same time, hopefully we all get to that lucky moment when our product is being used actively by customers who are paying. We're in that feedback loop. We are improving the product, more is being sold, and we're on a roll. That's when innovation over time looks like this: Incremental In this case as time progresses the product improves in a fairly linear way. Listening to customers becomes a critical skill of the product team. Product improvements are touted as "listening to customers" and things seem to go well. This predictability is comforting for the business and for customers. That is, until one day when needs change or perhaps in addition a new product from a competitor is released. Seemingly out of nowhere the great feedback loop we had looks like it won't help. If we're fortunate enough to be in tune to changing dynamics outside our core (and growing) customer base we have time to react and change our own product's trajectory. That's when innovation looks like this: New Product This is a time when the market is receptive to a different point of view, and a different product -- one that redefines, or reimagines, the category. Sometimes customers don't even realize they are making a category choice, but all of a sudden they are working differently. People just have stuff to get done and find tools that help. We're faced with what seems like an obvious choice—adjust the product feature set and focus to keep up with the new needs of customers. Failing to do so risks losing out on new sales, depth usage, or even marginalization. Of course features/capabilities is a long list that can include price, performance, battery life, reliability, simplicity, APIs, different integration points or service connections, and any other attributes that might be used by a new entrant to deliver a unique point of view around a similar scenario. Many folks will be quick to point out that such is only the case if a new product is a "substitute" for the product people are newly excited about. There is truth to this. But there is also a reality shown time and time again which gets to the heart of tech bets. It is almost always the case that a new product that is "adjacent" to your product has some elements of more expensive, more complex in some dimensions, less functional, or less than ideal. Then what seems like an obvious choice, which is to adjust your own product, quickly looks like a fool's bet. Why would you chase an inferior product? Why go after something that can't really replace you? The examples of this are too numerous to count. The iPhone famously sucked at making phone calls (a case where the category of "mobile phone" was under reinvention and making calls turned out to be less important). Solid State storage is famously more expensive and lower capacity than spindle drives (a case where the low power, light weight, small size are more valued in mobile devices). Of course tablets are famously unable to provide apps to replace some common professional PC experiences (a case where the value of mobility, all day battery life, always connected seem more valued than EFTA00682759 a set of platform capabilities). Even within a large organization we can see how limited feature set cloud storage products are being used actively by employees as "substitutes" for enterprise portals and file shares (a case where cross-organization sharing, available on the internet, and mobile access are more valued than the full enterprise feature set). The list goes on and on. As product managers we all wish it was such a simple choice when we face these situations. Simply leapfrog the limited feature set product with some features on our profitable product. Unfortunately, not every new product that might compete with us is going to disrupt us. So in addition to facing the challenges of evolving the product, we also have to decide which competitors to go after. Often it takes several different attempts by competitive products to offer just enough in the way of new / different approaches to begin to impact an established product. Consider for example of how much effort the Linux community put into desktop Linux. And while this was going on, Android and iOS were developed and offered a completely different approach that brings new scenarios to life. A good lesson is that usually a head- on alternative will quite often struggle and might even result in missing other disruptive technologies. Having a unique point of view is pretty important. The reality of this situation is that it is only apparent in hindsight. While it is going on the changes are so small, the product features so minimal, and the base of the customers choosing a new path so narrow that you don't realize what is going on. In fact, the new product is also on an incremental innovation path, having attained a small amount of traction, and that incremental innovation rapidly accumulates. There is a tipping point. That is what makes acting during such a "crisis" so urgent. Since no one is first all the time (almost by definition when you're the leader), deciding when and how to enter a space is the critical decision point. The irony is that the urgency to act comes at a time when it appears from the inside to be the least urgent. Choosing to innovate means accepting the challenges We've looked at the landscape and we've decided as a team that our own product needs to change course. There is a real risk that our product (business) will be marginalized by a new entry adjacent to us. We get together and we come up with the features and design to go after these new scenarios and capabilities. The challenge is that some of what we need to do involves changing course—this is by definition what is going on. You're Apple and you decide that making phone calls is not the number 1 feature of your new mobile phone or your new tablet won't run OS X apps. Those are product challenges. You also might face all sorts of challenges in pricing, positioning, and all the things that come from having a stable business model. For example, your competitor offers a free substitute for what you are selling. The problem is your existing customers have become conditioned to expect improvements along the path we were traveling together. Worse, they are by definition not expecting an "different" product in lieu of a new version of their favorite product. These customers have EFTA00682760 built up not just expectations, but workflows, extensions, and whole jobs around your product. But this is not about your existing and best customers, no matter how many, it is about the foundation of your product shifting and you're seeing new customers use a new product or existing customers use your product less and less. Moving forward the product gets built and it is time to get it into market for some testing or maybe you just release it. BOOM! All that work your marketing team has done over the years to establish what it means to "win" in the space that you were winning is now used against you. All the "criteria" you established against every competitor that came along are used to show that the new product is not a winning product. Except it is not winning in the old way. What you've done is become your own worst enemy. But even then, the new way appears to be the less than optimal way—more expensive, less features, more clicks, or simply not the same at doing things the product used to do. The early adopters or influential users (that was an old term in the literature, "IEU" or sometimes "lead user") are immediately taken aback by the change in direction. The workflows, keystroke memory, add-ins, and more are just not the same or no longer optimal--there's no regard for the new scenarios or capabilities when the old ones are different. Worse, they project their views across all customer segments. "I can't figure this out, so imagine how hard it will be for my parents" or "this will never be acceptable in the enterprise" are common refrains in tech. This happens no matter who a product is geared towards or how complex the product was in the first place. It is not how it does anything but the change in how it did things people were familiar with. This could be in user experience, pricing, performance, platform requirements or more. You're clearly faced with a set of choices that just don't look good. In Lean Startup Eric Ries talks in detail about the transition from early users of a new product to a wider audience. In this context, what happens is that the early users expect (or tolerate) a very different set of features and have very different expectations about what is difficult or easy. His conclusion is that it is painful to make the transition, but at some point your learning is complete and it is time to restart the process of learning by focusing on the broader set of customers. In evolving an existing product, the usage of a pre-release is going to look a lot like the usage of the current release. The telemetry proves this for you, just to make this an even more brutal challenge. In addition, because of the years of effort the enthusiasts put into doing things a certain way and all that work establishing criteria for how a product should work, the obvious thing to do when testing a new release is to try everything out the old release did and compare to the old product (the one you are changing course of) and then maybe some new stuff. This looks a lot like what Eric describes for startups. For products in market, the moment is pretty much like the startup moment since your new product is sort of a startup, but for a new trajectory. EFTA00682761 Remember what brought us here, two things: • The environment of usage or business around the product was changing and a bet was made that changes were material to the team. With enough activity in the market, someone will always argue that this change is different and the old and new will coexist and not cannibalize each other (tell that to PalmPilot owners who swore phones would be separate from calendar and contacts, or GPS makers who believe in stand-alone units, or...). • A reminder that if Henry Ford had asked customers what they wanted from a car they would have said a faster horse. The market was conditioned to ask for and/or expect improvements along a certain trajectory and no matter what you are changing that trajectory. All the data is flowing in that shows the new product is not the old product on the old path. Not every customer is interested in doing new things, especially the influential testers who generally focus on the existing ways of doing things, have domain expertise, and are often the most connected to the existing product and all that it encompasses. There is an irony in that for tech these customers are also the most tech-savvy. Pretty quickly, listening to customers is looking exceedingly difficult. If you listen to customers (and vector back to the previous path in some way: undo, product modes, multiple products/SKUs, etc.) you will probably cede the market to the new entrants or at least give them more precious time. If technology product history is any guide, pundits will declare you will be roadkill in fairly short order as you lack a strategic response. There's a good chance your influential customers will rejoice as they can go back and do what they always did. You will then be left without an answer for what comes next for your declining usage patterns. If you don't listen to customers (and stick to your guns) you are going to "alienate" folks and cede the market to someone who listens. If technology product history is any guide, pundits will declare that your new product is not resonating with the core audience. Pundits will also declare that you are stubborn and not listening to customers. All of this is monumentally difficult simply because you had a successful product. Such is the price of success. Disrupting is never easy, but it is easier if you have nothing to lose. Many folks will be quick to say that new products are fine but they should just have the old product's way of doing things. This can seem like asking for a Prius with a switch to turn off the battery (my 2002 Prius came with a training DVD, parking attendant reference card, and more!). There are many challenges with the "side by side" approach. The most apparent is that it only delays the change (meaning delays your entry into the new market or meeting of new scenarios). Perhaps in a world of cloud-services this is more routine where you have less of a "choice" in the change, but the operational costs are real. In client code/apps the challenge becomes very quickly doing things twice. The more complex the changes are the more costly this becomes. In software nothing is free. Product development is a social science. People and time EFTA00682762 In this numbered conversation, "disrupt or die" there are a few factors that are not often discussed in detail when all the debates happen. First, people adapt. The assumption, especially about complex tech products, is that people have difficulty or lack of desire to change. While you can always overshoot the learning people can or are willing to do, people are the most adaptable part of a system. One way to think about this is that every successful product in use today, those that we all take for granted, were introduced to a customer base that had to change behavior. We would not be where we are today without changing and adapting. If one reflects, the suboptimal change (whether for the people that are customers or the people running a business) is apparent with every transition we have made. Even today's tablets are evidence of this. Some say they are still for "media consumption" and others say they are "productivity tools". But behind the scenes, people (and developers) are rapidly and actively changing and adapting to the capabilities of tablets because the value proposition is so significantly improved in some dimensions. Second, time matters. Change is only relative to knowledge people have at a moment in time and the customers you have at the moment. New people are entering the customer base all the time and there is a renewal in skills, scenarios, and usage patterns. Five years ago almost no one used a touch screen for very much. Today, touch is a universally accepted (and expected) input method. The customer base has adapted and also renewed around touch. Universities are the world's experts at understanding this notion of renewal. They know that any change to policy at a university is met with student resistance (especially in the spring). They also know that next year, 25% of the "customer base" will be replaced. And in 3 summers all the students on campus will only know the new way. One could call that cynical. One could also call that practical. Finally time means that major product change, disruption, is always a multi-step process. Whether you make a bet to build a new product that disrupts the market dynamics or change an existing product that disrupts your own product, it rarely happens in one step. Phones added copy/paste and APIs and even got better at the basics. The pivot is the tool of the new endeavor until there is some traction. Feedback, refinement, and balancing the need to move to a new space with the need to satisfy the installed base are the tools of the established product "pivoting" in response to a changed world. It takes time and iteration—just the same way it took time and iteration to get to the first summit. Never lose sight of the fact that disrupting is also product development and all the challenges that come from that remain--just because you're disrupting does not mean what you do will be perfect--but that's a given we all work with all the time. We always operate knowing there is more change to come, improvements and fixes, as we all to learn by shipping. Part of these factors almost always demonstrate, at least in the medium term, that disruption is not synonymous with elimination. Those championing disruption often over- estimate progress towards elimination in the short term. Though history has shown the long term to be fairly predictable. Black cars are still popular. They just aren't the only cars. Product development choices are based on social science. There is never a right answer. Context is everything. You cannot NB test your way to big bets or decisions about technology disruption. That's what makes all of this so fun!! EFTA00682763 Go change the rules of the game! --Steven Sinofsky Note. I believe "disrupt or die" is the name of a highly-regarded management class at General Electric's management school. Steven Sinofsky I May 8, 2013 at 1:00 pm I Tags: creativity strategy, tension tradeoffs I Categories: posts I URL: http://wp.me/p3lnkB-8r See all comments Unsubsaibe or change your email settings at Manage Subscriptions. Trouble clicking? Copy and paste this URL into your browser: Thanks for flying with EFTA00682764