Innovating with Design Thinking

When, why, and how to use Design Thinking methods to solve problems and create opportunities for organisations and individuals

Five Stages of Design Thinking
Five stages of Design Thinking

Design Thinking is a framework for product or service innovation that focuses on enhancing a user’s experience with your product or service.

In applying the framework, we create artifacts that capture our understanding of the current user experience, and then we generate scenarios, prototypes, and roadmaps that resolve the issue and create potential for growth.

In this workshop, we uncover the user’s “pains and gains” when they use your service or product (or similar services or products). We then generate ideas and scenarios that address these pains and gains, converging on a set of opportunities for innovation.

 “There are three spaces to keep in mind: inspiration, ideation, and implementation. Inspiration is the problem or opportunity that motivates the search for solutions. Ideation is the process of generating, developing, and testing ideas. Implementation is the path that leads from the project stage into people’s lives.”

Innovation with Design Thinking aims to optimize the “desirability, feasibility, and viability” of a product or service.

The feasibility, desirability, and viability of Design Thinking
The nexus of feasibility, desirability, and viability

In the following articles in this series, we’ll look at how we create artifacts that help us to capture our understating of the users’ problem(s), define the business challenge, and generate ideas for solutions.

How the cloud changes the role of the product manager

by Paddy Barrett

This  post originally appeared in IBM’s Technical Rockstar blog in 2015 and is derived from my MSc thesis.


“Cloud is going to change the way I.T. operates,” said Ginni Rometty in 2103, referring to the paradigm shift from on-premises software to the cloud. But how does this shift impact the role of the software product manager and traditional product management activities such as cross-functional collaboration, customer relationships, and life cycle management? To find out, I interviewed ten product managers, both within and outside IBM, about their experiences of managing both on-premises and cloud products, and specifically to address the following goals:

  • Understanding why cloud products require a different product management approach.
  • Identifying the differences in product management activities between cloud and on-prem products.
  • Developing recommendations for practice in managing cloud products.

All ten interviewees felt that the biggest impact on the product manager’s role was that created by continuous delivery, where a product could be released on a much more frequent basis than its on-premises equivalent. Continuous delivery adds a new degree of flexibility because the product manager can improve the product much faster than in an on-premises context. Continuous delivery also enables product managers to respond more rapidly to customer requirements.

The other notable areas of change were cross-functional collaboration, innovation, the gathering of requirements, and customer relationships. The relative weight of the each theme is illustrated in Figure 1.

Figure 1. The top themes for cloud product managers.

The interviewees stressed the need to understand the differences between the cloud and on-premises models and to be able to explain those differences to their customers. Let’s look at these changes in detail later, but first ask: what does a product manager actually do?

The Product Manager’s role

Although product management combines elements of engineering, design, marketing, sales, and business development, the role demands specific skills, including an inclination towards continuous learning, a strategic mindset, networking and problem-solving abilities, and good decision-making instincts.

Many of the activities of the product manager in the cloud are largely identical to those in the longer release cycle in the on-premises paradigm, but with some key differences. There is still the same need to research the market, listen to customers, understand technology, and work cross-functionally.

What’s different in the cloud

The role of the product manager of cloud products differs in several significant ways from the way it is performed in the on-premises paradigm. The two defining characteristics of these changes are speed and flexibility: the increased speed at which cloud products change and cloud-based product management activities take place; and the new degree of flexibility required of the role.

Continuous delivery

Both of these factors – speed and flexibility – are integral to the continuous delivery characteristics of cloud software. The rapid rate at which cloud products can change is one of the most important differences between the cloud and on-premises paradigms. Instead of waiting several months to update an on-premises product, product managers have an increased flexibility to repeatedly update cloud products. Furthermore, they can update all cloud customers simultaneously instead of having to manage multiple versions of on-premises releases. This flexibility is supported by the agile development process, which is designed to yield an incremented product that can be released at the end of each development iteration.

“Continuous release provides product managers with a lot of flexibility that they didn’t have in the past – from having to collect a group of new features and releasing them all at once, to releasing everything iteratively.”

Product managers have to adapt to the continuous delivery process by re-engineering and automating the processes of building, testing, and deploying the updated software. Additionally, to facilitate customers who do not want continuous updates, the product manager has to devise an appropriate single- or multi-tenancy strategy for the product. One of the biggest challenges posed by continuous delivery is the need for product managers to change the internal culture of their organizations to mirror the speed and flexibility of continuous delivery.

