Apr 28, 2023 > [!Summary] > 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 get started with a pilot experiment. Making software is hard. Making software that solves a real need for customers 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 specialized, the Agile approach struggles. Many organisations are [dealing](https://uxdesign.cc/the-age-of-agile-must-end-bc89c0f084b7) 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 is only going to accelerate these issues](https://uxdesign.cc/to-benefit-from-ai-your-organizations-learning-loops-must-evolve-5b6145415f6a)). But many orgs are finding a new way forward by strengthening cross-disciplinary collaboration in product teams, often with Continuous Discovery methods at the centre. ## 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 OKRs to guide strategic prioritization, and 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](https://www.mironov.com/waste/) because no one took the time to discover the most impactful problems to solve, and to make sure the solutions actually provide value to users. At the core of these trends lies the fundamental, basic insight: To make software which solves a real problem that exists in the world, you have to work on [discovering, defining and framing the problem](https://www.youtube.com/watch?v=yl7g13_Un_I). Problems often have a high degree of 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 is going to benefit from the team spending time on defining and clarifying the problem while solving it. But in so many organisations Agile is only synonymous with [problem-solving](https://www.dubberly.com/articles/why-we-should-stop-describing-design-as-problem-solving.html). 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 lacks the appetite to handle it. The result is a gap between those who strategize 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 without much success. A nice way forward for organisations dealing with these challenges is to try out Continuous Discovery methods. ## 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](https://www.producttalk.org/2021/05/continuous-discovery-habits/) 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 will be able to make better decisions about what to work on, which in turn leads to higher impact. A side-effect is that the team is brought 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 a lot more appealing to organisations where research was previously de-prioritized 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](https://www.svpg.com/books/empowered-ordinary-people-extraordinary-products/): They no longer deliver features for a roadmap defined by someone else. Instead they work on assigned objectives - outcomes or problems to solve - and come together to figure out what to build in order to deliver the results the company needs. They own the problem, and along with it the solution they choose to build in order to solve the problem. 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 an outcome-oriented management approach like [OKRs](https://www.amazon.com/gp/product/1955469016/), 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 change to add onto an existing organisation! Here’s where Continuous Discovery simply lets you start at another level. ## 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, in this case a typical cross-functional one with product management, UX, and engineering represented. All team members: - Contribute to identify 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](https://www.producttalk.org/2022/04/best-customer-interview-questions/) and build out a detailed map of the customer experience. This approach is different 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](https://www.producttalk.org/opportunity-solution-tree/) that captures all the stories, and helps the team make good decisions about what to work on. (OST illustration) The third ingredient is de-risking the solutions the team comes up with through assumption testing, a technique similar to [RATs](https://hackernoon.com/the-mvp-is-dead-long-live-the-rat-233d5d16ab02). As the team makes its way through this process, they keep interviewing customers to refine their experience map and opportunity solution tree, and build up more confidence in the new way of working. ## 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](https://uxdesign.cc/ending-design-handoff-this-is-our-fight-b376d2b58e4a)), and this helps the team move faster and build things with high impact, which in turn boosts team morale and over time affects culture positively. Among the success stories are teams that become able to [rally the whole company](https://www.mindtheproduct.com/a-case-study-how-our-own-product-discovery-made-us-pivot-reveall-towards-product-discovery/) behind the same priorities, add [speed and confidence](https://www.mindtheproduct.com/continuous-discovery-by-konstantin-diener/) to big, messy decision-making processes, or simply get a steady stream of signals to help [prioritize the work for impact](https://www.mindtheproduct.com/how-i-do-continuous-discovery/) 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 that Continuous Discovery is in fact owned by the entire team.  Second, a clear product strategy needs to be in place. Continuous Discovery is not generative in nature - 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?”. Third, it requires investing in people - coaching, and allowing folks to learn through doing and make mistakes along the way. Finally, 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 not the solution to every research question that pops up - you will probably still want to do more specialized, 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 in a new structure. - With a team working on a big, complex effort - could be a new strategic software offering the company wants to bring to market. Maybe the team is struggling with the direction or getting a foothold on the problem. - With a team that struggles to deliver impactful solutions on their product. Maybe one of the partners (Product, Tech, UX) isn’t pulling their weight.  - With a team that's 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, 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 and 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 at all 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 make sure 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. ## Won't we lose control? When the people working on the software own outcomes and problem discovery and definition together, that’s simply the best use of everyone’s time; it lets teams de-risk, build and release much faster, and with higher impact on the outcomes that matter for the business. But to an organisation's senior management, that sounds a lot like loss of control; How will we know what work gets done and to which deadlines? How will our teams be guided? First of all, don’t throw away Agile. It’s more useful to think about discovery as something that gets integrated into your existing agile processes. After all, the Agile Manifesto states principles like “Customer collaboration over contract negotiation” and “Responding to change over following a plan”. There are [so many ways to achieve this](https://www.hyperact.co.uk/blog/ten-common-product-discovery-traps). And rest assured, there’s still a need for a clear strategy - perhaps even more so than before. Now, rather than product strategy being pushed into the organisation from above, teams will start pulling it, requesting it, and making demands of it if it’s not clear enough.Your strategy will see some use in the real world - and eventually, if you keep going, you may see your management co-creating the strategy in the future, bottom-up, with your product teams. **