Tuesday, December 8, 2015

Do Leadership styles matter in forming Product Portfolios?

To find the context of this blog, please do read this one I published recently. To summarize, this is a part of knowledge sharing of my panel talk at GHCI. Just as a note of caution, please do not expect the below answers to be elaborate as these were conveyed in a time limit of 3-4 minutes. I have tried to recollect these to the best of my knowledge.

Jack Welch famously said that if a division at GE is not #1 or #2 in their industry, that division should be closed. He implemented that strategy at GE while he was CEO.  How important is leadership style in driving the necessary portfolio changes?

Let me talk first about three pioneering figures of our Industry. Bill Gates, Steve Jobs and Andy Grove. They make an interesting study because all three of them had their strong points and they had weaknesses too and their personality reflected in the organizations that they eventually led to glory.

Gates’ USP in his early days was the rate knowledge on how to program the early personal computers. And he was a true expert at that as he has been featured in Malcolm Gladwell’s famous 10000 hour rule needed to be expert at anything. During his early days (till around 90s), he was so involved in programming related work that he himself admitted that “I wouldn’t let anybody write any code. I went in and took every statement that anybody else had written in BASIC and rewrote it myself, just because I didn’t like the way they coded.” He used to astonish company’s engineers with his programming details. He soon realized that he and Microsoft couldn’t scale this way and hired the able people to lead in other major functional areas.

Steve Jobs’s focus on design was just as intense as Gate’s focus on software. As Gates went deep into the code, Jobs committed himself to user experience and design with maniacal depth. He oversaw every aspect of product design and would scrutinize everything, down to pixel level. There are stories around Jobs wanting scroll bars to be looking in a certain way, forcing the team to show multiple versions in a process that took almost six months.

Andy Grove, possibly lesser celebrated than Gates and Jobs but no less effective was passionate about disciplined thinking. He would challenge people’s thinking. Then he would probe all the way through a strategy and force people to really justify it. He also once famously said- “Execution is God”

So be it Gates’ penchant for technical details, Jobs’ for design and Grove’s focus on disciplined thinking, their personalities showed up in the way their organizations shaped up and that included how their products looked a fared. Their leadership styles driven by their primary personality preferences shaped up the products.

Michael Watkins in his book “The First 90 days” talks about STARS framework based on the business situation a particular business or for our discussion, a product is. Each letter except the letter “A” in the STARS is related to a business situation i.e. Start-up (when business starts), it either becomes Sustaining Success (after some efforts) or it closes (Shutdown/Divestiture). Once it’s a sustaining Success usually complacency sets in where it reaches the state of Realignment and post this stage, it is either back to Sustaining success or Turnaround. If we study this framework closely, each of the stages requires different leadership style. 

To quote the case of Apple, when Steve Jobs took over Apple in 1997- it was almost a dead business dearly in the need of being Turned-around. At this stage, he adopted a very hands-on approach to leadership and involved himself in taking tough decisions, culled projects, got into product design. He eventually made Apple, a sustaining success. On his departure, and taking over of Tim Cook, Apple has undergone certain realignment and Cook’s leadership style evolved accordingly. E.g. Steve Jobs used to call acquisitions as “Failure to Innovate” whereas under Tim Cook Apple has made more than 50% of its acquisitions. Tim Cook is more open to doing partnerships with IBM, Microsoft than probably Steve Jobs was and Cook even leveraged these partnerships to open-up enterprise market for Apple.

How can the Engineering function positively support the growth of Product portfolio?

To find the context of this blog, please do read this one I published recently. To summarize, this is a part of knowledge sharing of my panel talk at GHCI. Just as a note of caution, please do not expect the below answers to be elaborate as these were conveyed in a time limit of 3-4 minutes. I have tried to recollect these to the best of my knowledge. The below question was more meant for designer in the panel and I had follow-up comments covering the Engineering aspect-

Indra Nooyi is one of my role models and she appointed a chief design officer a couple of years ago who has a seat at the table for current and future portfolio decisions.
As a chief designer for SAP, what problem are you trying to solve when you look at the portfolio of technology products?

As I have observed, Design is a much younger profession if we compare it with Engineering. One may argue that design may have existed long back but its importance in the Information Technology profession was brought in arguably by Steve Jobs and his maniacal focus on design.