Cross-functional collaboration

Cross-functional teams have to increase their own internal responsiveness to adapt to the rapid rate of change of cloud products. Doing so, however, can impact the stability of the cross-functional team and the product manager must make new efforts to improve knowledge-sharing and decision-making.

“The challenge is to bring rest of the company up to the same speed – this can result in conflict. You also have to be careful the impression isn’t given that product managers keep changing their minds.”

Figure 2. The product manager’s cross-functional collaborations.

To enhance the effectiveness of collaboration within the context of continuous delivery, cross-functional teams might benefit from further training in conflict management and communication. Some teams are already adapting by changing their collaboration processes and tools to reflect the asynchronous and fast-moving nature of communications within the cloud paradigm. Social networking tools are becoming more popular in product teams because they enhance internal discussion and knowledge-sharing, whereas more linear methods reflect the more static nature of collaboration in the on-premises paradigm.

“Since features are being released weekly or daily, you’re having to hurry more to educate the rest of the business when new features are ready.”

Over the longer term, cross-functional teams in the organisation will probably have to apply the agile approach to their own processes so that rapid, iterative change can be managed collaboratively. This approach is likely to work best when teams are willing to collaborate on a social platform like IBM Connections.

Cloud computing

The product manager in the cloud paradigm needs not only to thoroughly understand the product being managed but also the capabilities of cloud computing, including its benefits and drawbacks for customers. The many facets of the cloud are captured in this model by the European Commission in Figure 2.

C:\Work\Product Manager\PM Learning\DIT MSc\4. Dissertation\Images\EU-Cordis model of cloud computing.jpg

Figure 3. A cloud computing model.

The cloud product manager can point out to hesitant customers that switching from an on-premises application to the cloud will benefit them in the form of reduced capital expenditure and IT staff, along with the opportunity to gain competitive advantage. Conversely, the product manager must assure customers of the continued availability of the product and, consequently, business continuity.

“A product manager needs to understand the way to compare and contrast on-premises versus cloud versions.”

Although customers are increasingly attracted to the cloud because of its business benefits, the issue of data security is still one of their paramount concerns. This concern imposes additional responsibilities on the product manager, who must be conversant with national and international regulations around the issues of data accessibility and liability.

“There are new questions that prospects ask around security and the safety of their data.”

For customers in the EU, for example, the requirements for “safe harbor” agreements can be decisive factors in considering the move to a cloud product.

Pricing and revenue models

The cloud paradigm does not necessarily change the role of the product manager with regard to pricing. Nevertheless, product managers have to address new factors in the cloud paradigm, specifically the cost and revenue factors, which are markedly different than in the on-premises paradigm.

“When you move to a cloud model, my perception is that customers expect to know what they’re going to pay because they’re going to start using it immediately – they aren’t going to necessarily go through a procurement process.”

The cloud model typically has more pricing options than its on-premises equivalent, including several types of transaction (pay-per-use) and subscription (rental and licensing) models.

“It’s a minefield when you get into subscription pricing, because of all of the things that you have to consider.”

However, revenue models that are based on transaction pricing can be riskier than subscription models for several reasons: customers can switch more easily to another vendor; metering of transactions adds a new layer of administration, and revenue is collected in stages, making it more difficult to finance development work.

Lifecycle management

The shift to the cloud affects the product manager’s approach to product lifecycle management because the cloud can extend the lifetime of a product beyond that of its on-premises equivalent. Rather than accept that a product has reached its sunset phase and must be discontinued, product managers have new opportunities to reinvigorate their cloud products.

“We classified our on-premise products into invest, harvest, and sunset products but we haven’t done that exercise for the cloud because you can always update the product and make sure that it’s current with customer and market requirements.”

This flexibility is more difficult to achieve in the on-premises paradigm because the technology is installed on the customers’ hardware, rather than on the vendor’s.


The shift to the cloud is having a positive impact on innovation and new product development because of the ease of testing new ideas and garnering feedback. The cloud is thus a major new addition to the innovation process because it allows product managers to perform experiments to help develop products faster.

