Chasing Unknown Unknown, The Spirit Of Silicon Valley

A framework that I use to think about problems disruptive technology could help solve is based on what Donald Rumsfeld wrote in his memoir, Known and Unknown:

Reports that say that something hasn't happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns -- the ones we don't know we don't know. And if one looks throughout the history of our country and other free countries, it is the latter category that tend to be the difficult ones.

A couple of decades ago technology was seen as means to automate manual processes and bring efficiency. While largely automation is a prerequisite in the modern economy the role of technology has significantly changed to create unique differentiation and competitive advantage against peers in an industry. Many people are working on making things betters, cheaper, and faster or a combination of these three. This approach—solving known known—does provide incremental or evolutionary innovation and market does reward it.

But, the Silicon Valley thinks differently.

The Silicon Valley loves to chase known unknown problems, the moonshots, such as self-driving vehicles, providing internet access to every single human being on the earth, and private shuttles to space. These BHAG are totally worth chasing. To a certain degree, we do know and experience what the actual problem is and we can even visualize what a possible solution could look like. As counterintuitive as it may sound, but it is relatively easy to have entrepreneurs and investors rally towards a solution if they can visualize an outcome even if solving a problem could mean putting in a monumental effort.

"We can be blind to the obvious, and we are also blind to our blindness.” - Daniel Kahneman

Most disruptive products or business models have a few things in common: they focus on latent needs of customers, they imagine new experiences and deliver them to customers, and most importantly they find and solve problems people didn’t know they had and couldn’t imagine it could be solved - the unknown unknown.

Chasing unknown unknown requires bold thinking and a strong belief in you quest and methods to get there. Traditional analytical thinking will take you to the next quarter or the next year with a double digit growth but won’t bring exponential growth. These unknown problems excite me the most and I truly enjoy working on them. Unknown unknown is the framework that I use to understand the potential of disruptive technology such as Big Data and Internet of Things. If technology can solve any problem which problem you want to have it solved is how I think.

Chasing unknown unknowns is not an alternative to go for moonshots; we need both and in many cases solving an unknown unknown journey starts by converting it to a known unknown. The key difference between the two is where you spend your time -  looking for a problem and reframing it or finding a breakthrough innovation for a known corny problem. A very small number of people can think across this entire spectrum; most people are either good at finding a problem or solving it but not at both.

Discovering unknown problems requires a qualitative and an abductive approach as well as right set of tools, techniques, and mindset. Simply asking people what problems they want to have it solved they don’t know they have won’t take you anywhere. I am a passionate design thinker and I practice and highly encourage others to practice qualitative methods of design and design thinking to chase unknown unknowns.

I wish, as Silicon Valley, we don’t lose the spirit of going after unknown unknown since it is hard to raise venture capital and rally people around a problem that people don’t know exist for sure. Empowering people to do things they could not have done before or even imagined they could do is a dream that I want entrepreneurs to have.

Photo courtesy: Ahmed Rabea

Product Vision: Make A Trailer And Not A Movie

I have worked with many product managers on a product vision exercise. In my observation the place where the product managers get hung up the most is when they confuse product vision for product definition. To use an analogy, product vision is a trailer and product definition is a movie. When you're watching a movie trailer it excites you even though you fully don't know how good or bad the movie will be.

Abstract and unfinished

A trailer is a sequence of shots that are abstract enough not to reveal too much details about the movie but clear enough to give you the dots that your imagination could start connecting. Some of the best visions are also abstract and unfinished that leave plenty of opportunities for imagination. Product visions should focus on "why" and "what" and not on "how" and most importantly should have a narrative to excite people to buy into it and refine it later on. Vision should inspire the definition of a product and not define it.

I am a big believer of raw or low fidelity prototypes because they allow me to get the best possible feedback from an end user. People don't respond well to a finished or a shiny  prototype. I don't want people to tell me, "can you change the color of that button?" I would rather prefer they say, "your scenario seems out of whack but let me tell you this is what would make sense."

Non-linear narratives

Movie trailers are also the best examples of non-linear thinking. They don't follow the same sequence as a movie - they don't have to. Most people, product managers or otherwise, find non-linear thinking a little difficult to practice and comprehend. Good visions are non-linear because they focus on complete narrative organized as non-linear scenarios or journeys to evoke emotion and not to convey how the product will actually work. Clever commercials, such as iPad commercials by Apple, follow the same design principles. They don't describe what an iPad can do feature by feature but instead will show a narrative that help people imagine what it would feel like to use an iPad.

Means to an end

The least understood benefit of a product vision is the ability of using the vision as a tool to drive, define, and refine product requirements. Vision is a living artifact that you can pull out anytime during your product lifecycle and use it to ask questions, gather feedback, and more importantly help people imagine. I encourage product managers not to chase the perfection when it comes to vision and focus on the abstract and non-linear journey because a vision is a means to an end and not an end itself.

Photo courtesy: Flickr 

Why And How Should You Hire A Chief Customer Success Officer?

For an ISV (Independent Software Vendor) it is everyone's job to ensure customer success but it is no one person's job. This is changing. I see more and more companies realizing this challenge and want to do something about it.

Sales is interested in maintaining relationship with customers for revenue purposes and support works with customers in case of product issues and escalations. Product teams behave more like silos when they approach their customers because of their restricted scope and vision. Most chief technology officers are fairly technical and internal facing. Most of them also lack the business context—empathy for true business challenges—of their customers. They are quite passionate about what they do but they invariably end up spending a lot of time in making key product and technical decisions for the company losing sight of much bigger issues that customers might be facing. Most chief strategy officers focus on company's vision as well as strategy across lines of businesses but while they have strong business acumen they are not customer-centric and lack technical as well as product leadership to understand deep underlying systemic issues.

Traditional ways to measure customer success is through product adoption, customer churn, and customer acquisition but the role of a Chief Customer Success Officer (CCO) extends way beyond that. One of the best ways to watch early signs of market shift is to very closely watch your progressive customers. Working with these customers and watching them will also help you find ways to improve existing product portfolio and add new products, organically or through acquisitions. Participating in sales cycles will help you better understand the competition, pricing points, and most importantly readiness of your field to execute on your sales strategy.

I often get reached out by folks asking what kind of people they should be looking for when they plan to hire a CCO. I tell them to look for the following:

