Continuous Discovery and the New Collaboration
- Jeppe Kruse
- Strategic Design Director
- Send an email
Companies building complex digital products can benefit from using new collaboration methods and continuous discovery to improve outcomes and ways of working. This article looks at why continuous discovery works and how to start with a pilot experiment.
Reading time:
8 minutes
Making software is hard. Making software that solves a real customer need and creates value for the business is even harder. For a long time, the Agile movement has offered a solution to this fundamental challenge. But, as complexity grows, teams grow, and functions become more and more specialised, the Agile approach needs to be revised.
Many organisations are dealing with low impact and poor employee motivation and retention levels; their agile processes fail to connect strategy and delivery, often solve the wrong problems, and can't reliably produce quality (and by the way, AI will only accelerate these issues). But some organisations are finding a new way forward by strengthening cross-disciplinary collaboration in product teams, often with continuous discovery methods at the centre.
Teams build and release software that doesn't have the desired impact.
The problem with Agile
Maybe we haven't entered the post-agile era yet, but 'Agile' as methodology and practice is starting to show signs of wear and tear:
In larger organisations building software at scale, shifting objectives and competing agendas in the design, business, and engineering domains lead to poor decision-making and missed opportunities for software delivery teams. This happens even when using frameworks like Objectives and Key Results (OKRs) to guide strategic prioritisation. As a result, teams become too far removed from the Why of what they're building.
At the same time, creating lateral alignment between teams can feel like an eternal struggle.
For start-ups and innovation efforts in the enterprise, teams often still fall into the trap of building and releasing software that doesn't have the desired impact because no one took the time to discover the most impactful problems to solve and to make sure the solutions provide value to users.
At the core of these trends lies the fundamental, basic insight: To make software that solves a real problem that exists in the world, you have to work on discovering, defining, and framing the problem. Software typically has high complexity, so framing can happen at all levels, from strategy to the smallest implementation details. And it never stops - any change we make or new feature we build will benefit from defining and clarifying the problem while solving it.
But in so many organisations, Agile is only synonymous with problem-solving. Problem definition is not seen as something a product team does - maybe under the assumption that the product team is too busy, not competent enough, or needs more appetite to handle it. The result is a gap between those who strategise and conjure up the work and those who build and deliver. This leads to a scenario where teams get lost in the weeds, and management tries to exert control over the process, but usually with little success.
A way forward for organisations dealing with these challenges is to try continuous discovery methods.
Continuous discovery offers a way to reignite collaboration in a team, focus on what matters, and unlock strategic creativity.
PM, Engineering, and Design all have a stake in shaping the work.
Continuous discovery
Continuous discovery offers a bottom-up way to reignite collaboration in a team and focus on what matters. At the process level, it is all about connecting with your users and being intentional about why you do it.
Teresa Torres defines it as:
At a minimum,
weekly touchpoints with customers
by the team building the product
where that team is conducting small research activities
in pursuit of a desired product outcome.
There's a lot more to it, but those are the basic principles. The promise is that the team can make better decisions about what to work on, leading to a higher impact. A side-effect is that the team comes closer together because PM, Engineering, and Design all have a stake in shaping the work.
It's also worth noting that continuous discovery makes talking to users much more appealing to organisations where research was previously de-prioritised because it was seen as slowing the entire team down or because it felt too academic and monolithic.
It all sounds simple, so why does it have such great potential?
The new collaboration
In his 2020 book, Marty Cagan talks about Empowered Teams: They no longer deliver features for a roadmap defined by someone else. Instead, they work on assigned objectives - outcomes or problems to solve - and determine what to build to deliver the company's desired results together. They own the problem and, along with it, the solution they choose to build to solve it.
To succeed, this requires deep collaboration and openness in software teams. Uncertainty and hidden assumptions exist at all levels, and no one function has all the answers. The most successful teams are those who work together to:
Understand the problem from all angles.
Identify the various solutions they could choose to build and which risks are associated with them.
Create experiments together to test assumptions and de-risk solutions before designing and building.
Continue monitoring the impact of their build all the way through, making changes, or even pivoting if the solution does not produce the desired outcome.
But the idea of empowered teams is usually connected to adopting OKRs, and this changes how the organisation thinks about decision-making, planning cycles and tools, team structures, and incentive structures. All in all, a lot of changes to add to an existing organisation. Here's where continuous discovery lets you start at another level.
Start by testing the waters without changing your entire operating model.
As the team progresses they build up more confidence in the new way of working.
Continuous discovery is the way in
Teresa's definition above offers a way to test the waters without up-ending your entire operating model - starting with one team, a typical cross-functional one with product management, UX, and engineering represented. All team members:
Contribute to identifying the most important things they need to learn from users
Regularly join conversations where users talk about their needs and pains directly
Help build the team's shared knowledge about users and the opportunity/solution space the team is navigating
Done well, this creates an ongoing cadence that becomes second nature to the team. The first time around, the process goes something like this:
The team starts interviewing customers to collect stories and build out a detailed map of the customer experience. This approach differs from how most teams have traditionally thought about doing research: it's not a project but an ongoing process where each interview is way more scrappy, and the turn-around to arrive at insights is much faster.
The conversations become the starting point for understanding the opportunities available to the team. This is done by creating an opportunity solution tree that captures all the stories and helps the team decide what to work on.
The third ingredient is de-risking the team's solutions through assumption testing, a technique similar to RATs.
As the team progresses through this process, they keep interviewing customers to refine their experience map and opportunity solution tree and build more confidence in the new way of working.
Tthe team needs a pre-existing, detailed answer to the question “Where are we going?”.
Making it work
From the point of view of the business, this process produces clarity and shared understanding. It can become a forcing function for creating more collaboration in a team (which could lead to things like No-handoffs), and this helps the team move faster and build things with high impact, which boosts team morale and positively affects culture over time.
Among the success stories are teams that can rally the whole company behind the same priorities, add speed and confidence to big, messy decision-making processes, or get a steady stream of signals to help prioritise the work for impact at the micro level.
But critically, a few things need to be in place to succeed with continuous discovery:
The team should negotiate a new "contract" between the domains of Product, Tech, and UX to ensure the entire team owns continuous discovery.
A clear product strategy needs to be in place. Continuous discovery is not generative - it doesn't answer the question of which product to make or how to go to market. To succeed, the team needs a pre-existing, detailed answer to the question, "Where are we going?".
It requires investing in people - coaching and allowing folks to learn through doing and make mistakes along the way.
A good understanding of different types of research and what they can (and can't) do for your organisation is key. Continuous discovery methods are only one of the solutions to every research question that pops up - you may still want to do more specialised, stand-alone research for various other needs.
Starting with a pilot
Look for some of these scenarios where you could try continuous discovery methods with a pilot approach:
With a new team that is starting to work together - it could be in a new space or a new structure.
With a team working on a significant, complex effort - it could be a new strategic software offering the company wants to bring to market. The team may need help with the direction or getting a foothold on the problem.
With a team needing help to deliver impactful solutions on their product. Perhaps one of the partners (Product, Tech, UX) is yet to pull their weight.
With a team ready to take the next step and become more experience-driven in their approach.
And for your continuous discovery pilot to have the best chances of succeeding, here are some things to keep in mind:
Start with a team that is already collaborating well, and make sure the entire team is motivated and buys into the premise – that this is something all of the team will commit to in order to get the upside promised by continuous discovery.
Ensure leadership supports the experiment, sets the team free from other obligations, and that someone well versed in the product strategy is available to support the team closely.
Pick a time period that's not too short and fits an expected chunk of work the team will focus on. If possible, frame the team's objectives as outcomes to work on, not features to build, for the assigned period.
Assign someone outside the team to be a coach for at least a few weeks, and ensure the team knows why that person is there. The coach should instate a few key rituals and help the team understand how they're doing.
Don't underestimate the task of recruiting users to talk to. Make it the team's business to find ways to automate this process as much as possible.
Be prepared for the likely situation where the team wants to continue doing continuous discovery. Don't take this lightly – pulling the team back could be hugely demotivating for team members.