“Cloud gives us a lot more options about trying different solutions before focusing on one. It allows us to measure our tests. This type of research is absolutely new for us; we weren’t doing this before.”

The cloud model is supportive of design thinking approaches to innovation, particularly the process of prototyping potential product solutions, many of which can be expected to fail. Design thinking has an affinity with the cloud because the two phenomena focus on user experience, feedback, speed, and flexibility.

“Fail early and fail often” is something you want to do with SaaS. We use design thinking as a way to prototype and envision new features or functions outside of the released software, where the expectation that the feature will make it to market disappears.”

Product managers in IBM can now apply the IBM Design Thinking framework, which combines traditional design thinking approaches with three unique practices – design hills, sponsor users, and playbacks – as shown in Figure 4.

Figure 4. IBM Design Thinking.

Even without formally applying design thinking, product managers can take advantage of the low-cost of trialing new software in the cloud, whether through prototyping, A/B testing, or releasing a minimum viable product (MVP). They must, however, be careful to protect the customer relationship by informing users when a prototype or MVP is being tested.

Gathering requirements

The requirements-gathering process for on-premises products is identical in most ways to cloud products (including the use of interviews, focus groups, surveys, and site visits) but the cloud offers additional channels of requirements. Metrics, for example, can highlight patterns of usage of the product, feed directly into requirements, and prompt new innovation.

“You have this opportunity now to get information about the usage of your product that you never had before.”

Additionally, in contrast to gathering requirements at set intervals during the on-premises release cycle, the cloud product manager is constantly in contact with internal and external stakeholders to gather their requirements for future releases.

Product manager role

Many of the activities of the product manager in the cloud are largely identical to those in the longer release cycle of the on-premises paradigm, but there are some key differences. There is still the same need to research the market, listen to customers, understand technology, and work cross-functionally, whilst constantly honing the personal skills required for success.

“It’s not extra activity, it’s the same activity but in smaller pieces and in a much more dynamic way.”

A significant advantage of the cloud paradigm, however, is that a product can be developed and incremented iteratively, as opposed to the on-premises paradigm, where all aspects of the product must be in place before its initial release. But because of the faster pace of the cloud, more urgency is placed on the product manager.

“A lot of assumptions that you can make about on-premise software don’t work for cloud and vice-versa. And in addition, you need to get used to the speed of turnaround with all these processes.”

Moreover, the cloud product manager has to deal with increased uncertainty because the ability to react quickly to customer feedback and market trends requires a constant updating of the product roadmap. That said, product managers must keep the long-term product strategy in focus so that tactical issues do not predominate.

Customer relationship

The importance of the customer relationship is increased for the cloud-based product manager. As a consequence of the additional communication channels provided by the cloud, customer engagement is more immediate and fluid than in the on-premises paradigm. Product managers can more easily engage with customers both to understand and respond to their needs, and to provide online resources such as user communities, self-service tools, and documentation libraries.

“ The communication is continuous now. Every time you talk to the customer, you’re building the relationship.”

Moreover, the cost of switching to rival products is much lower for customers than in the on-premises paradigm, so product managers must constantly manage their customers’ expectations. This means continuously monitoring feedback, analysing usage, inviting participation in testing, and communicating news of updates and other important information.

Recommendations for practice

The product manager role as it is practiced in the on-premises paradigm differs in important ways from its execution in the cloud. The management of cloud products differs markedly from on-premises products in terms of the urgency and flexibility required of the product manager.

Product managers who are moving to the cloud should study the following recommendations for practice:

  • Attain a thorough understanding of how the cloud model works, including its benefits and drawbacks, with special regard to legal requirements for data protection.
  • Lead cross-functional teams in adopting new collaboration tools and processes to adapt to the extra demands of the cloud on communication and decision-making.
  • Introduce IBM Design Thinking practices to improve innovation, engage with users, and test prototypes.
  • To foster customer loyalty and interaction, maintain a consistent focus on managing customer relationships and customer expectations.
  • Master the use of metrics to analyze how customers use the product and to develop product requirements.
  • To prevent the customer disruption that can be caused by continuous delivery, devise and incorporate product capabilities that give customers some control over receiving upgrades to the product.
  • Formulate guiding principles that guard against the tendency to focus on short-term customer requirements at the expense of long-term product strategy.