T-shaped: Customer don't neatly fall into your one line of business and so is your CCO. You are looking for someone who has broad exposure and experince across different functions through his or her previous roles and deep expertise in one domain. The CCO would work across LoBs to ensure customers are getting what they want and help you build a sustainable business. Most T-shaped people I have worked with are fast-learners. They very quickly understand continuously changing business, frame their point of view, and execute by collaborating with people across the organization (the horizontal part of T) due to their past experience and exposure in having worked with/for other functions.

Most likely, someone who has had a spectacular but unusual career path and makes you think, "what role does this person really fit in?" would be the the right person. Another clue: many "general managers" are on this career track.

Business-centric: Customers don't want technology. They don't even want products. They want solutions for the business problems they have. This is where a CCO would start with sheer focus on customers' problems—the true business needs—and use technology as an enabler as opposed to a product. Technology is a means to an end typically referred to as "the business."

Your CCO should have a business-first mindset with deep expertise in technology to balance what's viable with what's feasible. You can start anywhere but I would recommend to focus your search on people who have product as well as strategy background. I believe unless you have managed a product—development, management, or strategy—you can't really have empathy for what it makes to build something and have customers to use it and complain about it when it doesn't work for them.

Global: Turns out the world is not flat. Each geographic region is quite different with regards to aptitude and ability of customers to take risk and adopt innovation. Region-specific localization—product, go-to-market, and sales—strategy that factors in local competition and economic climate is crucial for global success of an ISV. The CCO absolutely has to understand intricacies associated with these regions: how they move at different speed, cultural aspects of embracing and adopting innovation, and local competition. The person needs to have exposure and experience across regions and across industries. You do have regional experts and local management but looking across regions to identify trends, opportunities, and pace of innovation by working with customers and help inform overall product, go-to-market, and sales strategy is quite an important role that a CCO will play.

Outsider: Last but not least, I would suggest you to look outside instead of finding someone internally. Hiring someone with a fresh outside-in perspective is crucuial for this role. Thrive for hiring someone who understands the broader market - players, competition, and ecosystem. This is a trait typically found in some leading industry analysts but you are looking for a product person with that level of thought leadership and background without an analyst title.

About the photo: This is a picture of an Everest base camp in Tibet, taken by Joseph Younis. I think of success as a progressive realization of a worthwhile goal.

Celebrating Failures

Being a passionate design thinker I am a big believer in failing fast and failing often. I have taken this one step further; I celebrate one failure every week. Here's why:

You get more comfortable looking for failures, analyzing them, and learn from it

I have sat through numerous post-mortem workshops and concluded that the root causes of failures are usually the same: abstract concepts such as lack of communication, unrealistic scope, insufficient training, and so on. If that’s true, why do we repeat the same mistakes, causing failure to remain a common situation? Primarily because many people find it hard to imagine and react to abstractions, but can relate much better when these concepts are contextualized into their own situation. Post-mortem of a project would tell you what you already suspected; it's hindsight and it's a little too late. I have always advocated a "pre-mortem workshop" to prepare for a failure in the beginning. Visualize all the things that could go wrong by imagining that the project has failed. This gives the team an opportunity to proactively look at risks and prepare to prevent and mitigate them.

Failures just like successes become nothing more than events with different outcomes

A failure or a success is nothing but an event. Just like sports you put in your best effort and still fail because you control your efforts, dedication, and passion but not the outcome. While it is absolutely essential to analyze mistakes and make sure you don't repeat them but in some cases, looking back, you would not have done anything differently. When you look at more failures more often they do tend to become events with different outcomes as opposed to one-off situations that you regret.

It changes your attitude to take more risk because you are not afraid of outcome

When failures are not a one-off event and you are anticipating and celebrating it more often it changes how you think about many things, personally as well as professionally. It helps you minimize regret and not failures.

I don't want to imply failure is actually a good thing. No one really wants to fail and yet failure is the only certainty. But, it's all about failing fast, failing often, and correct the course before it's too late. Each failure presents us with an opportunity to learn from it. Don't waste a failure; celebrate it.

About the picture: I took this picture inside the Notre Dame in Paris. I see lights as medium to celebrate everything: victory of good over evil as celebrated during the Hindu festival Diwali and a candlelight vigil to show support and motivate people for a change.

Thrive For Precision Not Accuracy

Jake Porway who was a data scientist at the New York Times R&D labs has a great perspective on why multi-disciplinary teams are important to avoid bias and bring in different perspective in data analysis. He discusses a story where data gathered by Über in Oakland suggested that prostitution arrests increased in Oakland on Wednesdays but increased arrests necessarily didn't imply increased crime. He also outlines the data analysis done by Grameen Foundation where the analysis of Ugandan farm workers could result into the farmers being "good" or "bad" depending on which perspective you would consider. This story validates one more attribute of my point of view regarding data scientists - data scientists should be design thinkers. Working in a multi-disciplinary team to let people champion their perspective is one of the core tenants of design thinking.

One of the viewpoints of Jake that I don't agree with:

"Any data scientist worth their salary will tell you that you should start with a question, NOT the data."

In many cases you don't even know what question to ask. Sometimes an anomaly or a pattern in data tells a story. This story informs us what questions we might ask. I do see that many data scientists start with knowing a question ahead of time and then pull in necessary data they need but I advocate the other side where you bring in the sources and let the data tell you a story. Referring to design, Henry Ford once said, ""Every object tells a story if you know how to read it." Listen to the data—a story—without any pre-conceived bias and see where it leads you.

You can only ask what you know to ask. It limits your ability to unearth groundbreaking insights. Chasing a perfect answer to a perfect question is a trap that many data scientists fall into. In reality what business wants is to get to a good enough answer to a question or insight that is actionable. In most cases getting to an answer that is 95% accurate requires little effort but getting that rest 5% requires exponentially disproportionate time with disproportionately low return.

Thrive for precision, not accuracy. The first answer could really be of low precision. It's perfectly acceptable as long as you know what the precision is and you can continuously refine it to make it good enough. Being able to rapidly iterate and reframe the question is far more important than knowing upfront what question to ask; data analysis is a journey and not a step in the process.

Photo credit: Mario Klingemann

A Data Scientist's View On Skills, Tools, And Attitude

I recently came across this interview (thanks Dharini for the link!) with Nick Chamandy, a statistician a.k.a a data scientist at Google. I would encourage you to read it; it does have some great points. I found the following snippets interesting:

Recruiting data scientists:

When posting job opportunities, we are cognizant that people from different academic fields tend to use different language, and we don’t want to miss out on a great candidate because he or she comes from a non-statistics background and doesn’t search for the right keyword. On my team alone, we have had successful “statisticians” with degrees in statistics, electrical engineering, econometrics, mathematics, computer science, and even physics. All are passionate about data and about tackling challenging inference problems.

I share the same view. The best scientists I have met are not statisticians by academic training. They are domain experts and design thinkers and they all share one common trait: they love data! When asked how they might build a team of data scientists I highly recommend people to look beyond traditional wisdom. You will be in good shape as long as you don't end up in a situation like this :-)

Skills:

The engineers at Google have also developed a truly impressive package for massive parallelization of R computations on hundreds or thousands of machines. I typically use shell or python scripts for chaining together data aggregation and analysis steps into “pipelines.”

Most companies won't have the kind of highly skilled development army that Google has but then not all companies would have Google scale problem to deal with. Though I suggest two things: a) build a very strong community of data scientists using social tools so that they can collaborate on challenges and tools they use b) make sure that the chief data scientist (if you have one) has very high level of management buy-in to make things happen otherwise he/she would be spending all the time in "alignment" meetings as opposed to doing the real work.

Data preparation:

There is a strong belief that without becoming intimate with the raw data structure, and the many considerations involved in filtering, cleaning, and aggregating the data, the statistician can never truly hope to have a complete understanding of the data.

I disagree. I do strongly believe the tools need to involve to do some of these things and the data scientists should not be spending their time to compensate for the inefficiencies of the tools. Becoming intimate with the data—have empathy for the problem—is certainly a necessity but spending time on pulling, fixing, and aggregating data is not the best use of their time.

Attitude:

To me, it is less about what skills one must brush up on, and much more about a willingness to adaptively learn new skills and adjust one’s attitude to be in tune with the statistical nuances and tradeoffs relevant to this New Frontier of statistics.

As I would say bring tools and knowledge but leave bias and expectations aside. The best data scientists are the ones who are passionate about data, can quickly learn a new domain, and are willing to make and fail and fail and make.

Image courtesy: xkcd

Commoditizing Data Science

My ongoing conversations with several people continue to reaffirm my belief that Data Science is still perceived to be a sacred discipline and data scientists are perceived to be highly skilled statisticians who walk around wearing white lab coats. The best data scientists are not the ones who know the most about data but they are the ones who are flexible enough to take on any domain with their curiosity to unearth insights. Apparently this is not well-understood. There are two parts to data science: domain and algorithms or in other words knowledge about the problem and knowledge about how to solve it.

One of the main aspects of Big Data that I get excited about is an opportunity to commoditize this data science—the how—by making it mainstream.

The rise of interest in Big Data platform—disruptive technology and desire to do something interesting about data—opens up opportunities to write some of these known algorithms that are easy to execute without any performance penalty. Run K Means if you want and if you don't like the result run Bayesian linear regression or something else. The access to algorithms should not be limited to the "scientists," instead any one who wants to look at their data to know the unknown should be able to execute those algorithms without any sophisticated training, experience, and skills. You don't have to be a statistician to find a standard deviation of a data set. Do you really have to be a statistician to run a classification algorithm?

Data science should not be a sacred discipline and data scientists shouldn't be voodoos.

There should not be any performance penalty or an upfront hesitation to decide what to do with data. People should be able to iterate as fast as possible to get to the result that they want without worrying about how to set up a "data experiment." Data scientists should be design thinkers.

So, what about traditional data scientists? What will they do?

I expect people that are "scientists" in a traditional sense would elevate themselves in their Maslow's hierarchy by focusing more on advanced aspects of data science and machine learning such as designing tools that would recommend algorithms that might fit the data (we have already witnessed this trend for visualization). There's also significant potential to invent new algorithms based on existing machine learning algorithms that have been into existence for a while. What algorithms to execute when could still be a science to some extent but that's what the data scientists should focus on and not on sampling, preparing, and waiting for hours to analyze their data sets. We finally have Big Data for that.

Image courtesy: scikit-learn

Empathize Not Sympathize

Many enterprise software vendors sympathize. "We know it's a bad experience" or "We will fix the usability." One of the reasons the software is not usable is because the makers never had any empathy for the end users who would use it. In many cases the makers didn't even know who their end users were; they only knew who would buy the software. As far as enterprise software is concerned people who write checks don't use the software and people who use software don't write checks and have a little or no influence in what gets bought. Though the dynamics are now changing.

Usability is the last step; it's about making software usable for the tasks that it is designed for. It's not useful at all when the software is designed to solve a wrong problem. Perfectly usable software could be completely useless.

It's the job of a product manager, designer, and a developer to assess the end user needs—have empathy for them—and then design software that meets or exceeds their needs in a way that is usable. That way they don't have to sympathize later on.

Design Thinking encourages people to stay in the problem space for a longer duration without jumping to a solution. What problem is being solved—needs—is far more important than how it is solved—usability. Next time you hear someone say software is not usable, ask whether it's the what or how. The how part is relatively easy to fix, what part is not. For fixing the "what" you need to have empathy for your end users and not sympathy.

Objectively Inconsistent

During his recent visit to the office of 37 Signals, Jeff Bezos said, "to be consistently objective, one has to be objectively inconsistent." I find this perspective very refreshing that is applicable to all things and all disciplines in life beyond just product design. As a product designer you need to have a series of point of views (POV) that would be inconsistent when seen together but each POV at any given time will be consistently objective. This is what design thinking, especially prototyping is all about. It shifts a subjective conversation between people to an objective conversation about a design artifact.

As I have blogged before I see data scientists as design thinkers. Most data scientists that I know of have knowledge-curse. I would like them to be  consistently objective by going through the journey of analyzing data without any pre-conceived bias. The knowledge-curse makes people commit more mistakes. It also makes them defend their POV instead of looking for new information and have courage to challenge and change it. I am a big fan of work of Daniel Kahneman. I would argue that prototyping helps deal with what Kahneman describers as "cognitive sophistication."

The problem with this introspective approach is that the driving forces behind biases—the root causes of our irrationality—are largely unconscious, which means they remain invisible to self-analysis and impermeable to intelligence.

