How Ideas Develop

Providing structure starts with understanding how ideas develop. I offer an adaptation of the “double diamond” approach, created by the Design Council in the UK, which structures efforts around divergent thinking, where the team loosens constraints and generates many options, and convergent thinking, where the team specifies criteria to select ideas and try them out. The process of being expansive and critical repeats as you learn more and bring new information back to the challenge to inform another round of work. The “double diamond” refers to the fact that teams can use this approach in a first pass for determining objectives, and in a second for developing solutions. Since I find that both of those activities often take more than one cycle, I’ve depicted it as a single diamond that can be applied to either understanding a problem or developing solutions (see Figure 5-1). The diagram shows the cycle and the key inflection points that you should be aware of to lead people through it effectively. It has four basic stages:

Set objectives

Where the problem to be solved is stated, and success criteria are set

Explore

Where diverse solutions to ideas are generated

Decide

Where solutions are evaluated critically and one is selected to be tested

Test and learn

Where solutions are tested and data is gathered to evaluate and learn how to improve

Figure 5-1. How ideas develop

The diamond shape alludes to the creative process mentioned earlier, where you are channeling energies to be either divergent (many options are explored) or convergent (criteria are used to select options to try out). What’s key is structuring activities to understand what you’re trying to solve for, giving the team time to explore, being disciplined about choosing what to pursue, and trying it out. This structure helps teams focus on the problem and solution, and know when to be critical and when to be expansive in their thinking.

Often, without active coaching or facilitation, teams will attempt to skip to the end of this process by developing the obvious solution rather than trying different approaches. Because the value of collaboration is to bring many different perspectives to bear on a problem, and not assume we know the answer to complex questions, you should help your teams avoid this tendency by planning out time and being intentional about when you are diverging and converging together.

I’ve seen many teams be especially challenged during the exploration stage where they have spent time understanding a problem and begun developing solutions, but haven’t landed on anything tangible yet. Providing stakeholders with progress updates here is tricky because there isn’t a satisfying conclusion to report, and confidence about how the work is going is low. Being transparent in your plan about how your teams are using time will help to manage stakeholders’ expectations and push back against pressure to “just deliver something.”

Plan to Experiment and Reduce Risks

Because collaboration can help with situations where there’s a lot of unknowns, it can be useful to plan for time to investigate and “de-risk” situations, not just create solutions. It’s worth asking, how much risk is there in finding the solution, or how possible is it that you’ll develop ideas that fail? And, if you do fail, how bad are the consequences for the users and the company?

One way to think about the output of your collaboration is to frame it as being either an experiment, where you try a variety of ideas in a safe space to learn how they might perform and ferret out any unknowns without exposing yourself to negative outcomes, or a launch, where you release things into the real world to learn more specifically how they perform (see Figure 5-2).

Figure 5-2. Sometimes you want to test ideas in a controlled experiment versus a launch

For example, when I was part of a team designing a robotic surgical system, we would run experiments weekly or daily, by creating a simulation of the doctor’s controls and display to understand how well different approaches worked without involving the actual robot, which took a lot of time and money to prepare. Our experiments were about building confidence around a specific idea, or learning what made another idea fail. The environment we ran them in was highly controlled, with low risk of catastrophe if we were wrong. We didn’t always try to make the environment realistic, either. In one case we had doctors race each other on the system as a way of seeing many different challenges quickly, even though in reality, speed is never the key factor. Other times, with versions we felt strongly about, we would conduct trials on cadavers, or even animals, to validate certain choices. The decision to operate on a cadaver or animal was sufficiently serious that the team would choose this option only when we had a high level of confidence in what we were learning.

A launch, on the other hand, is when you actually put your solution out into the world, with factors you can’t control and effects that are real. Whether you’re sending shoppers to a new checkout process or collecting important data in a new way, there’s a possibility that if (really, when) things go wrong, the effects aren’t confined to the lab. But just because a launch goes out into the world and escapes the controls doesn’t mean you have no way to manage the risks and downsides of failures. The simplest option is to limit the scope of those using it to a small group. This can help unearth problems in the details that are likely easy to address once you know what they are. Another mitigation is to keep redundant processes in place while you try out a new one. For example, at PG&E when we released apps for the workforce to use to inspect equipment, we kept the old paper processes in place for a few months so we could compare the two sets of data we collected to make sure we were getting the same, correct data with the new tools.