Figure 5. Benefits of cloud adoption.

In short, traditional product management activities must become more dynamic in the cloud context and the product manager must adapt by becoming more flexible and responsive. To put this in context, IBM’s cloud revenue grew by 60% in 2014 to US$7bn, and one reason for that growth, said Ginni Rometty, was understanding the requirements of our clients. To continue to capture this market, managing customer expectations becomes a more critical concern than ever. Understanding and acting on these recommendations can help product managers shift to the cloud with a greater chance of success.

© Paddy Barrett 2015


Design Thinking – A literature review

This 2013 review for my MSc in Software Product Management examines the Design Thinking literature from the perspective of the software product manager who seeks a better framework or model for developing innovative products, a model that can help to deliver the right products for the right user while enhancing the strategic outcome for the firm.

1. Key arguments and ideas in the literature.

Design Thinking is an approach to product develop­ment where the fundamental premise is that direct collabora­tion between stakeholders in solving complex, ambiguous problems leads to positive user experience outcomes.

Generally, Design Thinking provides a set of conceptual models rather than specific processes. It stresses the importance of empathy in understanding users’ problems, as well as the rapid prototyping of possible solutions, all embedded within an organisational culture that nurtures the Design Thinking approach. Essentially, Design Thinking is about creating great experiences for users. When successfully applied, Design Thinking produces feasible product implementations that unify viable business requirements with desirable user experiences. For the firm, this approach can translate into a new source of competitive advantage.

Whereas traditional problem-solving might have focussed solely on new technology and techniques, the Design Thinking approach begins with an understanding of the user through empathy and observation. This approach requires the product manager and other stakeholders to ask new questions about the problem and, importantly, about the assumptions underlying the problem. These investigations, conducted in an open and creative way, inspire potential solutions that must be validated before an ideal candidate is produced. Most of the authors reviewed here advocate the use of iterative prototyping and testing so that multiple possible solutions are explored.

Although the methods described by the reviewed authors are typically not grounded in the academic theoretical discourse, they have been applied in real business contexts and thus can claim some legitimacy as best practice models for the firm. (Incidentally, the same models can be applied to non-commercial organisations, such as public service bodies.)

2. What are the authors seeking to do in writing these articles?

Not surprisingly, given his role at the IDEO design consultancy, David Kelly offers practical advice about implementing Design Thinking, along with anecdotal evidence of applications of Design Thinking. His formula for applying Design Thinking to business innovation problems can be summarised as “Observe, brainstorm, prototype” (Kelly & Littman, 2001). The book offers detailed advice about setting up a suitable environment, including hiring and training the right team of people, to stimulate and support Design Thinking in the firm. In this book, Kelley seeks to report IDEO’s research as well as express opinion.

The Developing Design Sensibilities paper is a manifesto for the introduction and championing of design sensibilities in the workplace, where these sensibilities include intuitive human qualities such as “delight, beauty, personal meaning and cultural resonance” (Suri & Hendrix, 2010, p. 59). Balancing design sensibilities with design methods creates a framework where complex problems can be resolved with solutions that support the firm’s strategy. The authors seek to contribute to theory and give advice on future policy directions.

Tim Brown, also of IDEO, positions Design Thinking as a discipline for achieving innovation in product development, emphasising its use as a strategic tool for differentiation and competitive advantage (Brown, 2008). He defines Design Thinking as a discipline that can deliver desirable products within the context of a viable strategy and the constraints of technological feasibility. He advocates that the firm integrate the discipline into its innovation processes and, moreover, use Design Thinking to reimagine the organisational structure.

Brown’s book goes into detail about how Design Thinking can be applied to the firm to foster a culture of creativity and thus improve innovation (Brown, 2009). While describing the stages of a Design Thinking project, he emphasises the value of storytelling as an input to human-centred design and, ultimately, as a basis for improving the user experience. Brown seeks to report his own research as well as give advice on future policy directions.

In their book, Liedtka and Ogilvie attempt to provide techniques for managers who want to introduce systematic methods of product innovation into their organisations (Liedtka & Ogilvie, 2011). They describe a detailed framework of tools – including sections about brainstorming, visualisation, and prototyping – that can help managers both to understand the designer mindset and apply the Design Thinking discipline. They suggest applying the tools in response to four overarching questions (“What is?”, “What if?”, “What wows?”, and “What works?”). Their book seeks to express opinions and report their own research.