This very cognitive sophistication works against people who cannot self-analyze themselves and be critical to their own POV. Prototyping brings in objectivity and external validation to eliminate this unconscious-driven irrationality. It's fascinating what happens when you put prototypes in the hands of users. They interact with it in unanticipated ways. These discoveries are not feasible if you hold on to single POV and defend it.

Let it go. Let the prototype speak your design—your product POV—and not your unconscious.

Photo courtesy: New Yorker

Data Scientists Should Be Design Thinkers

World Airline Routes

Every company is looking for that cool data scientist who will come equipped with all the knowledge of data, domain expertise, and algorithms to turn around their business. The inconvenient truth is there are no such data scientists. Mike Loukides discusses the overfocus on tech skills and cites DJ Patil:

But as DJ Patil said in “Building Data Science Teams,” the best data scientists are not statisticians; they come from a wide range of scientific disciplines, including (but not limited to) physics, biology, medicine, and meteorology. Data science teams are full of physicists. The chief scientist of Kaggle, Jeremy Howard, has a degree in philosophy. The key job requirement in data science (as it is in many technical fields) isn’t demonstrated expertise in some narrow set of tools, but curiousity, flexibility, and willingness to learn. And the key obligation of the employer is to give its new hires the tools they need to succeed.

I do agree there's a skill gap, but it is that of "data science" and not of "data scientists." What concerns me more about this skill gap is not the gap itself but the misunderstanding around how to fill it.

There will always be a skill gap when we encounter a new domain or rapidly changing technology that has a promise to help people do something radically different. You can't just create data scientists out of thin air, but if you look at the problem a little differently — perhaps educating people on what the data scientists are actually required to do and have them follow the data science behind it — the solution may not be that far-fetched as it appears to be.

Data scientists, the ones that I am proposing who would practice "data science" should be design thinkers, the ones who practice design thinking. This is why:

Multidisciplinary approach

Design thinking encourages people to work in a multidisciplinary team where each individual team member champions his or her domain to ensure a holistic approach to a solution. To be economically viable, technologically feasible, and desirable by end users summarizes the philosophy behind this approach. Without an effective participation from a broader set of disciplines the data scientists are not likely to be that effective solving the problems they are hired and expected to solve.

Outside-in thinking and encouraging wild ideas

As I have argued before, the data external to a company is far more valuable than the one they internally have since Big Data is an amalgamation of a few trends - data growth of a magnitude or two, external data more valuable than internal data, and shift in computing business models. Big Data is about redefining (yet another design thinking element, referred to as "reframing the problem") what data actually means to you and its power resides in combining and correlating these two data sets.

In my experience in working with customers, this is the biggest challenge. You can't solve a problem with a constrained and an inside-out mindset. This is where we need to encourage wild ideas and help people stretch their imagination without worrying about underlying technical constraints that have created data silos, invariably resulting into organization silos. A multidisciplinary team, by its virtue of people from different domains, is well-suited for this purpose.

What do you do once you have plenty of ideas and a vision of where you want to go? That brings me to this last point.

Rapid prototyping

Rapid prototyping is at the heart of design thinking. One of the common beliefs I often challenge is the overemphasis on perfecting an algorithm. Data is more important than algorithms; getting to an algorithm should be the core focus and not fixating on finding the algorithm. Using the power of technology and design thinking mindset, iterating rapidly on multiple data sets, you are much likely to discover insights based on a good-enough algorithm. This does sound counterintuitive to the people that are trained in designing, perfecting, and practicing complex algorithms, but the underlying technology and tools have shifted the dynamics.

Loving What I Do For Living

A few months back, I was helping a very large customer of ours to help simplify as well as automate their process of trading financial instruments. During one of my many visits to their office, I met a person who was trying to explain to me his job in supporting the people that are involved in this super complex process. I always ask a lot of questions — until they're totally annoyed and ready to kick me out of the room — to get a complete understanding of the business rationale behind whatever they're thriving for and their personal motivation behind it. Something unusual happened at this meeting. Instead of getting into the gory technical details of how they get things done, he chose to tell me a short and simple story.

"You know, um.. there's this early morning meeting everyday that Peter goes to with a bunch of other people. They all gather around a large table in a dimly lit conference room with a bunch of printed spreadsheets, a laptop, and a large calculator. Peter has a cup of coffee in one hand and a cigarette in the other hand talking to people who have coffee cups in their one hand and cigarettes in the other hand. This is their lives. I am concerned about Peter and I want him to stop smoking. Can you please help me?"

Now, this is the job that I love that makes me get out the bed and run for it. This is the human side of enterprise software. It's not boring.

Photo Courtesy: Jane Rahman

Design thinking: A New Approach To Fight Complexity And Failure

Photo credit: String Theory by Michael Krigsman

The endless succession of failed projects forces one to question why success is elusive, with an extraordinary number of projects tangling themselves in knots. These projects are like a child’s string game run amok: a large, tangled mess that becomes more convoluted and complex by the minute.

IT projects fail all the time. Business blames IT, IT blames the system integrator (SI), who then blames the software vendor. After all this blaming and shaming, everyone goes back to work on another project without examining the project management methods and processes that caused the failure. And, so, they fail again.

There’s no one definition of design thinking. It’s a mindset and set of values that applies both analytical and creative thinking towards solving a specific problem. Design thinking is about how you think and not what you know; it is about the journey and not the destination.

Having followed Michael Krigsman’s analysis of IT project failures, it became evident that design thinking can play an important role in improving enterprise software development and implementation. 

The design thinking approach offers a means to address the underlying causes of many project failures — poor communication, rigid thinking, propensity toward tunnel vision, and information silos.

I have distilled important lessons from design thinking into six principles that can help stop project failures. Along the way, we will draw comparisons with Agile development, since that distinction is often a source of confusion when discussing design thinking.

These six principles, based on design thinking, can help any project team operate more successfully.

1. Put a multi-disciplinary team in charge

You can’t pin down project failure on one person or one topic and yet we continue to use a person-centric method to manage projects. No one on a project team wants to fail. If you collectively put responsibility of the failure or success on the shoulders of the team and get them trained and motivated to think and behave differently you will mitigate much failure.

Multidisciplinary teams champion the user, business, and technology aspects of a project in a more comprehensive manner than would otherwise be possible. Typically, an IT team talks to business stakeholders who then talk to end users, which creates communication gaps, delays, and inefficiency. Far better to create a single team that includes participants from all areas, creating a single unit that includes multiple perspectives.