By understanding how complicated your problem space and solution space is, you can figure out how broadly you should cast your net when developing ideas. You can visualize this as the intersection of risk (i.e., the chance that you’ll choose a bad solution) and consequences (i.e., the material damage done by mistakes or inaction), as shown in Figure 5-3.

Figure 5-3. Mapping out complications versus risk in your effort helps you plan

Figure 5-4 shows how teams can manage risks and consequences by structuring their time in the form of experiments and launches to try things out and understand how well proposed solutions work.

Figure 5-4. Connecting risk and consequences to experiments and launches

When you are dealing with ideas in the lower left, quadrant 1, there’s very little chance that you will choose a poor solution, and if you do, the consequences are low, so you may not have to spend very long looking for a breakthrough idea. Likely there are well-known patterns you can learn from and test out. For example, driving traffic to a new feature may take a few A/B tests to work out specific wording or color choices, but it won’t cause catastrophe if you haven’t yet optimized it.

On the other hand, if you face a high risk of not finding a good solution and the consequences are dire, as they are in the upper right (quadrant 3), you’ll need to do enough exploration to drive down that risk and uncover some insights to learn what makes better or worse solutions. For example, creating a new heads-up display for use in mining operations has safety and cost concerns that mean you’ll need to take time to test out what works and/or learn how to reduce the negative consequences of mistakes with safety implications.

Most collaborations are likely to find themselves in the other two quadrants. Something that has high risk, in that no comparable solutions have been identified, but won’t have a ruinous effect if it fails (quadrant 4) can be explored quickly by the team, because you can move to testing with the audience to get “real-world” data about what’s working. For example, developing early capabilities that can augment a product offering might be worth the team spending a few cycles “dogfooding,” or working out kinks, before launching to customers in a trial.

If you’re looking at a problem with serious consequences, but where the path to a solution isn’t risky (quadrant 2), you’ll want to try out ideas in a safe space for a bit longer. For example, rolling out changes to an ecommerce pipeline might affect sales numbers, and rolling out a sweeping policy for a part of HR operations might affect retention and morale. Both of the areas are well understood, so the risk of making a mistake is low, but if you do there will be major consequences.

So, when thinking about how broadly you want the team to look for solutions, consider how well understood the problem space is versus the consequences of failure. Working in an incremental fashion—that is, testing out ideas as you go—helps you avoid implementing a terrible solution, and acknowledges that any solution over time will be refined and optimized for a better return. By balancing efforts to think expansively and efforts to drive down risk, you can develop a plan that will help align your stakeholders in terms of how long the effort will take, and why. This is also useful information to periodically revisit with outside stakeholders to show incremental progress when you don’t have a big reveal.

Keep in mind that these models are intended to be used transparently, with the group evaluating and deciding the details of the plan together. Resist the temptation of keeping these models to yourself to create a plan and then asking the team to sign on. The team’s trust and buy-in will be strengthened when you all develop plans together. And when those plans change—as they will—it’s easier for the group to adjust when everyone’s got the same background. The sidebar “Planning Your Effort and Understanding Complexity” shows more specifically how you can lead a group to think through the approach together.

Example Plans to Manage Risks and Consequences

You can use the framework in Figure 5-5 to determine how many rounds you’ll need to diverge and converge with stakeholders to minimize risk, weed out uncertainty, and create trust. Depending on how complex your problem space is, you can set aside the time needed and communicate that to stakeholders as a matter of mitigating exposure to negative consequences, rather than meeting arbitrary deadlines.

Figure 5-5. Plan to de-risk and manage negative outcomes in your project by moving it from situations with higher risks and consequences to those with fewer risks and consequences

Being in the upper left or lower right means that you should budget two to three cycles to reduce risk or uncertainty and set expectations that the answer is unlikely to happen right away. Once you’ve worked through a few approaches, you can take a cycle to create something that you can test more thoroughly.

Now let’s look at a few example collaboration plans for different scenarios.

Low Risk, Low Consequences