From an Engineering perspective, when I started my career one of the first applications that I worked on was built on- then modern and now obsolete- Three tier architecture. Three tier architecture was an improvement over the earlier architecture but it was still very locked and un-scalable. The key characteristics of the modern engineering architectures are that they are not monolithic (like their predecessors), they can be morphed, they embrace extendibility, they are modular. In today’s world, the architectures are usually referred to as “Platform-style architectures”. What is a Platform? Let me explain with an example-

iPhone is a fabulous, high quality, supremely designed product. For a moment, can you imagine the utility of an iPhone without App-store? It will still be a fabulous, high quality, supremely designed product but with a severely limited utility. The presence of app-store and its compatibility with iPhone enables Apple to “extend” the functionality of an iPhone. iPhone with app-store is really “iPhone with billions of features” considering each app as a feature. Could Apple have built all billion apps by itself ? Possibly not in one life time even with thousands of developers. So what’s happening here ? Apple has actually have been able to build an ecosystem of developers and consumers and been able to build a win-win scenario for all. Apple provides a “platform” for developers to build apps. Consumers who buy iPhones need apps that solve their problems and needs. Developers earn a good portion of what they gain from each app usage. Apple earns its chunk. And Consumers get an answer to their needs by apps.

This is all being made possible by embracing Platform style architectures. If, for a moment, we assume that iPhone was built on a three-tier architecture, could it have achieved extendibility? No, there was no way it would have allowed external developers to add features. Platform style architectures achieve that by exposing the APIs with the right amount of data. External developers can use these APIs and integrate their offerings. We live in a API economy, and this trend is going to stay for some time to come.

When we thinking of building something these days, we don’t say “Lets build products”. We say- “Lets build Platforms”. To conclude I would state the below quotes that was doing rounds, which reflect the power of platforms-

"Uber, the world’s largest taxi company, owns no vehicles. Facebook, the world’s most popular media owner, creates no content. Alibaba, the most valuable retailer, has no inventory. And Airbnb, the world’s largest accommodation provider, owns no real estate. Something interesting is happening."

What kind of mindset is needed to deal with changes that can impact the product portfolio?

To find the context of this blog, please do read this one I published recently. To summarize, this is a part of knowledge sharing of my panel talk at GHCI. Just as a note of caution, please do not expect the below answers to be elaborate as these were conveyed in a time limit of 3-4 minutes. I have tried to recollect these to the best of my knowledge.

For many companies, portfolio planning is an annual affair. In this mobile-first, cloud-first world, how can organizations keep up with the pace of change.

I love Sports and I will be a bit biased towards sports related examples. I would like to narrate an example from the sport of Cricket-
There was an England bowler named Monty Panesar, who was bowling in one of the Ashes tests (Ashes is one of the most traditional cricket series between England and Australia). Commentating in the match and seeing Monty bowl, Australian legend Shane Warne is said to have remarked-
“Is Monty bowling in his 33rd test or the 1st test for the 33rd time?”
Monty probably stopped growing and probably he started to think of himself as having been an accomplished bowler after getting a break into England playing team and stopped growing there afterwards. Monty probably did all the hard-work to reach the pinnacle of his profession but sadly, after reaching there, kept doing the same things that brought him to the top and didn’t innovate further. 

For the purposes of our discussion, let’s call this phenomenon as “Monty Effect” i.e. doing all the hard-work to achieve initial grand  success, only to not being able to sustain the same over longer time. Interestingly I have seen a lot of companies go through “Monty Effect”. Companies cash-in well on what made them successful and eventually the very reason that made them successful slow starts to become the reason for their downfall. They keep doing the same things that made them successful in the past, only to realize later that the incrementalism has really pushed them down. The key fact remains- things that make companies (and careers too) reach success at one level doesn’t work well while reaching a different level. A related corollary is echoed by Robin Sharma also famously quotes- “Don’t live the same year 75 times and call it life”

On the topic of managing change, while dealing with the product portfolios- I would like to say just 2 points here-

Point#1. Anticipating change and adapting to it is a skill…
…and if we don't treat it as a skill we leave a gap open to become victims of change.

From a popular case related to AOL-Time Warner merger- AOL was the king of the dial-up Internet world, but that world was rapidly being supplanted by always-on, much faster broadband. At the time of the merger, half the country had Internet access, yes, but only 3% had broadband. AOL’s business model couldn't anticipate the threat related to broadband on time. 