Try to staff your project team with “T-shaped” people, who possess a broad understanding and empathy for all the IT functions, but who also have deep expertise in one domain to champion that perspective. This approach can ensure that your solution is economically viable, technologically feasible, and delights the end users. A more balanced team also humanizes the project and its approach. Stay small and resist the temptation to set up very large teams. If you believe the “two-large-pizza-team” rule, those projects are team-driven and tend to be more successful. Start-ups can build something quicker because they are always short on people. As your group get bigger and bigger, other people tell you what to do and team members feel less connected to their work as it relates to the outcome.

2. Prepare for failure in the beginning

I recommend kicking off the project with a “pre-mortem workshop.” Visualize all the things that could go wrong by imagining that the project has failed. This gives the team an opportunity to proactively look at risks and prepare to prevent and mitigate them. I have sat through numerous post-mortem workshops and concluded that the root causes of failures are usually the same: abstract concepts such as lack of communication, unrealistic scope, insufficient training, and so on. If that’s true, why do we repeat the same mistakes, causing failure to remain a common situation? Primarily because many people find it hard to imagine and react to abstractions, but can relate much better when these concepts are contextualized into their own situation.

3. Be both vision- and task-driven

Design thinking emphasizes storytelling, shared vision, and empathy towards all stakeholders involved in a project. On many projects, participants focus exclusively on their own individual tasks, thus becoming disconnected from the big picture.

While design thinking strives to connect participants to the larger vision, Agile development can be very task-driven. Everyone gets a task without necessarily understanding the big picture, or vision, or even seeing the connection between his or her tasks and the final outcome. In this situation, a project can fail and people may not understand their role, thinking they failed due to someone else’s work. If participants don’t realize their tasks contributed to a failure, they won’t try to learn and change.

On the other hand, vision-driven approaches are very powerful. People perform their tasks, but the story and vision persist throughout the project; the same story gets told by different people throughout the lifecycle of the project to avoid that big picture fading away. All the tasks have a bigger purpose beyond their successful execution. Even good project managers miss this point. At review meetings, it is important to evaluate what the team did right but also revisit the vision and examine how recent outcomes fit the overall story.

4. Fail and correct then fail again

Design thinking contradicts other methodologies that focus only on success. In design thinking, failing is not necessarily a bad idea at all; however, we fail early and fail often, and then correct the course. In many projects, people chase success without knowing what it looks like or expecting to fail; therefore, they do not learn from the process.

One of the challenges with traditional project management is the need to pick one alternate and run with it. Turns out that you don’t know everything about that alternative and when it fails, due to the irreversible decision that you made, you can’t go back. Far better to iterate on a number of alternatives as fast as you can before deciding which one will work. This approach requires a different way of thinking and planning your project.

5. Make tangible prototypes

Agile proposed creating unstructured documentation as opposed to making structured requirement documents. But, unfortunately, that is not enough to solve many problems. One of the core characteristics of design thinking is to prototype everything, to make a tangible artifact and learn from it. The explorative process of making prototypes makes people think deeply and ask the right kind of questions. It’s said that “computers will never give a wrong answer but it will respond to a wrong question.” The prototypes encourage people to focus on what I want to know as opposed to what I want to say. This is very important during the initial design phase of the project.

One of the biggest misconceptions about prototypes is that people think they are too complex to make and are overhead or a waste of time. This isn’t true at all. Prototypes can be as simple as a hand-drawn sketch on a paper or as complex as fully functional interactive interface. The fidelity of a prototype is based on what kind of questions you want answered. People tend to fill in gaps when they see something raw or incomplete whereas hi-fidelity prototypes can be too complete to solicit meaningful feedback. As I already mentioned, most people respond better to an artifact as opposed to an abstract document. Prototypes also make the conversation product-centric and not person-centric. They also help to get team members on the same page with a shared vision.

6. Embrace ambiguity

One of the problems with traditional project management methodologies is that they make people spend more time in executing the solution and less time on defining the problem. Design thinking encourages people to stay in the problem space as long as they can. This invariably results in ambiguity, which is actually a good thing.

Ambiguity fosters abductive thinking — a mindset that allows people to explore what is probable with the limited information on their hands without concerns about proving or concluding that it actually works. It helps people define a problem in many different ways, eventually letting them get to the right problem they eventually should focus on.

This also supports the emergent approach that design thinking advocates as opposed to a hypothesis-driven approach. In a hypothesis-driven environment, people tend to focus on proving a premise created by a small group people. Rushing to a solution without defining the problem, and having no emergent framework in place to include the insights gained during later parts of the project, certainly contributes to failure.

ORGANIZATIONAL BARRIERS TO SUCCESS

Even the best methodology requires organizational commitment to success. For design thinking to work, it is also necessary to address these common organizational issues, each of which can impede progress and limit successful outcomes.

Lack of C-level commitment: Although design thinking is applicable at all levels in an organization, executive management must bless it by publicly embracing and practicing design thinking. Top down initiatives and training only go so far.

When the employees see their leaders practice design thinking they are more likely to embrace and practice it themselves. The same is true with adoption of social media and collaborative tools inside an organization. The best signal to your employees is by showing them a firm belief in the method by practicing it firsthand and sharing positive outcome.

Resistance to change: People in any organization are usually fundamentally against change, even if they believe it’s a good thing. They don’t want to get out of their comfort zone and therefore practice the same methods that have resulted in multiple failures in the past. Changing behavior is difficult but fortunately design thinking can help.

One of the ways I have taught design thinking is by taking people away from their primary domain and have them solve a very different kind of problem such as redesigning a ticket vending machine or a fast food restaurant. My team was hugely successful since it was a completely different domain and it didn’t interfere with their preconceived notion of how a project should be executed. People’s reservations are tied to their domain; they are willing to adopt a new method and new way of thinking if you coach them outside of their domain and then encourage to practice it in their comfort zone.

Lack of industry backing: Despite being informal, undocumented, and non-standards-based methodology, Agile experienced widespread adoption. I would attribute this success to two things: a well-defined manifesto by lead industry figures and organizations publicly committing to adopt the methodology. Design thinking lacks these attributes.

Even though industrial design companies such as IDEO has evangelized this approach, there’s still confusion around what design thinking actually means. This also makes it difficult to explain design thinking to a wider audience. If a few organizations publicly endorse design thinking, create a manifesto, and share the best practices to gain momentum, many of the adoption hurdles will go away.

