Breaking the Double Diamond with iterative discovery

Project handoff is painful. We assume handoff is an inevitable part of product builds. It is NOT, but it is ubiquitous and we see very few examples otherwise. Most of us on product teams hate handoff. It is the hardest part of managing projects, brings unacceptable risk, and a blame game often follows.

Handoff is another word for silos. Silos suggest that each team operates as its own universe, and once work is handed over their job is done. But good products take continuous teamwork, and denying that reality just makes everyone’s job more difficult. The solution is a shared output. Just as distinct outputs enable silos, a shared output dismantles them.

Why we need to rethink the Double Diamond

Traditional projects frontload the discovery and design phases, resulting in non-code artifacts such as research findings written up in long form, or flat mockups that will need to be entirely redone in code. These outputs don’t contribute directly to the end goal, and can sometimes even get in the way.

This is because goals often change once a working product gets into the hands of users. In these cases the high quality and challenging work that a team has put in earlier to guess at the truth and create polished outputs can turn out to be time wasted. Whole product philosophies are built around avoiding that risk (XP, Agile). But the Double Diamond reinforces premature optimization and handoff (you could say it Doubles Down on it! haha!).

The current team handoff process

When guiding artifacts reach engineering, the product workflow usually shifts gears to iterative cycles. Engineering teams use iteration to frequently assess direction and progress, which helps them identify and manage the risk of wasted development cycles. But for the most part risk reduction practices like agile have left out discovery and design. We often see this pattern:

Engineering sprints do not typically include iterating with research or design, so it only does a good job managing engineering risk. How do we move out of this dichotomy and end handoff? We include all teams in the iteration process and reduce risk for the product overall.

A new process

The most effective method I’ve found is implementing a shared output: a functional prototype in a shared language (generally HTML, because…browsers). With a functional prototype at the heart of the project, all teams contribute to the actual product itself, in iterative stages as co-creators.

We can break the Double Diamond at the problem-solution stage and expand with an iterative build process instead, like this:

In this process, Discovery stages happen repeatedly rather than just at the initial problem space stage. ResearchOps can make repeated Discovery phases a high-quality reality and be a critical enabler of team-wide iteration patterns.

Definition stages are when decisions are made as to what to work on next, and this process benefits from the combined knowledge of research, design, dev, and more.

During Build stages, both design and functionality emerge side by side and have the opportunity to inform one another. In this way, engineers avoid building functionality ahead of validated research findings and future design changes.

Though the unexpected is inevitable, iterating in smaller increments enables high team involvement and greatly reduces risk.

Use ResearchOps to reduce risk throughout the project build cycle

Catching problems upstream means massive savings and risk reduction all the way down the line. One of the most upstream processes of all is research. But research teams suffer from handoffs too. All too often, research is underutilized (or forgotten about) because it is not in front of the right people at the right time when it can be implemented. As Jake Burghardt says, we should “more closely connect research flows into the structural work of product organizations.”

According to research by Charrette[1], developers spend 40 to 50 percent of their time on “avoidable rework,” rather than “work that’s done right the first time.” And once the product is deemed complete, the cost of fixing an error can be 100 times higher than in earlier stages. Further research by Boehm in his oft-cited work “Software Risk Management” [3] that some of the highest risks in software development are building the wrong features, having the wrong interface, and changing requirements. He lists a litany of research outputs as the best risk mitigation technique, alongside incremental development.

In “Software Engineering at Google: Lessons learned over time,”[4] the authors posit that “software engineering can be thought of as ‘programming integrated over time.’” That is, do not simply sit down and build your best guess at the right solution. Build a first version, learn from it, then build the next version, do more learning, and so on. Incremental releases and continuous user testing are some of the most powerful methods of avoiding rework. But these tools are largely confined to engineering teams, and at great cost to the project.

According to research by Hoozoree and Ramdoo[5] requirement-related issues (which is based around making good decisions about what the true user needs are and what to do about it) remain a major source of unnecessary rework for the following reasons:

1. Poorly defined, incomplete, or conflicting requirements. Many requirements do not even become apparent until the software exists.
2. Unrealistic expectations of the customer.
3. Insufficient involvement from team members (ie: silos).
4. Poor dissemination of project needs (ie: siloed information).

This research spans the last 30 years! We know the risks, and we know the solution is breaking down silos and drawing on each other’s strengths. Most — perhaps all — of the issues above can be mitigated by having robust ResearchOps processes with strong integration. But handoff still persists.

To harness the power of ResearchOps, researchers need to be part of the product team, where they can iteratively bring real (and potentially evolving) user feedback into the project when it is most relevant. Depending on the project stage, research and discovery could look like user interviews, market analysis, direct usability testing, and more. I love this timeless diagram of the Research Funnell from Emma Boulton:

Image credit: Emma Boulton

Research should not be confined to a single stage, and should not be conducted in isolation from the product. It is iterated upon as the team learns more and has more to test. User needs are not divined, they emerge.