Denial takes different forms. In 1984, the then head of Digital Equipment Corporation, the largest mini-computer maker at the time,  described PCs as "cheap, short-lived and not-very-accurate machines." This attitude was especially ironic when you consider Digital's past. Digital broke into the world of computers, then dominated by mainframes, in the 1960s with simply designed and inexpensive mini-computers, and grew to become very large company with that strategy. Yet when they were faced with a new technological change in their environment, Digital- once the revolutionary that attached the mainframe world- now resisted this change along with incumbents of the mainframe era."

In my career time, I have seen some legendary companies like Sun Microsystems, Compaq, etc. either merge with bigger companies or bite the dust altogether.
Companies need to build in mechanisms that can help them sniff the changes and help them respond to it timely.

Point#2: As much as we try, it's not possible to anticipate change every time
The second point that I mention here is in a way contradicting with the point I just said and it is that- As much as we try and want, it's not possible to anticipate and predict the change every time accurately. And when we cannot predict it, we should do the next best thing- respond to the situation like the best in the world.
The companies that survived the aftermath of 9/11 attacks weren't experts in dealing with such situations. But they were the companies that were most responsive to change, they were the ones who were willing to work on the ground, they were the ones who changed their plans by every hour and do all that was need to get back on feet despite numerous odds. Southwest airlines was one example which survived post 9/11 situation when most airlines just couldn't cope up with the gravity of the situation.
What happened after 2007 to Nokia is also widely known and written about. Though operationally, it had the best brains to take them past the fire-like situations with suppliers but strategically, it probably lacked the anticipation machinery that could help them assess the impact of disruption iPhone and Android were about to cause. Another aspect in this case is that Nokia failed to part ways with Symbian OS when Android seem to be becoming a de-facto standard.

Walter Gretzky, the father of Champion Ice Hockey player- Wayne Gretzky gave his son the advice to "skate where the puck's going, not where it's been". Likewise, the companies need to evolve and position their products and offerings consistently towards the direction where the industry and markets are moving, not where it’s been in the past.