Lack of key performance indicator (KPI) frameworks: Design thinking faces the same challenge that most Enterprise 2.0 tools face: lack of measurable KPIs.

For number-driven leaders, lack of a quantifiable framework to measure and monitor the impact of a new methodology is a challenge. Some leaders are good at adopting new ways of doing things and others are not. In these cases, isolate a project that you can’t measure and start small. Contain the risk but pick a project that has significant upside, to keep people engaged and motivated. You may still fail, or not achieve a desired outcome, but that’s what the design thinking is all about.

It’s worth noting that Agile, as a software project methodology, has well defined quality and reliability KPIs such as beta defects, rejected stories during a scrum cycle, and the delta between committed and delivered stories.

Fail early and course correct the next time. Remember that adoption and specific practice need correction and not the method itself. Don’t give up.

FINAL THOUGHTS

During my extensive work on design thinking - practicing, coaching, and analyzing — I often talk with people who believe that design thinking is merely a methodology or approach for “visual design.” This view is a false perception. Design thinking comprises a set of principles one can apply during any stage of the enterprise project lifecycle along with other project management methodologies. This approach is valid for the CEO and executive management all the way to the grass roots.

Another common point of confusion is the distinction between design thinking and Agile methods of software development. The primary difference is that Agile offers a specific set of prescriptive processes while design thinking encapsulates a set of guidelines and general principles. Although not the same, the two approaches are highly complementary (even on the same project), because both recognize the benefits of using iterative work cycles to pursue customer-centric goals.

Always remember that real people work on every project. The best methodologies are inherently people-centric and help participants anticipate likely causes of failure. Visualizing failure early in a project is an excellent means to prevent it from occurring. We’re all human and may make mistakes but certainly no one wants to fail.

Design thinking can make potential failure a learning tool and not a final outcome.

_______

I had originally published this post as a guest blog post on Michael Krigsman's IT Project Failures blog

Taking The Quotes Out Of "Design Thinking"

Bruce Nussbaum, a design thinking thought leader and a professor of Innovation and Design at Parsons The New School of Design, recently wrote that Design Thinking Is A Failed Experiment.

He claims that:

"Design Thinking has given the design profession and society at large all the benefits it has to offer and is beginning to ossify and actually do harm."

Rubbish.

I would argue otherwise. Design thinking is not a catchphrase anymore, and that perhaps is an issue for someone like Bruce who wants to invent a new catchphrase to sell his book. When I tweeted his post, Enric Gili - a friend, co-worker, and a design thinker whom I respect - had to say this:

I couldn't agree anymore. I have learned, practiced, and taught design thinking, for living. I have worked with folks from IDEO, closely, very closely. I have mentored students at Stanford d.school and I live and breathe design thinking. I don't think of it as a method that goes out of fashion. For me, it's a religion, a set of values, and an approach that I apply to all things that I do on daily basis.

I have taken the quotes out of "design thinking".

Just as I don't get excited by the rounded corners and gradients of Web 2.0 I don't think of design thinking as voodoo dolls. To some, this appears to be a failure of design thinking. Design thinking has gone mainstream; it is not dead. What is dead is a belief that it's a process framework that can fix anything and can even cook dinner for you. Design thinking is an approach that codifies a set of values. Design thinking is not an innate skill. It can be taught, gained, and practiced.

"I place CQ within the intellectual space of gaming, scenario planning, systems thinking and, of course, design thinking. It is a sociological approach in which creativity emerges from group activity, not a psychological approach of development stages and individual genius."

Design thinking is ambidextrous; it advocates abductive as well as deductive thinking. The "design" in design thinking is an integrative discipline. As my boss used to tell me, you can't have Ph.D in design. Unless you're a smartypants clever clogs, it doesn't make sense. If CQ is a sociological-only approach, it fundamentally defies the inclusive and integrative values of design, which is a vital driver for creativity.

"It’s 2020 and my godchild Zoe is applying to Stanford, Cambridge, and Tsinghua universities. The admissions offices in each of these top schools asks for proof of literacies in math, literature, and creativity. They check her SAT scores, her essays, her IQ, and her CQ."

It's 2020 and IDEO has gone out of business and so is d.school. I am applying for a new job and they measure my CQ. I miserably fail at this CQ thing, perhaps. Do I care? Absolutely not. I have got my design thinking value system that may not be catchy to sell a book, but good enough to get my job done, spectacularly.

Creative Quotient? Give me a break.

Designing An Innovation Incubator To Prevail Over Innovator's Dilemma

The large scale software companies often deal with the tension between incremental and revolutionary innovation. They know that if they only keep listening to their customers' requests the very same customers will put them out of the business. Clayton Christensen has captured this phenomenon in The Innovator's Dilemma. Over a period of time these companies have managed to execute the incremental innovation really well to deliver the same software release after release and occasionally introduce new products. However most of these companies struggle to incubate revolutionary innovation inside the company since it is fundamentally a different beast. The executives are often torn between funding the revolutionary initiatives to ride the next big wave and funding the incremental innovation that the current customers and the market expects. It is absolutely imperative for the executive management to differentiate between these two equally important but very different types of innovation opportunities. Many companies have set up in-house incubators to bring revolutionary innovation to the market but in most cases the incubators are set up as yet another department inside the company that shares the same legacy and bureaucracy. Following are some suggestions on setting up and running an incubator to avoid the innovation disappear down the rat hole:

6x6 cubicle in Iowa won't cut it: There is nothing wrong with Iowa but I won't build an incubator there. Pick a location that emanates entrepreneurial spirit, attracts talent, and is surrounded by good colleges. Scout for a location that has good work-life characteristics where people feel the energy and have social outlets - pubs, hiking trails, good restaurants etc. San Francisco and Palo Alto in the Silicon Valley are a couple of examples of such locations.

I cannot overemphasize the impact of an inspirational physical space that fosters innovation and drives people with insane urge to be creative and build something disruptive. Ditch Steelcase and shop at IKEA. Have a loft-like set-up with open seating, project rooms instead of conference rooms, and have all the furniture on the wheels. Can you write on all the walls? Have alternate comfortable seating all over the places - bean bags, red couches, chairs and coffee tables with tall bar stools. Innovation does not happen in a cubicle. Have an entire team paint the loft with bright colors as a team-building exercise. Pay a mandatory visit to IDEO and d.school in Palo Alto if you haven't already been there.