Unlike in the traditional Double Diamond process, the results of research stages should be incorporated and disseminated via the prototype — our shared medium — rather than waiting in a repository until an enterprising person makes the connection and brings it to the attention of the product team.

There is a lot of translation that needs to happen from traditional research outputs to a working product, and handoff means that work is done by other teams down the line. A shared output keeps us authoring together.

The benefits of functional prototypes are many, and some might surprise you:

• Everyone’s work is more visible. Just this alone goes a long way to building empathy and breaking down silos.
• Working prototypes are typically in a shared language that everyone understands. From the C-suite to the user on the street, we all know how to “read” a working interface.
• The audience who can natively read, understand, and contribute to a working prototype includes people who rely on assistive technology — if it is built accessibly of course. Making HTML your medium (instead of relatively flat and inaccessible mockups, for example) means researchers, designers, and developers who rely on screen readers or other assistive technology can be full contributors from the very beginning. The product and the process can both be born accessible, but not within our current tools and norms. And I’m sure it goes without saying, but people with disabilities are the world’s experts on accessibility. Systematically leaving out this entire group of stakeholders is unjust and deprives the project of a key source of expertise.
• As a source of shared truth, a prototype is unbeatable. Which would you understand better: a 100 page specification document full of jargon, or a prototype you can directly test and use? It can also act as a living specification document. It is the embodiment of all the research, discussions and decisions that have taken place so far.
• A functional prototype right from the start enables earlier research integration and working patterns that you cannot accomplish any other way. We can collect frequent and high quality feedback from stakeholders based on actual functionality, eliminating a lot of conjecture and guesswork. And we can collect this feedback at each iteration, not just as a large research effort upfront, or waiting until a product is almost fully developed for more testing.
• Inviting users into a Beta has long been used by large companies like Google as a soft-launch strategy and a way to reduce risk. Working in iterative cycles on a working prototype means there is no “big reveal” with its accompanying risk. Instead, we are sharing with our co-creators (including customers) all along, and addressing the inevitable questions and confusion that complex product builds bring much earlier in the process. We also leverage the psychology of familiarity, which — contrary to popular belief — breeds affection.

Once we get over our fear of sharing an unpolished output, the benefits of co-creating with all stakeholders are many.

How can researchers contribute to a working prototype?

Prototypes open new ways of communicating with users and other stakeholders that don’t require translation. It can be challenging to help stakeholders fully understand the potential of a research finding, or the richness of functionality that a mockup is representing. Working prototypes leapfrog many of these communication pitfalls. So, though we don’t all code, there is too much at stake to close the door on prototyping.

What we need are processes and tools that meet us where we are at. What might that look like for research?

• Planning research work across the full spectrum of the research funnel, with iterations becoming shorter as the project progresses from discovery all the way to product refinement.
• Templates that bridge from research insights to prototypes more easily.
• Customer/stakeholder participation early and often. User discovery should set the direction and cadence of each following build cycle.
• Share research insights with other stakeholders through the medium of the prototype. It is intuitive, engaging, and memorable.
• Bring product teams into the research. There is nothing more powerful than hearing user needs directly, and it will give weight and context to emerging research insights. It also makes research work more visible to other teams.
• Engage in implementation discussions with devs and others on the product team. It will make their work more visible to the research team.
• Get people who use assistive technology on your teams. Among many other benefits, people with disabilities are the world’s experts in true accessibility, and will help your team shed siloed mentality.

The perfect tools for everyone to code a prototype together may not exist (yet… they are coming), but the door is wide open to co-creating right now. We can do the difficult underlying work of transforming our team norms and expectations, so that improved tooling will only build on our success.

Conclusion

Project handoff introduces unnecessary risk and inefficiency, team frustrations and false antagonism. In contrast, iterating on a shared prototype promotes high team involvement.

To iterate together our silos have to come down. We need to reframe the Double Diamond as a process that involves the whole team and contributes to an ever-improving prototype, instead of outputs that are handed off. And those outputs need to be in formats that everyone can read and understand, including people who rely on assistive technology.

Integrating research throughout the team process is one of the most powerful options we have for reducing risk; ensuring the whole team is doing the right things, and doing things right, throughout the process. To do that, research must take its rightful place in the product team. ResearchOps is ideally positioned to enable this transformation.

References:

[1] Robert N. Charette. Why Software Fails. IEEE Spectrum. 2005

[2] Barry Boehm. Software Risk Management: Principles and Practice. IEEE Software Magazine, Jan. 1991

[3] Geshwaree Huzooree and Vimla Devi Ramdoo. Strategies to Reduce Rework in Software Development on an Organization in Mauritius. International Journal of Software Engineering & Applications (IJSEA), Vol.6, №5, Sept. 2015

[4] Titus Winters, Tom Manshreck and Hyrum Wright. Software Engineering at Google: Lessons Learned from Programming Over Time. O’Reilly Media, 2020.