When the Australian team was winning almost everything in the Cricket field from mid-90s through most of 2000s, their captain during the initial stages of its transformation Steve Waugh shared a secret of their success. I remember him once saying that internally the Australian team used to consider themselves as world no. 2 (though they were undisputed #1). This feel of them not being #1, even though artificial one but deeply internalized one, helped them get better even when they won. If they won by 10 runs, they did make sure to celebrate but more than that set themselves the goal to do win by a bigger margin in the next match. So this team remained emerging and constantly strived towards reaching great heights.

Companies need to imbibe this mindset when their products are doing well to help them prepare for the unforeseen change.

Monday, December 7, 2015

What factors matter in decisions related to Product portfolio growth and expansion?

To find the context of this blog, please do read this one I published recently. To summarize, this is a part of knowledge sharing of my panel talk at GHCI. Just as a note of caution, please do not expect the below answers to be elaborate as these were conveyed in a time limit of 3-4 minutes. I have tried to recollect these to the best of my knowledge.

Question: You have a portfolio and you have a strategy to grow into a new space. You have a choice of expanding your portfolio by organic growth or inorganic growth. How do you decide?

There are three ways that I can think of-

     #1. Build:
Every company is once a start-up. They come up with an idea, build it from ground-up, test the waters, release it to customers, market it, improve on the offerings and either achieve success or has to change the course of action. Building in-house remains one of the most fundamental ways to grow the portfolio. Not only start-ups, even the more established and successful organizations also invest a lot of time and energy to build products after achieving initial success. Most companies have set R&D budget that is spent on building the products that helps meet the needs of today or the perceived wants of tomorrow. Established organizations also drive the internal innovation to build in-house by means of the programs such as Innovators program, Start-up accelerators programs or “Spin-in” (where a sub team is asked to work on independent workplace on a particular idea to further give it shape and productize it).

    #2. Acquisitions:
Talking of Mergers and Acquisitions, I am reminded of a term- “Toothbrush test”. You may be wondering how toothbrush is related to this topic. A while ago, I learned about this statement from Larry Page, (former CEO of Google), which he asks before any acquisition and the answer to which drives the decision to acquire a company or not-
"Is this something you will use once or twice per day, and does it make your life better?"

Interesting to note that he doesn’t mention about financial gains (yet) from the acquisition. It is interesting to observe that the companies make acquisitions for unique reasons and along with the reasons, the parameters they gauge the acquisition’s success with also varies. So we will be limiting ourselves if we just look at financial success to qualify the acquisition as a success or a failure. When I was growing up, the key products that I used to deal with were things like TVs and Fridges. Our interactions with these products were limited to the number of times that we used them i.e. in case of TV and Fridge, only 2-3 times a day. If you compare that to today’s times, we probably see our Smart Phones 150-200 times according to some estimates. So the currency in today’s product world is not just how much dollars it gets to the companies but also today’s currency is user’s data, time and attention- which once captured is then looked to be monetized. Larry Page’s Tooth brush test validates this hypothesis of mine.
If we look at the high profile Facebook’s acquisition of WhatsApp for a whopping $21 billion or so, it follows the same pattern. If we just look at financials, it (WhatsApp’s acquisition) probably does not still get Facebook any greater tractions in terms of dollars. But if we try and look broadly, WhatsApp acquisition probably helped Facebook stay relevant. Facebook was fast observing that it was losing the user’s attention especially for the young people, who were finding value in alternate services like WhatApp, SnapChat and Instagram. WhatsApp, in the first 4 years or so, reached around 400 million + users whereas during the same time, Facebook had far less users. To think of it, the traditional products like telephone took 75 years to reach even 50 million users and the Radio around 38 years. So, we are talking about a massively different scale here. So, Mark Zuckerberg seem to be patient in making WhatsApp a paid service or finding ways to monetize it but he has been smart enough to consider the billions as he paid for WhatsApp as a price for staying relevant.

    #3. Partnerships:
We live in a competitive world and in this professional era, no two companies neither are permanent friends nor permanent enemies. We are seeing the emergence of terms called as “Frenemy”, which means that the same companies partner in some aspects of their charter and they compete in other areas. The case in point is Apple’s partnership with IBM last year. This partnership is helping Apple gain ground in the Enterprises (using IBM’s expertise) and helping IBM build world class enterprise apps. Apple and IBM compete in the other areas at the same time.

So to wind-up- three ways companies (these days) decide to grow portfolio- Build, Acquire and Partner.

Sunday, December 6, 2015

Panel discussion at GHCI- "Product Portfolio Optimization"

I had an interesting experience late last week while participating in Grace Hopper’s conference in Bangalore, India (abbreviated as GHCI). The conference was on 2nd-4th-Dec. This was my first time attending this conference and having been a part of many other conferences, I can confidently say that I liked being there a lot by virtue of raw energy and enthusiasm of the participants and variety of sessions.

I had my Panel talk on the 4th-Dec at 9:00 AM on the topic- “Product Portfolio Optimization- Choosing your Right bet”. Along with me were the esteemed panelists- Nidhi Gupta (Product Manager, Google), Martin Wezowski (Chief Designer at SAP) and the panel was ably led my Manjula Gondi (Director, Microsoft). The topic around product management, I was told, was being brought in for the first time at the GHCI conference. It was an enriching experience for me personally being part of such a learned Panel, who brought in such diverse perspective. And the in-person feedback that we received post the panel talk only confirmed that the session went humbly well.

The format of Panel discussion required the moderator (Manjula) to set the context and invoke a discussion among the panelists by asking specific questions around the topic and also invite questions from the audience. Through the next few blogs, I will try and list the questions that were put forward to me as a part of discussion and try and list the answers that I gave (as much as I recollect them).

Stay tuned for more Info. Below is the video link of the session-

Sunday, November 22, 2015

Some Valuable Learnings from Amazon Fire Phone failure

This is more of a recent failure. For more reasons than one, i was keen to explore this case further to figure out the possible reasons why Fire Phone failed (Significant number of Fire Phone remained unsold) to cause an impact. Amazon, under Jeff Bezos, have really made some big, bold bets in the past and atleast from outside, it appears to have a culture in which failing is not treated as a sin. This case is even more interesting considering that Amazon has had a reasonable run of success with Amazon Fire Tab. Agreed, a phone is a different animal than a tab when it comes to nuances related to its development, usage and adoption but it (and Amazon's past success with Kindle and its variants) does tell that Amazon was no novice in the area of building hardware product. Read on to know more-

Customer focus gone wrong:

If i try and think about why an organization like Amazon would want to venture into building a phone, i can certainly think of Amazon want to own the starting point of customer experience to access its online retail services. Apple, for instance, takes 30 percent of all revenue generated through apps, and 70 percent goes to the app's publisher. It means that even though Amazon may be selling e-books using Kindle app in iOS, it won't get its full share. Controlling the starting point of buying experience (i.e. owing a smart phone) can have other benefits too where Amazon could have had its own services that could have helped them sell more stuff. So, venturing into phone wasn't a bad idea at the first place. Some analysis that led into analyzing the failure of Fire Phone also led to the fact that it lost out on customer focus. This finding is a bit intriguing given the fact that Amazon is known for its customer centricity. Below are some useful insights from a Fast Company

 "Bezos’s guiding principle for Amazon has always been to start with the needs and desires of the customer and work backward. But when it came to the Fire Phone, that customer apparently became Jeff Bezos. He envisioned a list of whiz-bang features,....Perhaps most compelling was Dynamic Perspective, which uses cameras to track a user’s head and adjust the display to his or her vantage point, making the on-screen image appear three-dimensional."

 And team members simply could not imagine truly useful applications for Dynamic Perspective. As far as anyone could tell, Bezos was in search of the Fire Phone’s version of Siri, a signature feature that could make the device a blockbuster. But what was the point, they wondered, beyond some fun gaming interactions and flashy 3-D lock screens. "In meetings, all Jeff talked about was, ‘3-D, 3-D, 3-D!’ He had this childlike excitement about the feature and no one could understand why," recalls a former engineering head who worked solely on Dynamic Perspective for years. "We poured surreal amounts of money into it, yet we all thought it had no value for the customer, which was the biggest irony. Whenever anyone asked why we were doing this, the answer was, ‘Because Jeff wants it.’ No one thought the feature justified the cost to the project. No one. Absolutely no one."

If this is to be believed, Jeff Bezos vigorously backed some features which didn't make much logical sense to the team. Apparent lesson is that CEO shouldn't necessarily become the customer himself or herself but CEO should rather take the role of the best representative of the business.

Eric Schmidt, the former CEO of Google, brings in an interesting perspective in his book- "How Google Works". He doesn't eat his words when he says "Don't listen to HIPPO". Who is an HIPPO? Read on the excerpt from his book to appreciate this point more-
From the book- "How Google Works"

Lack of App ecosystem:

Keeping platform style thinking at the forefront, it is imperative that a product should be able to build an ecosystem of developers (and consumers), who can help extend the product's capabilities further and make it more useful for the consumers. As this Time article points out, 

Amazon’s app store has about 240,000 apps, compared to more than 1 million in the Google Play store.

As Apple's success had proven, to be successful- it is imperative for the Smart Phone companies to have an app ecosystem that helps its users. On the contrary, as the not-so-wide adoption of Windows phone have proven too, the apps or lack of it, really is one of the key factors. Windows, since its leadership change, has started to take the corrective actions in this regard by announcing the iOS and Android bridge projects for Windows OS.  These projects, if successful, would make it easy for developers to port Android and iOS apps to Windows. To me, releasing a smart phone without adequate app support is a fundamental flaw. It would have been accepted in 2007 (when iPhone was launched), not now when already precedent has been set with so many players already in the market.

Micro-management- the root of all evils? Nah.

There are also some apparent references to Bezos' micromanaging the entire project, which might or might not have been true. Even if it were true, i would rather look into this with a balanced mind. What i mean by this is, if we choose to blame Bezos' micro-management as a reason of failure of Fire phone, we should also be open to appreciate where his apparent micro-management worked and delivered a blockbuster product. My take on micro-management is that it is not as bad as it is often made out to be. Micro-management, like empowerment is a management strategy, which is necessary in some situation where there is a need to monitor the situation closely. It is probably bad if it's an inherent trait of a person. It isn't bad if it is used only in situations where it's used is justified.

Begin with the end in mind:

Ok, this one is not a negative learning. One of the things that i read about the how Amazon Fire phone development effort was started was particularly interesting. It said-

Like every product created at Amazon, the Fire Phone began on a piece of paper. Or rather, several typed, single-spaced pieces of paper that contained a mock-up of a press release for the product that the company hoped to launch some day. Bezos requires employees to write these pretend press releases before work begins on a new initiative. The point is to help them refine their ideas and distill their goals with the customer in mind.

Visualizing the impact that the product is bound to make even before its development has commenced didn't seem like an everyday idea to me. This approach has certain freshness in the times when many product organizations start with a formal product requirements document. With this end clear, reviewed and approved- it has the capability to become a sort of oracle against which product specific decisions could be made. Another notable aspect is the fact that Jeff Bezos' act of involving his employees to write the same. With all the flak that Bezos have been getting regarding Amazon's work culture of late, this seem like a perfect counter-argument.

This point also proves that when a product is a failure, it doesn't mean that everything that happened during its inception was wrong.

What's your take on these points? Please do share in the comments.



Monday, November 16, 2015

Does Intel Pentium Bug of 1990s Still Holds Any Lessons for us?

Information Technology, at its core, is a forward oriented profession. What i mean by this assertion is that, as a general observation, the rate of change that this profession deals with is unprecedented. In my career time span so far, i have seen many a paradigm shifts including rise and fall and re-rise of Microsoft, birth and dominance of Google, a gigantic comeback of Apple, and all these eventually impacting our lives as professionals and as consumers of technology. In dealing with such acute dynamism, in my belief, it is very easy to lose the sense of history of our profession. I personally feel that having a good sense of history for a chosen profession often helps us connect the dots better and better fathom the current events that we experience. History helps connect things through time and I do consider knowledge of the history of our profession important in shaping its future. Most of the today's methodologies and good practices are evolved by bettering what didn't work in the past. To say the least, sense of history also gives as a sense of connection with the past which we should look to not lose.

I was recently reading the book- "Only the Paranoid Survive", the first person account of Andy Grove (former CEO of Intel) on how he dealt with strategic inflection points i.e. the time in the life of a business when its fundamentals are about to change. One of the narration in the book talks about the Pentium chip bug and it goes like as follows (written as is it appears in the book)-

"Several weeks earlier, some of our employees had found a string of comments on the Internet forum where people interested in Intel products congregate. The comments were under the headings like, "Bug in the Pentium FPU." (FPU stands for floating point unit, the part of the chip that does heavy-duty math.) They were triggered by the observation of a math professor that something wasn't quite right with the mathematical capabilities of the pentium chip. The professor reported that he had encountered a division error while studying some complex math problem.
We were already familiar with this problem, having encountered it several months earlier. It was due to a minor design error on the chip, which caused a rounding error in division once every nine billion times. At first, we were very concerned about this, so we mounted a major study to try to understand what once every nine billion divisions would mean. We found the results reassuring. For instance, they meant that an average spreadsheet user would run into the problem only once every 27,000 years of spreadsheet use.

Andy spends a quite a few pages later in the book to tell why this bug was critical and how it turned his thinking around some peculiar was happening in the world around him. Let me summarize that point of view in next few points and also explain its relevance in today's world-

1. The beginning of social media as a force to reckon with:
Internet Forum in 1990s
     We pretty much take social media for granted these days. It generates a lot of data and opinions every passing second, which is very valuable to those who see the need to seek information out of it. This is especially true for anyone seeking feedback for a 
newly launched product or a service. Consumers, on the other hand, provide feedback often without being asked on social media. It more often turns out to a medium for venting out imperfections and bad experiences. This is now. But when we talk about 1990s, when the Pentium FPU bug occurred, things were still in infancy w.r.t Internet and people had started to use Internet forums to share opinions. Intel, then was not in the business of selling the computer chips directly to consumers. It used to sell via PC manufacturers like IBM. Intel's emergence was at the cusp of PC industry turning more horizontal oriented than vertically oriented meaning that earlier one manufacturer like Digital used to manufacture/assemble all parts of a computer (vertical orientation), later each key component became individual business (horizontal orientation) serving the PC assembler like IBM, Dell etc. Andy mentions in his book that with this bug, he smelled something unusual happen in the field. And it was that though he was not selling directly to consumers, he was getting feedback from them directly. He inferred that if this situation wasn't handled with proactive stance, then he could receive a lot of negative backlash. Mind you, this was 1990s, when it was hard to imagine the power of social media. Andy took the corrective actions quickly and even justified the huge cost of this bug- around USD 450 million (mammoth amount now but more so 20 years back).

It stands the lessons for today's times too. Proactively dealing with feedback received on social media is the order of the day. It is easy to manufacture negativity even by bad intentions of the competitors. The birth of techniques such as Sentiment Analysis that help to proactive assess positive and negative sentiments around the events like product releases further help to deal with negative perceptions well. In my recent memory, i am reminded on the social buzz that was created by the security vulnerability in SSL- Heartbleed bug and the negative response generated in the social media when the news about their (hidden) social experiment A/B test leaked out publically where they subjected a certain percentage of their consumers to negative news deliberately. Even though social media as a channel is quite useful to generate feedback but it also makes companies vulnerable to negative publicity in the event of bugs that catch public attention.

2. Handling strategic inflection points need different skills
   In the wake of negative press and crisis-like situation that the Pentium FPU bug generated for Intel, Andy made a very interesting observation in his book. He says-
 "A lot of people involved in handling this stuff had only joined Intel in the last ten years or so, during which time our business had grown steadily. Their experience had been that working hard, putting one foot in front of other, was what it took to get good outcome. Now, all of a sudden, instead of predictable success, nothing was predictable. Our people, while they were busting their butts, were also perturbed and even scared."

In short, the skills needed to handle peace time in business are quite different from the ones needed during war time. People often come to work believing the workplaces to be fair i.e. if i do "X" amount of work, i will get equivalent of "X" credit. While there is nothing wrong in this assumption generally but such thinking (from employee's perspective) do not take into account changing business situations. The reality of today's times is that an effort that would have resulted in a great output (for company and personally) in a certain business situation would not just be enough in a very different business situation. This often happens because of no fault of employee, who did his best given the current situation but probably lacked situational awareness to alter the nature of efforts. To quickly explain this perspective, Nokia's example comes to mind. The story of rise and further decline of Nokia is widely written about. During good times (till atleast 2007), the company made a big fortunes with its existing model (with its phones based on Symbian OS). But when the time came to change to more modern mobile OS like Android, they just failed to move swiftly. I can imagine the employees in this situation would have put in great efforts with their key skills around Symbian OS but due to situational change, the same efforts which bore huge fruits earlier were just not enough to reap similar or greater rewards.

3. Lessons in Defect Advocacy
    To me, the most interesting part of the narration regarding Pentium FPU bug was this- "an average spreadsheet user would run into the problem only once every 27,000 years of spreadsheet use"
This was actually a known problem before the Pentium chip was released. What might have happened is, following the usual defect prioritization principles, it would have been given acknowledged but given less priority as the frequency of this bug happen was staggering 27000 years of spreadsheet use. Now, one may question this data's accuracy, which is probably a fair question but larger point that this case teaches is that the usual defect prioritization approach usually fail to consider the macro aspects impacting the product. Let me explain this point a little bit-
Pentium chip was released at the backdrop of the legendary "Intel Inside" marketing campaign. The extent of popularity (due to marketing efforts) of this campaign was so huge that Intel almost became a household brand. When people started seeing the effects of the error related to this, they put the blame squarely on Intel and not the computer manufacturer. The early social media in the form of Internet forums gave voice to their concerns. Had the defect prioritization decision, take into account the macro environment that the product will operate under, it would probably have been chosen to be fixed. 
One of the key learnings here that is still relevant in today's times is to have a holistic approach towards defect advocacy. A tester advocating the defect should relate the bug information with the macro environment happenings like business situation, popularity of the bug, users impacted and much more. For a tester to be playing the role of the headlights of the product, he/she should not just think about internals of the bugs but also associate it with the necessary business information and related factors.

What else do you learn from this case? Please do share your thoughts in the comments.

Images source:


Friday, November 13, 2015

Are the Lessons from Google Wave Debacle Still Relevant ?

In this blog (or hopefully a series of them), i intend to write about the key lessons to be learned not only from the tech products that failed in the past but also i intend to write a bit about why products succeed as well. The motivation to write this comes directly from my experience. I started my career with working on a large ecommerce product, which was (at that time) supposed to be the biggest technology application built entirely on Microsoft technology. Ok, the word "biggest" in the past sentence has more or less an anecdotal reference but the key point is that this project really struggled to find its feet due to various reasons. I will talk more about my own experience in the coming posts but to start off, i wanted to put a microscope on some of the public products that bit the dust. Failures, like success, leaves a lot to be learned from. My personal hypothesis is that most failures share similar reasons that led to eventual results. As a series of this blog, i want to test this hypothesis as well. I will try and bind my narrative to around 500 words so (covering top 3-4 reasons) that it remains within the readability limits.

The first product that pick for analysis is Google Wave. The reason I pick up this product is simply that i got to know a bit about this product while reading the book "How Google works" and it is quite fresh in my mind. As the book says- Google Wave as the creation of
a small team of engineers who took their 20 percent time to explore the question "What would email be like if it were invented today?" Google Wave was said to be a technological marvel, but it proved to be a major flop. Its user base never grew as expected (said to be close to 1 million or so) and Google eventually cancelled this project within one year of its launch in around 2010. Google Wave was said to be "collaboration and communication tool consolidating] core online features from e-mail, instant messaging, blogging, wikis, multimedia management, and document sharing,”

Some reasons for its failure as I researched as below-

Complicated User Experience:
As this Quora article suggests,
In retrospect, the lack of success of Google Wave was attributed among other things to its complicated user interface resulting in a product that was a bit like email, a bit like an instant messenger and a bit like a wiki but ultimately couldn't do any of the things really better than the existing solutions.

One of the studies even pointed that a celebrated Tech journalist even wrote a 195 page manual on how to use Wave.
This fact that someone need to write a hefty manual explaining a product alone would testify that Wave probably missed a trick or two in designing a simpler application. It appeared that it was not only hard to use but it was also perceived as hard to explain.

If we fast-forward to 2015, companies are adopting unbundling as a product strategy, which means that they are decoupling the features to make it more usable or focused e.g. Facebook unbundling messenger from the core app. It means that the world gets to value simpler, one feature app more than an app doing too many things, which Google Wave tried to do.

Launched with Lofty Expectations:
As this Mashable article suggests, The first lesson that Google or any web application developer can learn from Google Wave is the importance of managing expectations. Because the hype window started four months before Wave actually launched, the idea of what Wave was easily exceeded the reality. Phrases like "radically different approach to communication" and "e-mail 2.0" were bandied around, along with buzz-word laden phrases like "paradigm-shifting game-changer."

As I have experienced, when a product is launched with much fanfare, it always runs the risk of being subdued under its own expectations. This is something Intel observed when they launched Pentium chip (more about it in later blogs) when one edge case bug resulted in a loss of close to a half billion dollars majorly because of the marketing hype preceding it.

Lack of Extensions:
As one of the reasons cited in eweek- Google Wave was open sourced and yet failed to catch on with developers. While SAP, Novell and Salesforce.com all vowed to work with Wave, and there were a number of extensions created, the support didn't match that of other Google projects, such as Chrome, for which there are thousands of browser extensions. That's a big killer.

As I explained in one of my earlier blogs, in today’s tech era the successful products are more defined with a platform style architecture where building a successful ecosystem of developers is the key. The absence of incentives attracting enough developers timely impacted the speed at which extensions were created and hence resultant user adoption.

No Integration with Google Apps

Again a reason cited in one of the analysis- Google proudly displayed Wave as its own entity. It would have been better served attached to Google Apps similar to the way Google Buzz was tied to Gmail, with Google suggesting users try it out for certain collaboration functions in Google Docs or Sites.
Integration between products is one of the key problems faced with most big sized tech. companies that typically have multiple products in its portfolio. Big companies usually expands their portfolios by acquiring other companies. Acquisitions usually have a negative engineering impact when it becomes to integration because of conflicting architectures.
The book that I referred earlier- “How Google Works” described Google Wave as an ahead of its time product. I politely disagree to this given the fact that now, 5 years later, the world still doesn’t see a compelling reason to have a product like this. To be fair to Google Wave and its superior technology, Google did use the pieces of Wave platform in Google+ and Gmail. But hearing Eric Schmidt say that Google liked the Wave UI represents a sort of disconnect between what users felt and what management saw the product. At the core, this aspect is something that’s common across most product failures.

Please do share your thoughts, ideas around this blog.