No process is the new process: The incubator should not inherit your organization's legacy processes. You cannot expect your employees to behave differently to solve a problem if they are restricted by the same process overhead. Throw your application policing process out of the window and let people experiment with whatever works well for them. One of the main reasons why incubators fail because they rely on the organization's product roadmap and capabilities. Don't pick up any dependencies instead simply consider your organization's capabilities as one more source that you can evaluate for your needs. Use open source as much as you can, build your own partner relationships, and OEM whatever you can.

Pizza-size multidisciplinary teams: Can your entire product team be fed on two large pizzas? Smaller and tighter teams reduce the communication overhead, churn, and produce amazing results. Don't follow your corporate headcount calculations. Go for smaller teams. Hire I-shaped and T-shaped people to form a multidisciplinary team. Have a good mix of internal people who understand the business that you are into and the external people that are entrepreneurs or have worked in incubators. Get help from the external recruiters to find the right people since the internal recruiters may or may not have expertise to find and hire the kind of people that you are looking for.

Be agile and design think everything: Design thinking and agile methodology empower the teams to apply an ambidextrous and iterative approach to take on the revolutionary ideas in highly ambiguous environment. Encourage wild ideas, defer judgment, and be iterative. Be visual in storytelling, stay close to your customers and end-users, and have persuasive, catalysts, and performance design. Focus on useful over usable. Have a good-enough mindset and ship often to get continuous feedback to keep improving. Iterate as fast as you can and keep your sprint cycles small.

Seed, Round A, and Round B: This is where many organizations get hung up on an upfront $200M business case to qualify the business opportunity as incubation-worthy. If all the start-ups required to have a detailed upfront business model we would not have had Twitter, Facebook, Google, Craigslist etc. The same incremental business case mindset simply won't work for revolutionary innovation. The disruptive innovation has characteristics that many people haven't seen their in their lifetimes. The organization need to adopt the VC model and embrace the high risk high reward business environment. There will be plenty of failures before you hit a jackpot but that's the fundamental premise of VC funding. Have a separate budget and an investment decision process that provides autonomy to an incubator to make their own decisions without going through a long chain of command. Have multiple rounds of funding to ensure that you are tracking the potential of the innovation right from the seed to the maturity.

Explore all exit strategies: Don't expect to go-to-market with everything that comes out of an incubator. The mainstream product teams in your organization may or may not embrace and support the innovation citing the reasons "not invented here" or "too radical". Focus on your customers and success stories. If you are successful people will come to you instead of you selling the outcome to the organization. Be courageous and kill the products that are not working out and experiment with other exit strategies such as spin-offs, outright sale etc. Try to keep the product portfolio moving. High volume and turnover is a good thing for an incubator. Financial success is not the only success that counts; happy customers, re-invigorated organization, and global visibility as an innovation player are equally important KPI.

Reward high risk behavior: People work for uncertain and highly ambiguous projects for two reasons - higher reward for higher risk and passion to build something new. Design your compensation structure that is fundamentally different than your corporate title-driven compensation and includes a generous equity option. The titles don't mean much when it comes to an incubator. What really matters is the skills, attitude, and the knowledge that people bring to the table. The career path in an incubator is very different than a conventional corporate ladder. Make sure that all the people that are part of an incubator truly understand what they are signing up for and are passionate for the work rather than simply waiting to be a "Chief Innovation Officer".

Accelerating Social Computing: Web 2.0 + Cloud = Web²

I was at the Web 2.0 expo in San Francisco last week. It was not very different from the previous year except that I could see the impact of slow economy - shrinking attendance, less crowded booths, and "Hire Me" ribbons. Tim O'Reilly's keynote was interesting. He said that Web 2.0 was never about the version number (read, he does not like people calling Web 3.0 a successor of Web 2.0). He had the equation Web 2.0 + World = Web Squared. I changed it to Web 2.0 + Cloud = Web². The cloud seems more appropriate and the superscript is much cooler. If this catches on, remember, you read it here first!



The biggest shift that I have observed in Web 2.0 is the exponential growth of social media. This was evident at the Web 2.0 expo by looking at the number of participating social computing companies. Web 2.0 is certainly taking the direction of social computing. Tim mentioned in his keynote that the immense data gathered by the sensors and other means have hidden meaning in it and the applications have begun to understand this meaning. I could not agree any more; that justifies replacing the word "World" with "Cloud". Amazon's recent announcement to offer MapReduce on EC2 and Cloudera's $5M series A funding to commercialize Hadoop are early indicators of the rising demand for data-centric massive parallel processing. The cloud is a natural enabler to this evolution that will help gather data, context, and the interactions to amplify social conversations and create network effects. As John Maeda in his keynote said - people want to be human again. As Bill Buxton says :

User-centered design commonly tries to take into account different canonical user types through the use of persona. Perhaps one thing we need to do is to augment this tool with the notion of "placona," that is, capturing the canonical set of physical and social spaces within which any activity we are trying to support might be situated. After all, cognition does not reside exclusively in the brain. Rather, it is also distributed in the space in which we exercise that knowledge—in the location itself, the tools, devices, and materials that we use, and the people and social context in which all of this exists.

If one of the purposes of design and innovation is to improve our lives—for business, artistic, or familial purposes—then design that does not consider the larger social, cultural, and physical ecosystem is going to miss the mark.

Social computing is fundamentally a distributed problem that requires to make sense out of people's social and physical interactions with other people and objects including the context. The cloud can make this feasible and we can truly accelerate towards Web². I think Tim will most likely drop the 2.0 from Web 2.0 next year - that in itself would be a great first step in leaving Web 2.0 behind and start the journey towards Web².

Design Thinking Sustainability

The designers have been designing tools, processes, and methods to support and not to change people's behavior. In contrast designing for sustainability would fundamentally require changing people's behavior. The behavior change to achieve the sustainability goals would mean offering different alternatives, encourage reduced consumption, make people conscious of their behavior, and leverage peer pressure and competition. The design that maintains status quo will not help to achieve sustainability goals. The design will have to be provocative and challenge user's assumptions in many ways.

Design Thinking is about how you think and not what you know; it is about the journey and not the destination. For a problem of massive scale such as sustainability where we still know a little and the desired outcome may take years, following are some elements of design thinking that could help make world a better place to live for the generations to come.