Because this is a well-understood problem with little downside, you can do quick passes to develop ideas to then test with as real an audience as you can get (Figure 5-6). If you are in a position to run A/B tests, your collaboration simply becomes a bit of structure around an iterative development process; maybe you’re working in a “sprint ahead” mode where the exploration and testing is done ahead of when it is to be implemented.

Figure 5-6. An example for low-risk, low-consequence efforts

This might also apply to more organizational challenges like trying flexible seating arrangements or improving internal communications about an HR processes.

Low Risk, High Consequences

When you are in the top-left quadrant, dealing with something that’s pretty well understood but with big potential downsides, you’ll want to slow down the process to make sure you’re getting really sound information about the effects, intended and unintended, of your solution (Figure 5-7). In this case, you’ll want to make sure you’ve defined the context and objectives fully, giving the team time to understand and clearly articulate them. Then, you can explore and develop a few tests that you run for long enough to get a good trend from the data. This could apply to rolling out a new travel and expense policy, where you want to make sure you’ve worked out kinks before asking the whole company to use it. The goal of this type of effort is to drive down the negative consequences by optimizing what works with some protection.

Figure 5-7. An example for low-risk, high-consequence efforts

An example of a situation that’s relatively low risk but high consequence is changing a checkout flow for a highly trafficked ecommerce site, where the factors involved are well understood and there are other case studies to consult, but if a mistake happens it could have a big impact on revenues.

High Risk, Low Consequences

In this quadrant are efforts that don’t have a big downside to them but do have a lot of uncertainty about what will create the desired results. When you have a great idea but no sense of what it will take to pull it off, or if you want to innovate new ideas, it’s good to set aside a few cycles within the team’s whitespace to work through both wild and mundane ideas and shore up the team’s understanding of where the constraints really are (Figure 5-8). From there, testing the best ideas to get external input is useful. The goal of this engagement is to drive down the risk while keeping the consequences low.

Figure 5-8. An example for high-risk, low-consequence efforts

An example of such a situation might be developing a radical new offering for an audience where the team doesn’t have many points of reference to learn from, but their efforts won’t threaten existing revenues or customer loyalty. Launching new features that augment a product or service but don’t take away its current capabilities is worth experimenting with, since you won’t have to worry about killing your core offering.

High Risk, High Consequences

In this situation, your focus should be to either/both drive down the risk and uncertainty about what will work, or to drive down the consequences of a misstep. It is helpful to spend a sprint thoroughly defining the problem and sharing what everyone knows about the territory, but then it’s better to actually move into the territory and start exploring. You can then run single-sprint-long cycles that let you test ideas quickly (Figure 5-9). At any point you can stop and assess what you’ve learned. This type of work should be done outside the cadence of a shipping development team or operational team. This team needs to be able to share their findings with senior leaders and communicate clearly about how they are progressing in the face of a lot of risk and no tangible benefits.

Figure 5-9. An example plan for high-risk, high-consequence efforts

Making changes to the tax code is an example of where there isn’t a straight path to follow toward desired outcomes, and if something goes wrong it affects a lot of people.

Timeboxing Over Deadlines

One way to deal with the pressure to get to the answer quickly and short-circuit the process is timeboxing, or defining a set amount of time for an activity versus a specific outcome. This helps keep the momentum of the team going, and get them trying out ideas to gain feedback and data about what works to show progress instead of jumping to the end.

Years ago, a group of artist friends introduced me to figure drawing. They had set up a tableau and a model, and I was interested, but anxious. After all, I’m no artist! But as we got started, one of them described how this was going to work. We’d start out with three or four sketches of 10 seconds each. From there we’d move on to 30-second drawings and minute-long drawings until finally, at the end, we’d have a full 10 minutes to draw the model. I was instantly curious. Ten seconds?! That was barely enough time to pick up my pencil and make a line or two! So that’s what I did. The 10 seconds was the constraint I’d been given, so there was only so much detail and “quality” my drawing could have.

The same thing happens with teamwork. It can be tempting to hang back from making decisions, especially if the group isn’t in deep agreement, burning valuable time trying to satisfy a need for information or perfection that just isn’t possible. Vanessa Cho of Google Ventures is a big fan of “time chunking,” and she says it’s often saved her in situations where the time pressure feels overwhelming. By setting up shorter, more limited sections of time, you can often satisfy the need to keep things moving and show progress, without trying to solve for every unknown you face.

