Continuous product discovery (CPD) sounds simple. Instead of doing all your research at the start of a project, you talk to customers regularly, in small amounts, so their feedback shapes every step of building the product and not just the beginning.
The idea is easy to like. Keeping it going is the hard part.
For my MSc thesis I spent several months studying how organisations actually run continuous discovery. I interviewed eight senior practitioners who were either running CPD inside their organisations or advising others on how to implement it, including principal researchers, research operations leads, product owners and consultants. I also ran a workshop with twelve people across two product teams who wanted to adopt it. The same problems came up again and again.
Below are the eleven challenges that came up most often, and the ways practitioners get past them.
1. It rarely gets fully implemented
Almost everyone wants to be more strategic and more proactive, which is the whole point of continuous discovery. But very few teams do it properly. They train for it, plan for it, and then slowly go back to their old habits. As one participant put it, few are doing it realistically.
Two related problems sit underneath this. The first is cadence: teams struggle to hold a consistent rhythm, and the ones I studied ran anywhere from weekly to two, four or six week cycles. The second is measurement: the wrong KPIs make it easy to misjudge whether it is working at all, because short-term metrics often miss long-term improvement.
What helps: start very small. Run one short, time-boxed experiment instead of trying to roll it out across the whole department. Pick a cadence you can actually hold and treat your objectives as a hypothesis to be tested and refined, rather than a fixed target set once.
2. People do not fully understand it yet
There is often a gap in basic knowledge about what CPD is, and in particular about testing assumptions. Teams tend to jump straight to building a high-fidelity prototype to test a solution, when the real job is to test what needs to be true for that solution to work.
What helps: change the goal. Before you build a prototype, write down the assumption you are making and the result that would prove it right or wrong. Testing an assumption is cheaper, faster and more honest than polishing a design nobody has checked.
3. Too many insights, not enough action
Talking to users every week produces a lot of raw information. The hard part is not collecting it. It is turning a pile of insights into a decision.
What helps: capture insights in a simple, consistent way, such as a short snapshot with one direct user quote, and review the backlog on a regular schedule, for example every quarter. That way patterns rise to the top instead of building up. An insight that never turns into an action was not worth collecting.
4. Nobody has the time
Product managers and stakeholders are busy, and making time for extra weekly discovery is genuinely difficult. Engineers also tend to drift away over the weeks.
What helps: stop treating discovery as an extra task on top of delivery. Build it into the sprint instead. Many teams protect one fixed day for research, and rotate who takes part so the work is shared rather than left to one person.
5. Keeping the team aligned
When people expect continuous discovery to pay off straight away, they lose interest when week three does not produce a breakthrough. Keeping product, design, engineering and management aligned and involved over time is one of the harder parts.
What helps: set expectations early about how long results take, and hold a short debrief after every session so the whole team hears the same thing at the same time. Being in the room with users is what keeps people involved.
It also helps to treat disagreement as a team problem rather than a fight to win. One participant described deliberately taking the other person’s perspective and listening with empathy instead of, as they put it, flipping the table and fighting a theological war. Patience and genuine listening move people further than being right.
6. Recruitment never stops
A continuous process needs a steady supply of the right participants. If your audience is specialised, finding and scheduling them every single week becomes exhausting.
There is a related failure mode: CPD gets bolted onto everyone’s daily work as an extra thing rather than being set up as a process in its own right, which quietly guarantees it will slip.
What helps: build a managed pool of participants. One practitioner mentioned keeping around a hundred users and rotating through them, with a cooling period so the same people are not contacted too often. When your own users run low, look for similar audiences, such as people in the same role or industry, through panels and agencies.
Underneath all of it, securing buy-in from senior leadership to spend real time and money on discovery is what makes the rest possible.
7. Doing analysis and storage properly
Under time pressure it is tempting to pick out the quotes that confirm what you already believe. That, along with GDPR and data storage rules, makes careful and compliant analysis harder than it looks.
What helps: set aside real time for analysis, not just for collecting data. Use clear metrics for assumption testing so you are measuring against a standard you set before the session. Then triangulate: check what you heard against other sources, such as analytics, support tickets or sales conversations, so one loud interview does not become a finding on its own.
8. The tools work against you
Tools like Jira, Trello and Linear are built for delivery. They push you straight into tickets and sprints, with little room for the earlier thinking that discovery needs, such as opportunities, assumptions and options.
What helps: give discovery its own space. Whether that is an opportunity solution tree, a Miro board or a simple insight repository, keep the work of deciding what to build, and why, somewhere that is not built around shipping tickets.
9. Bias from untrained researchers
When designers or product managers run interviews without training, quality drops and bias creeps in. Inconsistent interviewing leads to inconsistent, and sometimes misleading, findings. It is worth remembering that confirmation bias is often strongest in the people closest to the product, who already have fixed ideas about what it should be.
What helps: you do not need everyone to become a researcher, but you do need guardrails. Practitioners named several:
- Detach from what you already know. One participant described deliberately acting as if they had never seen the product before.
- Ask about past actions, not opinions. Get people to think out loud about what they actually did last time, and excavate the story from there, rather than asking what they would do in future.
- Use a less attached researcher. Someone with no stake in a particular outcome gives a more neutral read.
- Review plans and scripts as a team before the session, and discuss findings together afterwards so no single view goes unchallenged.
- Involve stakeholders properly, including company-wide reviews for major projects, so findings are stress-tested rather than quietly accepted.
- Let untrained team members observe and take notes rather than lead, and give anyone who does interview some basic training, mainly on how to listen instead of pitch.
10. Justifying the cost
Continuous research is an ongoing cost, and when money is tight companies tend to drop anything that feels exploratory. Stakeholders keep asking what they are getting for it.
What helps: connect discovery to the outcomes leadership already cares about, such as a north star metric, revenue or retention. Be realistic about timelines, set the target up front, and find a champion in management who will speak up for it when budgets are under pressure.
11. Running out of momentum
Once CPD is working well, teams hit a quieter problem, which is keeping it going. You can genuinely run out of new opportunities to explore, and enthusiasm fades if the process starts to feel repetitive.
What helps: widen your view. Bring in nearby audiences, non-users and former users, and gather signal from support tickets, analytics and sales conversations. Treat the opportunity solution tree as a living document, not a fixed checklist.
What ties these together
Looking across the eleven, a clear pattern shows up. The hardest parts of continuous discovery are rarely about research technique. They are about alignment, buy-in and keeping up a habit. Small experiments work better than big rollouts. A champion in management matters more than a perfect process. Getting the team in front of users matters more than a polished report nobody reads.
Continuous discovery is hard to start, and honestly, hard to keep going. But every practitioner I spoke to agreed on the payoff. Once it is up and running, it is much faster than stopping and starting big research projects, and it keeps the whole team close to the people they are building for.
Further reading
- Teresa Torres, Product Talk. producttalk.org
- My MSc research. Read the case study
This piece draws on my MSc User Experience Design thesis, “Continuous Product Discovery,” which looked at how organisations can adopt CPD as a consistent, repeatable practice. You can read more about the research in the case study. New to the topic? Start with what is continuous product discovery, or see the practical 12 guidelines for adopting it.
