Chapter 8
The Faster We Go The Sooner We Know
Abstract
PrD benefits from urgency, timeboxing, and setting impossible deadlines. The only way to discover how wrong we are (and in what way) is to have our external stakeholders tell us. The sooner we get them talking to us, the sooner we improve. PrD’s reliance on speed makes it advantageous to organizations facing ever-increasing time pressures and rates of change.
Keywords
velocity
ROI
time to insight
fidelity
level of investment
insight overhead
problem space
decision point
… enlightened trial and error beats the planning of flawless intellects. … fail faster to succeed sooner.
—David Kelley
Overview
PrD requires us to get started, immediately. The faster we iterate our ideas, the more we learn and the more our guesses improve. Because the approach uses rapid iterations with external stakeholders, PrD is agile. But it differs from agile because it operates in the problem space, predecision. Similar to agile software development, PrD faces unknown unknowns, the upper left quadrant of the decision matrix discussed in Chapter 3. As we’ve discussed, in these situations the quickest thing to do is to take action.
Our first guesses about our external stakeholders’ needs are wrong. Why polish and refine our errors? Getting more attached to them or investing more into them won’t make them less wrong. Instead, we must fail intelligently, immediately. And then do it again and again, as quickly as possible. By each failure we learn; subsequently we fail less. Over time, we asymptotically approach the perfect solution. The faster we do this, the more money we save.
This chapter is ostensibly about speed, but we increase our velocity to save money:
• The faster we move, the better our time-to-market.
• The sooner we know, the higher our confidence in our next step (abandon the project or proceed).
• The less time spent crafting artifacts, the lower our investment in them.
Just Get Started
It’s Day One. Ideally, we watch stakeholders use stuff on the first day. Calendars, schedules, and real-world constraints prevent such an ideal, but we keep it in mind at all times. The more we delay engaging with stakeholders, the more we delay capturing insights. All team members may not share this sense of urgency. They offer several objections to getting started right away:
• Intellectual property concerns: They don’t want to reveal too much too early.
• Viability concerns: The idea may violate laws of finance.
• Feasibility concerns: The ideas may violate laws of physics.
These are important concerns, but they start with the assumption the idea is remotely correct. Before the team begins financial or technical deep dives, we need to improve our confidence in the idea having a market at all.
Protecting Our Assets
In PrD we do not hold on to our ideas in service of protecting them. We don’t hold on to them at all. We subscribe to the notion “information wants to be free” (as in liberty, not beer).1 Ideas in the early stages of innovation are never half-baked; in fact, these ideas are more like an open container of alcohol: volatile, evaporating, and difficult to contain. It takes far more energy to keep them bottled up than to simply let them loose. It’s far less expensive to reveal our cards, to lay them on the table (Figure 8.1).
Figure 8.1 There’s no profit in hiding your cards
Don’t delay; do it today. The earlier we set ourselves straight about our assumptions, the bigger the impact we’ll have on the outcome.
PrD doesn’t expect a well-crafted design; it doesn’t require us to know all of our assumptions to get started. Time wasted is money squandered. We start engaging with external stakeholders ASAP to rapidly accelerate our understanding of them.
Critics argue we’ll compromise our intellectual property if we discuss ideas too soon. Ideas aren’t protected. Execution on those ideas is. Without getting too wonky, we can agree the expression of an idea into an artifact could cross a line. Since PrD is most effective for disruptive or transformative sustaining innovation, we frequently find ourselves in this territory. We have not had trouble engaging stakeholders in discussions about our assumptions behind an idea. Nor have we had trouble finding ways to express our ideas without revealing the true intellectual property required to execute on them. Nor have we had to name any of our stakeholders as coauthors on any expression of the idea they may have discussed with us.
Critics argue the idea may not be financially viable, or it may not be possible to build today based on our current understanding of physics. They miss the point. The idea stems from our assumptions about the stakeholders’ needs. If we propose a faster-than-light communication technology to illustrate our assumption about our stakeholders’ need to be in the loop, what difference does it make? They’ll tell us about their needs to be in the loop.
We don’t waste time. We get started with what we know as soon as possible.
As The Case of the Hard-Boiled Eggs illustrates, the team struggled with this core principle of PrD. It was hung up on developing and accurately portraying ideas. They approached Leo, seeking a way to move more quickly. “Hard-boiled eggs! Just use hard-boiled eggs!” He threw at them. They stepped back, concerned for his health. Still, one team member took up the charge. The outcome? “It worked!” they said, flabbergasted. “Stakeholders started playing with the eggs and envisioning different solutions, explaining their work and revealing their needs. We learned so much in one day!”
An Early Start Reduces Cost
Addressing user issues up front is 10 times cheaper than fixing user issues during development and up to 100 times cheaper than after deployment.2 These statistics focus solely on the cost of development, not opportunity costs of pursuing a suboptimal solution in the first place. Reducing risk early on benefits the solution in two ways: improving confidence in the decision to proceed (opportunity cost) and reducing the cost of execution.
PrD’s greatest impact is with that first risk reduction benefit: improving our confidence in the proposed direction. Teams using PrD in the earliest stages of the innovation pipeline maximize their understanding of stakeholder needs, contributing to market-based framing of early stage ideas.
The Future Wasn’t Built to Last
Getting started is a conceptual hurdle the team must overcome. The next challenge is building the artifact as quickly as possible. PrD depends on crafting low-fidelity artifacts: physical objects designed to provoke. Several characteristics distinguish PrD artifacts from the more common notion of prototypes:
• Purpose
• Mutability
• Timing
• Level of fidelity
• Level of investment
We cover the first two bullets in later chapters. This section focuses on the others: timing, fidelity, and investment.
Predecision Versus Postdecision Timing
We return to the Double Diamond diagram (Figure 8.2). Before a decision is made, the project is in problem space. Postdecision, the project has entered solution space.
Figure 8.2 Double Diamond diagram illustrating the decision point separating problem and solution spaces
PrD’s greatest impact occurs in the problem space of a project where iteration cycles vet team assumptions. Contrast that effort with iterating in the solution space, in which teams refine the proposed solution. The two regions are separated by the “decision point,” sometimes referred to as the plan. PrD artifacts inform and impact the decision point, which in turn affects everything beyond.
Jared Spool classifies work products (prototypes, sketches, wireframes, journey maps, and so on) based on their timing, predecision or postdecision. An “artifact,” he argues, is a predecision idea proposal; a “deliverable” is a postdecision representation of the “winning” idea. A prototype or wireframe, then, could be either an artifact or a deliverable depending on when and why it was made.3
How Faithful Is Our Artifact?
Generally speaking, teams operating in the problem space don’t have enough resolution of the problem to express their ideas in high fidelity. Conversely, early on in the solution space, teams may still not have enough clarity to craft high-fidelity prototypes. Buxton is clear on the point: When exploring the problem space, sketch (use low fidelity). When iterating in the solution space, prototype (use high fidelity).4
In PrD, fidelity becomes a little tricky: What is the fidelity of a hard-boiled egg, after all? The artifact must be faithful to rendering the team’s assumptions, at whatever level of fidelity that requires.
We’ve mapped both variables (timing and fidelity) over the Double Diamond in Figure 8.3.
Figure 8.3 Timing versus fidelity
PrD focuses on the left-side quadrants. Under what circumstances would a team be in the upper left? Rarely by choice. One bona fide example is the concept car and its research equivalents: high-fidelity artifacts in service of participatory innovation.5 In those atypical instances, verisimilitude is required to achieve the desired provocation.
All other instances we encounter of upper left artifacts (and we encounter them all the time) occur by mistake. Any team (agile or waterfall) speedily building the wrong solution is at risk. Such projects operate under the illusion they are past the decision point, in the upper right quadrant. The day of reckoning occurs when their stakeholders review their work products and question the underlying assumptions. These teams discover, late in the game, their investment in high-fidelity prototypes was wasted. Two cases, The Case of the Rx Reminder and The Case of the Star Trek Holodeck, illustrate this point.
In The Case of the Rx Reminder, fully functioning products were built and used to engage with external stakeholders. None of the three finished products addressed key stakeholders’ needs of simplicity, mobility, and discreetness. In The Case of the Star Trek Holodeck, Steve Portigal and his team were working with a smart TV. “It was like a futuristic smart TV on steroids,” he told us. “To call it a smart TV doesn’t do it justice.” Initially he and his team were commissioned to rank and prioritize features. When consumers couldn’t make sense of the system (because it lacked a coherent narrative), the team pivoted from feature prioritization to questions of why. In short, the client thought their high-fidelity, very expensive prototype was a deliverable; Steve’s research suggested it was still an artifact. (This case also points to that rare bird we mentioned a few paragraphs back, the concept car. Steve suggests at least some of his team’s findings wouldn’t have been possible without such a highly refined prototype.)
How Little Do We Need?
PrD asks us to get artifacts in front of external stakeholders quickly. The key to speed is investment: Reducing our time investment in artifacts improves our velocity. Although low-fidelity artifacts generally take less time to create than high-fidelity artifacts, fidelity isn’t a good measure of investment. As The Case of the New Case illuminates, high-fidelity Photoshop images required far less investment (in time or money) than building foam core mock-ups.
What is the minimum investment (of time, money, or expertise) required to get the most appropriate artifact in front of stakeholders? That’s the business question.
Expanding the earlier matrix to include investment reveals additional insights (Figure 8.4). With the exceptions already noted, the top left of the matrix (high fidelity, high investment) occurs by accident or mistake. The next cell down (high fidelity, low investment) is more common, but problematic. Low investment is appropriate during the problem space investigations, but high fidelity usually isn’t. As we discuss throughout, better conversations result from offering a sketchy artifact versus a highly refined one.
Figure 8.4 Timing versus fidelity versus investment
The bottom left (low fidelity, high investment) of the matrix is an obvious error, committed when teams spend too much time crafting a “beautiful” low-fidelity artifact. We’ve witnessed teams craft “sketchy-looking” drawings using software prototyping tools rather than quickly scribbling a drawing on paper.
PrD sits in the left cell second from the bottom (low fidelity, low investment). When we craft a low-fidelity artifact, with minimal investment, we are poised to quickly engage with stakeholders and investigate the problem space.
Maximize Insight, Minimize Investment
Our intention working in the problem space is to gain insight. The same amount of insight gained at a lower investment of time and money is worth more. It has a lower “insight overhead.” In plain English, the quicker and cheaper we gain the same amount of insight, the less our overhead will be. Formally we express insight overhead as illustrated in Figure 8.5.
Figure 8.5 Insight overhead—overhead decreases with increasing insight or decreasing investment
We minimize insight overhead when we work in the low-fidelity, low-investment cell. Landing in the upper left by accident, as in The Case of the Star Trek Holodeck, makes insight overhead skyrocket.
Discovery Through Agility
PrD’s agile approach to problem exploration also lowers insight overhead by reducing hand-offs from one team to another. Recall from Chapter 2 the compare and contrast example of the cleanroom industrial control interface. In the waterfall-like traditional UCD approach, the research and design teams operate separately from each other and the development teams. Each moves through the design thinking cycle sequentially, handing information off as it crosses boundaries. Eventually the development team receives a requirements document along with technical specifications, wireframes, and other deliverables. The process takes months, sometimes years, before the development team creates a working version of the idea. This investment of time increases insight overhead (Figure 8.6).
Figure 8.6 Research and design effort and insights (waterfall/traditional UCD)
Investment overhead goes up for a second reason: Insights diminish from the start of the process until the end. By the time the research has been written up and communicated to the design team, insights have decreased due to:
• Layers of abstraction between the observation and the report out
• Distance in both intimacy and time from the original observation
• Recasting of the information for each group’s needs
Contrast this with PrD’s agile-like approach to design research (Figure 8.7).
Figure 8.7 Research and design effort and insights (agile/PrD)
Because teams are working together from the start of the engagement, few hand-offs are required. This increases the number and value of insights. Likewise, the time investment plummets. These two factors—increased insight and lowered investment—significantly reduce investment overhead.
PrD shortens discovery activities to a matter of weeks (or months for extraordinary projects). It simultaneously raises the team’s confidence about the desired outcome. It couples research to design, using design as a research vehicle. Because this happens within the problem space, business stakeholders are actively involved, monitoring how customers react to their desired value propositions.
Moving Fast While Staying Real
Recall a key tenet of agile: Maximize business value. Software developers achieve this by getting working code in front of customers as soon as possible. It’s an important point. With a working product the organization has begun earning revenue and enabling its customers. By putting a real thing in front of customers, they can respond to it with feedback for the next cycle. The approach makes a large assumption: External stakeholders have communicated their needs and we have accurately understood them. Recall from Chapter 6 the revised version of the agilists’ Pharaoh story.
Get Real
PrD and agile agree in principle: We need to get real stuff in front of our stakeholders before they can show us how wrong we are. The challenge is to reduce the investment of producing that stuff. And, of course, we need to agree on what we mean by “real stuff.” For designers and researchers, a smoke-and-mirrors artifact is real enough, as long as it provokes the right conversations. For some agilists, working code is the only definition of real. But what would an organization prefer: A quick-and-dirty artifact eliminating a possible solution entirely or working code for a narrow slice of that solution (that might be entirely wrong)?
Working code brings an additional advantage: It proves the solution works. And herein lies the problem: the word “solution.” A truly robust solution comprehends user needs. Agilists leave the crafting of user stories to Product Owners (POs), but POs never work with code. How are the POs supposed to know they have the right stories? Poorly written user stories not generated from a legitimate UCD research method result in lowered quality (from the stakeholder point of view) forcing refactoring down the line. PrD ensures the validity and robustness of the stories, before the tasks and work breakdowns begin. (See sidebar for a wonky deep dive into the challenges of reliably capturing user needs.)
Rapid Iterative Testing and Evaluation (RITE) is an established method of iterative testing (as its name suggests) of a candidate product.7 It has many of the hallmarks of PrD in that it is iterative, expects the product to change rapidly between sessions (perhaps in the same day), and involves direct engagement with external stakeholders. Historically, researchers and usability engineers employ RITE after there is a working product, again, using real code. RITE brings its own challenges to the table: Rapidly changing the code itself, in almost real time, depends on a highly mature development process (or a relatively simple set of problems being iterated).
Both RITE and working code are important ways to move quickly and keep things real. Because both operate in solution space, both fail to identify the big picture concerns of stakeholders (the “elephant” in the pyramid as we discussed in Chapter 6).
Real Is in the Eye of the Stakeholder
Sketching, as Buxton9 describes it, is not only a natural tool for designers but also exactly the thing to move forward with external stakeholders today. A whiteboard and a marker may be all that is needed to get the conversation going, today. Delaying these conversations increases insight overhead and adds risk, especially when critical decisions about infrastructure, platforms, and requirements could use the information. Sketching allows us to race forward with our stakeholders. It helps identify potential risks of infrastructure decisions (including purchasing third-party software or tools). In the happiest of circumstances such sketches influence the decision point before development begins in earnest.
In The Case of the Constricted Collective Conversation (about civic engagement in Englewood, IL) the research team mentioned how academics had spent years studying such communities before advancing possible solutions. These researchers didn’t have the time or the luxury to deeply study the culture they were hired to help. Their approach (placing a chalkboard at a busy intersection and offering journals at well-frequented business establishments) moved quickly: Within a period of a few days, the team captured substantial information and, equally important, helped the community discover novel methods of engagement to improve neighborhood dynamics.
Risk Factors
The Need for Design Thinking
PrD’s velocity depends on the team’s ability to quickly switch between analysis and synthesis, a hallmark of design thinking, discussed at length in Chapter 2. One way to guarantee teams use design thinking is to have designers on the team who are good at design thinking. Imagine that!
Reasoning abductively, a key part of design thinking, is required throughout PrD. During initial artifact creation, designers quickly sketch ideas they’re hearing from other team members. During the fielding of the artifacts, the Facilitator quickly offers alternative expressions of the artifact. At a minimum, she is able to mirror back alternative interpretations of the artifacts based on stakeholder reactions.
A lack of design thinking on the team impacts PrD’s velocity.
Analysis Paralysis
This risk appears at any time: In the beginning when the team is uncertain how to start, in the middle when stakeholder feedback appears confusing, and even at the end when the iterations have stopped and the results need to be comprehended and communicated.
Apparently it’s a part of our nature: We want to reduce risk to our reputation. We want to be certain of our assertions and we want to ensure the organization is on the right course. All of these issues reduce velocity and for some of us, some of the time, freeze us in our tracks. We’ll discuss techniques for overcoming analysis paralysis in later chapters, but a key method is establishing and maintaining a sense of urgency. Timeboxing the team’s effort, for example, is one of the ways to reduce overthinking at any stage of the process.
Equally important is to ensure everyone (sponsors, team members, and internal stakeholders) understands PrD is a qualitative research method relying on small numbers. Of course, if the project is betting millions on the outcome, quantitative measures will be needed. But if the team is simply trying to set its sights in the right direction, the niggling details are likely less important than the big directional indicators. To quote Keynes: It’s better to be roughly right than precisely wrong. Moving fast and identifying likely risks early is far more important than getting a narrow implementation exactly wrong.
It’s the big ideas that matter up front, not the small details. Moving fast is more important than being pedantic. Part of the value of PrD is getting internal stakeholders aligned. It requires individuals to air their operating assumptions up front and it obligates them to witness the testing of those assumptions. Alignment sidesteps the quagmire and cost of design by committee. Nothing releases team members’ attachment to a bad idea faster than witnessing, first hand, external stakeholders trashing it. Rapidly assessing an idea, over multiple iterations, improves team members’ understanding of its validity far more quickly than offering them a written report or presentation deck.
Summary
• Time to insight is crucial. This means the more we learn about our external stakeholders as quickly as possible, the better. We achieve the greatest velocity by capturing their needs, goals, and work while simultaneously having them vet our assumptions.
• Multidisciplinary teams working together from the start reduces insight overhead by increasing insights and dropping time investments.
• Build the least-cost (time, effort) artifact to capture the most information. Working code can’t offer insights into the big picture; PrD identifies the right thing to build.
• The faster and cheaper we iterate through this process, the more we increase the ROI of “being wrong,” speeding time to insight. PrD’s results are not improved by having more time.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.