Chapter 9
The Perils of PrD
Abstract
PrD is an amazing risk reduction strategy, but it doesn’t apply in every situation. Successful PrD requires the right mix of talent: The internal team must be open to the process, and the process requires an effective facilitator. Further, the approach takes courage—airing our assumptions to external stakeholders with nothing more than cardboard, foam core, and glue is not for the faint of heart. Although PrD isn’t limited in how it can be applied, or to what type of project, it is most effective when the situation requires taking action first.
Keywords
limitations
magic
artifact
talent
collocated
courage
A ship in harbor is safe, but that is not what ships are built for.
—John A. Shedd
Overview
In a recent PrD workshop, one of the attendees asked, “What sorts of projects won’t work well with this method?” Leo had to pause to consider. PrD isn’t limited to a specific sort of project, industry, or engagement; rather, it makes the most sense when applied to particular types of problems. When businesses face existential threats, in part due to their current processes and strategies, they can’t rely on those strategies to move forward. Disruptive innovation (or “possibility thinking”), by definition, conflicts with day-to-day operations. In these cases, PrD offers a cost-effective method of moving forward. Outside such contexts, PrD may not return the results sponsors and stakeholders expect.
In addition to the strategic questions of whether to use PrD, the process can fail for numerous tactical and operational reasons. In each of the preceding chapters (dedicated to PrD Principles) we offer risks associated with the principle in question. The remaining chapters in this part describe additional ways in which the process can fail: team composition, failure to believe we’re wrong, poor objectives, poorly executed objectives, and poor facilitation. In this chapter we focus on when PrD shouldn’t be considered at all.
Is It the Right Problem?
PrD is not limited in its application. Instead, it is limited by the nature of the problem: PrD is unnecessary for “simple” and “complicated” problems. Recall from Chapter 3 simple problems can be solved by applying standard processes, and complicated problems are solved by experts applying tacit knowledge. In both of these contexts, the problem can be resolved through mechanistic or analytic approaches. In “complex” or “chaotic” problems, however, no amount of analysis or process will identify the right way to proceed. In these situations action must come first, and through taking action, produce results on which the team reflects. PrD is best applied when the problem requires taking action first.
Software development is one such situation. The best outcome for a new feature or product cannot be predicted ahead of time. It is unknowable without a series of experiments. Substitute “design” or “strategy” for “software development” and the statement still holds true. The nature of design problems is we can’t predict their solutions without a series of guesses.
Design thinking comes in handy for almost any sort of problem, be it simple, complicated, complex, or chaotic. PrD however, though it depends on design thinking, will be too “heavy” for situations in which we already know “enough.”
PrD Needs Two Things
PrD requires two components to succeed: an artifact and a focus on the external stakeholders’ problems. With those two ingredients, PrD applies to a whole host of problems. As we discuss throughout, the artifact can be almost anything—as long as it provokes conversation in service of the internal team’s objectives. The second ingredient, sincere interest in the external stakeholders’ problem space, rarely limits the sorts of things PrD can be used to discover.
Without these two components, either PrD won’t work or it isn’t PrD.
A Provocative Artifact
As part of a PrD workshop focused on next-generation drawing systems, a team crafted a “dreamcatcher,” a device that could record an individual’s dreams and redisplay them on request. The artifact was envisioned to be worn over the ear, similar to a wireless headset. But after the team’s Engagement Sessions, it realized it didn’t have to build such a sophisticated artifact at all. The team could just as easily have put a small dot above the stakeholder’s ear to achieve its objectives (Figure 9.1). In The Case of the Balking Bicyclists, David MacKenzie quickly realized the key conversations didn’t require him to build anything fancy—a cardboard box would have sufficed. The point is the artifact need not “mock up” an envisioned design at all: All it need do is represent the internal team’s assumptions enough to provoke a conversation about them with the external stakeholders.
Figure 9.1 An over-the-ear dream catcher could just as easily have been a paper dot
Suzanne Howard, Partner and Managing Director of IDEO’s Learning Platform, suggests the artifact should push boundaries of the known—to be “from the future.”
Sacrificial concepts—In order to solve the challenges at hand, design thinking involves early prototypes or tangible, conceptual versions of what the future might be in order to help engage participants in imagining new realities.1
Magical Artifacts
As Arthur C. Clarke said, “Any sufficiently advanced technology is indistinguishable from magic.”2 If the artifact isn’t sufficiently futuristic to be magical, PrD will not produce good results. Consider a drinking glass from the future. Perhaps it has embedded sensors, is networked with other glasses in the area, and both feeds and is fed from big data sources. This isn’t such a far-fetched idea. All sorts of magical things could go on with that glass: biometrics, assessment of water quality, social networking, and so on. A magical artifact must express those qualities in service of testing the team’s assumptions.
Whether to use PrD or not depends on the magic of the artifact. At first glance it would appear PrD is suitable only for product-type engagements (and by product we mean anything from hardware to software to web designs to services). Requiring a magical artifact would appear to eliminate such things as new org chart, a strategy statement, or a new logo. In reality, PrD can test abstract ideas just as well, if they can be crafted as an artifact that can be used. As Steve Sato relates in The Case of the PowerPoint Play, his team did exactly that: They crafted provocative slides to test how far their VP could be expected to advocate for design.
An Artifact to Use
In PrD, the artifact must be magical, and stakeholders must use it to complete a relevant task. PrD relies on the stakeholder’s multimodal thinking—not just thinking aloud but also manipulating the artifact while thinking aloud. If the team can’t devise a task where the stakeholders work with the artifact, then PrD is not going to deliver useful results.
Additional Ways PrD Can Fail
Talent
Perhaps the most important consideration in choosing to use PrD is whether the team has the talent to do it. In spite of it being conceptually easy to describe, it is an advanced technique. This book allots considerable space to facilitating in PrD because it is the most difficult part of the process to master (see Chapters 14–16). PrD requires very real and legitimate facilitation expertise. In addition, teams will need creative experts in design, user experience, and user interviewing. When Leo was building a UX team for a large enterprise project, he discovered even folks with years of experience in UX design and research were unfamiliar with the kind of facilitation PrD requires. Only after training and participating in several Creation and Engagement Sessions did the team begin to understand the subtleties of the process. See Chapters 14–16 for more details on facilitation. See Chapter 10 for details on roles, reasoning skills, and personality types that contribute to PrD’s success.
The bottom line: PrD won’t work, and we advise against using it, without access to an experienced interviewer or facilitator. Not only will the results be disappointing, but the team also may not even know the process has failed until it’s too late. Again, see the following chapters for details on who may be experienced enough to make the process a success.
Courage
PrD is not for the faint of heart. It requires team members to keep two opposing and equally passionate beliefs in their minds: The artifact they’ve created is truly what external stakeholders want and need and that something (if not everything) about this presumption is wrong.
This takes extraordinary courage, but it is the courage that drives team adrenaline and subsequently the focus and clarity of purpose.
Every time we’ve used the process in the past 15 years, we’ve doubted whether it would work. Every time. And every time the process has worked. But it’s nerve wracking.
So, for teams trying this for the first time, they must have the courage of their convictions: courage to convince internal stakeholders and sponsors this foolishness will work and it is worth getting in front of real customers. And, most important: The team must have the courage to learn from and reflect on its failures.
Must Be Present to Win
Another important limitation of PrD is the need to engage in real time and real space. As we describe in detail in Chapter 15, internal stakeholders come together to craft the artifact in the Creation Session. With a few exceptions, achieving the objectives of the Creation Session without collocating the team members is almost impossible. One notable exception is an abstract idea (as we discussed in the Section “A Provocative Artifact”). In The Case of the PowerPoint Play, Steve Sato worked with associates around the globe, both asynchronously and remotely. He could do that because the artifact was virtual, and it was intended to be used in a virtual context by his stakeholders. Few artifacts meet those requirements, including software screens, web pages, and the like. While they certainly are abstract, they are generally used by an individual interacting with a screen. To test the assumptions behind them requires an artifact that is used in the “here and now.”
Building the Artifact
If in PrD the artifact is real-world, how do people remotely contribute to it? We’ve heard of a Creation Session in which a remote team member directed local team members to craft an artifact, but it was cumbersome and slow. Equally important is aligning team members on their assumptions. While we can imagine using remote collaboration technologies to debate assumptions, alignment occurs when team members fully engage with each other and the artifact. In sum, being present is a must for creating the artifact.
In Chapter 16 we introduce the second half of PrD: the Engagement Session. Similar to the Creation Session, it is possible to run the Engagement Session remotely, but it may be more trouble than it’s worth. We’ve heard two rationales for doing the Engagement Sessions remotely: convenience and cost.
Convenience
It’s true—meeting with an individual at their desk using a phone and screen capture software may be just fine for artifacts easily represented in a digital format (presentation software, prototyping applications, HTML mockups, and the like), especially if that’s where the stakeholder is likely to do his work. The additional burden to set up a screen sharing application, video camera, and other minimal infrastructure may take less effort than meeting the stakeholder face to face. The convenience may warrant the additional risk introduced by the intermediating technologies. If Engagement Sessions are less than 30 minutes, a quick remote collaboration call may be perfectly sufficient to achieve team goals and reduce the bother of a face-to-face meeting.
But these sorts of artifacts are frequently too refined to provoke the conversations for which we use PrD. Also, most web prototyping tools require more work to make the results appear as rough as a quick sketch on a sheet of paper.
Cost
In general, though, the rationale most organizations use to avoid face-to-face meetings is cost. We take a sensible approach to most of our design budgeting, whether during the research or execution phases: Spend between five and 10% on the total estimated cost of the project. If a project is expected to cost $10K to complete, clearly flying a team all over the country isn’t going to make sense. But if the cost is estimated to be $5M, cutting corners using digital approaches to save a few dollars merely increases the overall risk of the project.
PrD is an extraordinarily powerful risk reduction technique. Saving costs up front doesn’t necessarily translate into overall project savings—if the PrD team discovers a completely different way of proceeding as a result of something they witnessed at multiple customer sites, the project may be cancelled early or may have an improved ROI. Either way, the cost of the Engagement Session is a pittance compared with that of fielding a failed product months later.
In Chapter 16, we provide additional details about the challenges of remote facilitation. In brief, remote facilitation requires even greater expertise in facilitation and increased investment in collaborative technology.
Consider the options if the artifact is real-world and the team is remote. Teams need to figure out how to have the participant work with the artifact in their location. Do they mail it to them? Is there a remote facilitator? If the artifact is digital, it’s a little easier. Videoconferencing tools such as Lync, WebEx, and even Skype and Hangouts can share screens, allowing the team to observe and facilitate the session much like a remote usability test. But as with remote usability tests, much information is lost: body language, nonverbal facial cues, distractions, hesitations, and even potential for attention slicing (e.g., remote participants may choose to answer a high-priority e-mail, unobserved). And, as discussed throughout, crafting a digital artifact often requires far more investment than the typical junk artifacts we rely on for PrD.
In sum, a major consideration in using PrD is the very real need for very real-world engagement on the teams’ part—both in creating the artifact and in engaging stakeholders with it.
Summary
• PrD is more successful in problem spaces requiring taking action first. In these types of problems, the right solution cannot be intuited or reached through analysis alone: They require experimentation and reflection to determine the next best way to proceed.
• PrD is not limited by the type of product, service, industry, or application. As long as the team crafts an artifact stakeholders can use, PrD will work.
• PrD will not succeed without masterful facilitation and courage!
• PrD works most effectively when teams are collocated, whether during the Creation Session or Engagement Sessions.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.