“You can’t just go on forever,” Cho says. “But I also want everyone involved to know that while we are moving forward, we aren’t done.” She points out that to be successful, timeboxing must be very explicit and made transparent to everyone. You may want to just timebox a stage in the process, or run the entire cycle as a single sprint, working fast and loose to see what gets unstuck. What’s key is that you don’t skip stages or squish them too far. And, when you reach the end of your timebox, you can always add “extra time” if you aren’t quite finished.

How Many Cycles Do I Need?

The question that most teams and their stakeholders ask themselves early and often is “How long is this going to take?” The answer to this question is, of course, the annoying “it depends,” but there are some ways to look at your problem to give yourself some guidelines. Obviously problems and environments will differ, so you should apply your own judgment to arrive at a final plan, but these exercises will give you some lenses to consider instead of making arbitrary guesses or engaging in wishful thinking.

The first assumption is that you are working in sprints, or defined cycles of effort that repeat. Even if you aren’t following Agile practices, it’s useful to frame your work in cycles so that you can communicate increments of progress outside the team while maintaining some whitespace for the core team to work in that feels safe.

You can choose whether your sprints are one or two weeks long, but for my purposes in this chapter I’ll assume you’re working in one-week sprints. The shortest time to set aside for a collaboration is one sprint. This is not to say you can’t do quick workshops in a day, or even do a whole cycle in a few days, but if you are working on a specific challenge with rigor, it’s sensible to give yourself a full sprint cycle at a minimum.

The flipside to this maxim is, don’t plan a collaboration that is longer than 12 sprints. That is, even if you need longer than three months to actually develop a solution, or are working in a context that requires much longer timeframes, it’s generally good to push the team to make one pass through the entire cycle in three months. This means you’re socializing ideas and testing them with some frequency to avoid team insularity from taking you too far off course without feedback. I’ve worked on complicated hardware products where it tooks 16+ weeks and a quarter-million dollars to prototype the full system, but we would still look to prototype and test pieces or low-fidelity solutions more quickly to mitigate risk and learn about our guesses.

So the basic range you should plan in is 1–12 one-week sprints. But that’s a lot of variation. How can you narrow this down? The sidebar “How Long Do I Need?” shows you specifically how to lead a team through estimating how long the entire effort might take, and what assumptions underlie that estimate. Again, it’s worth reminding yourself and the team that this isn’t about promising a deliverable, but about giving stakeholders some expectations about the complexity and approach the team thinks is best.

Share Plans to Set Expectations

Once you’ve created a plan, be sure to make it visible not just to the team, but to outsiders as well. Consider plans as you would work output, something that falls under the RACI roles you’ve hopefully established. Plans should be socialized widely—again, not as a promise, but as a guess about how the work will unfold. This helps everyone have a sense of what to expect, and where the group is headed. For those who aren’t dedicated full-time to the effort, it’s especially useful to remind them where the team has been and where it’s going.

Keeping track of your progress as you go doesn’t just help you set expectations with stakeholders, it keeps the team focused. It can be easy to forget things you’ve learned, or take assumptions for granted if they aren’t made explicit and visible. The sidebar “Keeping Track of Progress” offers tools for tracking and communicating your efforts.

Conclusion

Structure is needed to keep teams from devolving or losing focus, especially when facing complex challenges. By understanding how ideas develop and setting up cycles of effort that are timeboxed and iterative, you can help teams de-risk situations and learn to reduce or avoid negative consequences that come from their solutions. The structure you create isn’t meant to govern exactly what teams do or function as a monolithic order, but rather to help the core team and their stakeholders be explicit about where they are in their efforts and manage expectations. Plans should be made visible and revisited periodically to see what’s changed and whether the effort needs a different approach.

Key Takeaways

• Collaborations can’t succeed if they are free-for-all discussions without structure. People’s personalities will lead to some dominating the work, or to teams getting lost between defining problems, solving them, and learning how well their solutions work.

• Creating a plan to help teams move through the cycle of exploration and learning helps mitigate risk.

• Plans don’t have to be monolithic Gantt charts, but can be structured timeboxes that repeat as the team learns more and progresses.

• It’s better to “guesstimate” how long the team needs and share those guesses to set expectations both within the team and with interested stakeholders.