Ambidextrous-thinking: Sustainability being fundamentally a sociological, psychological, and economical problem designers not only need to synthesize what they observe but to also design their solutions based on well-analyzed hard facts. It requires the designers to use both sides of their brains, left and right, to feel and to think. Human beings respond to positive and negative incentives e.g. charging people for grocery bags, allow hybrids cars in the carpool lanes etc. Ambidextrous approach allows designing creative incentives such as showing real-time gas consumption in Prius that changes the driver's behavior. It also prevents blindly rolling out initiatives that feel right but are outright wrong such as paper bags instead of plastic. Even though they are easy to down-cycle paper bags consume more energy to manufacture compared to plastic bags. All types of reasoning - inductive, deductive, and abductive - are quintessential to dream, design, and validate the solutions.

Analogous research: This approach allows designers to explore analogous problems with similar characteristics in other domains to gain insights and be inspired. Weight loss programs and alcohol support groups use social levers such as community support, peer pressure, and competition to help change people's behavior. The green social networks such as Carbonrally and Climate Culture are designed to leverage social competition towards green living. Similarly the community support aspect behind the fast growing fitness chain for women, Curve, can be applied to understand the role of community in changing people's behavior. Wiser Earth is an effort in this direction that uses community to connect people with non-profit and businesses to work together towards a sustainable world.

Researching an analogous domain is even more important when the primary domain such as sustainability does not allow to experiment the solution effectively due to its dry, non-tangible, and emerging nature. When given a task to design an emergency room a few people from IDEO went to a NASCAR race to observe the pit crew to better understand what kind of things can go wrong under emergency and how people respond to those events.

Empathy: Put yourself in the shoes of the people you are trying to change. As Thomas Friedman says people are having a green party and not a green revolution. Go to these green parties and follow people around to better understand what it will take to turn these parties into a true green revolution. Is it lack of awareness, motivation, or an incentive? Gain empathy for the people and understand their perspective in their context - what will it take socially and economically for them to change their behavior?

Context is critical for design thinking. Observing and talking to people in their natural environment designers gain empathy for the people and discover behavior patterns that they would have not found had they sat in their offices thinking how they should change people's behavior.

Holistic multidisciplinary approach: The sustainability efforts span across different culture, countries, background, and belief systems. To successfully solve this problem from the tools, behavior, and policies perspective people from the different disciplines such as engineers, scientists, interaction designers, social scientists, policy makers, and business executives need to come together and collaboratively work on it. Naive, curious, and inclusive mindset allows designers to holistically study the problem from the perspective of all the stakeholders - manufacturers, consumers, policy makers etc. The tools, technology, incentives, and policies, if designed in isolation, leave out gaps and often result into confirmation bias.

Be tangible and iterate often: This is a daunting problem and boiling the ocean would lead to an analysis paralysis nightmare. This is not a mature domain and there are no certainties around what will work and what won't. The best approach would be to rapidly prototype a solution to get early feedback from the consumers and iterate it often. There has been an ongoing debate on carbon tax versus carbon cap-and-trade. Instead of getting stuck in the controversy, opinions, and abstract ideas there is an opportunity to build something tangible and let people validate their own assumptions. A tangible object against an abstract concept enables better conversations and feedback channels since it is about the solution and not about the problem.

Focus on journey and emergent experimentation: Design thinking is about thinking in a different way and not about having any specific skills. It focuses on the journey, the method, and not on the outcome. People demand instant gratification but sustainability is not like the biggest looser competition where your weekly weigh-in would tell you where you are. It will take us years before we can actually quantify the impact of sustainability efforts that we are asking people to put in today. It is one of those initiatives that may not see any short term benefits at all. For such initiatives top-down compliance strategy won't work. A good design with emergent experimentation will focus on the journey and not the destination with the iterative results on the way to convince people how a change in their behavior slowly change the world around them. People will believe in the journey and the emergent experimentation.

Update: John R. Ehrenfeld who is currently serving as an Executive Director of the International Society for Industrial Ecology prior to his career as the Director of the MIT Program on Technology, Business, and Environment, an interdisciplinary educational, research, and policy program has picked up this story and posted on his blog Sustainability by Design.

Incomplete Framework Of Some Different Approaches To Making Stuff

Steve Portigal sent me an article that he wrote in the Interactions magazine asking for my feedback. Unfortunately the magazine is behind a walled garden and would require a subscription but if you reach out to Steve he should be able to share the article with you. In the absence of the original article I will take liberty to summarize it. Steve has described how companies generally go about making stuff in his “incomplete” framework:

• Be a Genius and Get It Right: One-person show to get it right such as a vacuum cleaner by James Dyson.
• Be a Genius and Get It Wrong: One-person show to get it wrong such as Dean Kamen’s Segway.
• Don’t Ask Customers If This Is What They Want: NBA changing the basketball design from leather to synthetic microfiber without asking the players
• Do Whatever Any Customer Asks: Implementing the changes as requested by the customers exactly as is without understanding the real needs.
• Understand Needs and Design to Them: Discovery of the fact that women shovel more than men and designing a snow shovel for women.

I fully agree with Steve on his framework and since this is proposed as an incomplete framework let me add few things on my own:

Know who your real customer is:

For enterprise software the customer who writes the check does not necessarily use the software and most of the time the real end users who use the software have no say in the purchase or adoption process. Designing for such demographics is quite challenging since the customers’ needs are very different than user needs. For instance the CIO may want privacy, security, and control where as the end users may want flexibility and autonomy and to design software that is autonomous yet controlled and secured yet flexible is quite a challenge. As a designer pleasing CIO for his or her lower TCO goals and at the same time delighting end users gets tricky.

Designing for children as end users and parents as customers also has similar challenges.

Look beyond the problem space and preserve ambiguity:

Hypothesis-driven user research alone would not help discover the real insights. Many times the good design emerges out of looking beyond your problem space.

If Apple were to ask people what they would want in their phones people might have said they want a smart phone with a better stylus and they do not expect their phone to tell them where they should eat their dinner tonight. We wouldn’t have had a multimodal interface on iPhone that could run Urbanspoon.

Embracing and preserving the ambiguity as long as you can during the design process would help unearth some of the behaviors that could lead to great design. Ambiguity does make people uncomfortable but recognizing that fact that “making stuff” is fundamentally a generative process allows people to diverge and preserve ambiguity before they converge.