Roger Martin focuses on marrying the often mutually-exclusive modes of inductive and deductive thinking with the abductive reasoning mode, and using it as a basis for applying Design Thinking to the firm (Martin, 2009). He also explains how to negotiate the tensions between business innovation outcomes, as measured according to standards of either reliability or validity, by adopting Design Thinking principles such as experimentation, heuristics, and creative thinking. His book seeks to contribute to theory, criticise what is currently being done, and express opinion.

The Beckman and Barry paper urges design thinkers to make use of user-based storytelling in their approach to Design Thinking. They suggest including user stories in the design approach and telling inspiring new stories to drive the Design Thinking project (Beckman & Barry, 2009). They propose a framework that combines the abstract and concrete elements of the design process, specifically in that concrete observations are developed into abstract insights and ideas which later form concrete solutions. The authors seek to express opinion and contribute to theory.

3. What are the authors saying that has relevance to my work around Design Thinking?

The Art of Innovation (Kelly & Littman, 2001) contains some useful pointers to ways in which a product manager might organise Design Thinking projects that are focussed on product innovation. The techniques of observation, brainstorming, and prototyping are described in great detail and can be usefully added to the portfolio of the product manager’s tools. The theme of innovation is predominant throughout the text and Kelley provides advice for exploring diverse and often unusual methods. He emphasises the value of stimulating the people involved in the project and gives concrete examples of the tactics to use for exploration.

Suri and Hendrix (2010) explain how designers can bring their sensibilities to the business innovation process and then delve into some specific attributes, such as observation practices, the ability to sense “opportunities for change” (p. 60), and the skills to design the expression of such changes. Designers use their sensibilities to connect to the sensibilities of the users of their products and this symbiotic relationship sums up a core aim of Design Thinking – to focus on users when solving their problems.

Brown posits a simple formula of the stages of Design Thinking: inspiration, ideation, and implementation (Brown, 2008). Specifically, he describes a ”creative, human-centred discovery process [that includes] iterative cycles of prototyping, testing, and refinement” (Brown, 2008, p. 87). These are useful concepts for the product manager because they help identify the methods and models that can be applied to innovation processes that might ultimately deliver practical business goals. Brown emphasises the use of iterative prototyping as a method both for learning about the feasibility of an idea and for indicating the next steps to take in the project.

Liedtka and Ogilvie provide several templates that might, with considerable effort, be applied to the firm, although it might be more useful to compare these templates to the models of other Design Thinking proponents (Liedtka & Ogilvie, 2011). Nevertheless, the book reminds us that a design thinker can be anyone – not necessarily an accredited designer – who approaches complex problems with empathy and an open mind before exploring the possible paths towards a solution. Iteration is a key feature in this model: whereas traditional business managers prefer a linear path to problem-solving, designers approach innovation through iterative experimentation.

Martin’s discussion about ways to transcend the exploitation and exploration approaches to business innovation is helpful because it might uncover patterns in the firm that have become embedded and unnoticed (Martin, 2009). The analysis of how the firm usually makes business decisions based solely on data from historical results, and often losing market share as a consequence, could help to reduce unnecessary dependence on reliability yardsticks. Martin argues that the firm should consider an alternative approach, favouring unpredictable initiatives situated in a Design Thinking context. The discussion about heuristics and algorithms provides further clarity about the nature of innovation. The book also offers techniques for developing personal Design Thinking skills, which can be categorised into three components: Stance, Tools, and Experience. Furthermore, Design Thinking is a useful model for managers seeking to tackle complex problems at an organisational level (Dunne & Martin, 2006).

The storytelling framework proposed by Beckman and Barry reflects the models that are proposed by other Design Thinking authors but is a greatly simplified version. In that respect, the framework might be more useful than the multifaceted techniques found elsewhere because the essence of this framework is observation, insight, and ideas, and it can be readily applied to a Design Thinking project. Above all, the paper advances the use of storytelling as a vital tool in the innovation process. That assertion seems apt in the agile development process, where formal user stories are the driving force behind development.

4. How convincing is what the authors are saying?

Kelley’s book reads, at times, like a eulogy to IDEO with repeated references to the company’s past achievements and its prowess at innovation. Such information is not necessarily relevant to the theory. Nevertheless, Kelley provides interesting descriptions of how IDEO’s projects usually begin with brainstorming and prototyping. Apparently, he neglects some of the processes that precede and organise these activities. In that respect, the book is not especially authoritative as a source of best practices in Design Thinking. Having said that, it might provide useful interview material for an aspiring IDEO intern.

Both Suri and Hendrix are managers at IDEO and draw on their own experiences but also describe detailed corporate examples of Design Thinking, including those of Starbucks, Proctor & Gamble, and Virgin America. There is little discussion of practical, step-by-step techniques that, if applied consistently, could replicate some of the anecdotal examples described in the paper.

Brown brings considerable experience as both a designer and a consultant, and his practical outlining of techniques, along with numerous examples from business, offer substantial evidence of the applicability of his vision of Design Thinking.

Most of the techniques described by Liedtka and Ogilvie are common to much of the Design Thinking literature that is aimed at the firm, but whether they can be realistically applied is an open question. Moreover, the book contains few references to the theoretical underpinnings of Design Thinking and also lacks convincing real-world evidence of the application of its framework.

Martin makes a powerful case for the use of abductive logic in his discussion of the struggle between analytical and intuitive thinking. He elicits examples of applied abductive logic at several businesses, including Cirque du Soleil, Herman-Miller, and Proctor & Gamble, to show how a new mindset, when applied to established products, can lead to revolutionary innovation.

There are several references in Beckman and Barry’s paper to the Design Thinking and sociological literature to support the authors’ claims for the power of storytelling in applying Design Thinking. The paper provides a detailed description of the innovation process that resulted in Kimberly Clark producing the ground-breaking Huggies Pull-Ups product.

5. How can I make use of this analysis?

Design Thinking has the capability to help solve complex problems and thereby increase the likelihood of developing compelling, creative, and disruptive product innovations.

A key tenet of Design Thinking is that everyone in the organisation – or, more often, the project team and especially the product manager – has a role in working with and applying the principles of Design Thinking. This teamwork approach means empowering colleagues with suitable mental models to aid decision-making – as opposed to dictating prescribed processes and activities.

The models and techniques outlined in the literature emphasise the importance of cross-functional collaboration. In order to achieve their innovation business goals, team members must collaborate effectively with internal stakeholders and clients to uncover market needs. In particular, the entire project team must focus on the user experience by both understanding the user’s – often hidden – needs and creating an outcome that enhances the user’s experience. In short, putting the user at the centre of the release.

This shift in thinking – and the concomitant expansion in mindsets from purely technological to sociological or psychological – might require sustained programs to educate project teams, if not the whole organisation.

Aside from the challenge of obtaining organisational buy-in for the Design Thinking model, there are probably new resources needed to gather and analyse user research, which is vital to capturing the data that provides the basis for inspiration and ideation. It might also be necessary to change attitudes to iterative prototyping, and to educate personnel about its importance in quickly validating the ideas that emerge from the ideation stage.

The product manager will continue to drive innovation but will need to engage sooner with designers and developers to induce them into the Design Thinking culture. On a Design Thinking project, all three functions are likely to collaborate more closely than before. Ideally, this new level of collaboration and decision-making leads to better user outcomes in the form of innovative and profitable products.


Beckman, S. L., & Barry, M. (2009). Design and innovation through storytelling. International Journal of Innovation Science, 1(4), 151-160.

Brown, T. (2008). Design thinking. Harvard business review, 86(6), 84.

Brown, T. (2009). Change by design: HarperBusiness.

Dunne, D., & Martin, R. (2006). Design Thinking and How It Will Change Management Education: An Interview and Discussion. Academy of Management Learning & Education, 5(4), 512-523.

Kelly, T., & Littman, J. (2001). The art of innovation: Lessons in creativity from IDEO, America’s leading design firm: New York: Doubleday.

Liedtka, J., & Ogilvie, T. (2011). Designing for growth: A design thinking tool kit for managers: Columbia University Press.

Martin, R. L. (2009). The design of business: why design thinking is the next competitive advantage: Harvard Business School Press.

Suri, J. F., & Hendrix, R. M. (2010). Developing Design Sensibilities. Rotman Magazine, 58-63.