The Problem With Continuous Discovery
…and how to solve it!
Like many tech companies, SEEK is a big user of continuous discovery. By involving a few customers each week for user research sessions, we aim to:
- foster a culture of continuous improvement in product teams;
- build deeper empathy for customers and their usage contexts;
- discover how specific customers perceive and use relevant products;
This research practice has proven to be quite valuable and useful. However —at the risk of sparking controversy —it does have a problem, namely that:
Continuous discovery is not continuous enough!
Despite the catchy name, continuous discovery is actually a frequent, small-batch process with limited coverage. As a result, it can still have issues like:
- Delays in getting insights
- Blind spots on some topics
- Risky extrapolation from a few cases
- Missing real-world context
- …etc
Don’t get me wrong — continuous discovery is well worth doing and I strongly encourage its ongoing use, together with traditional UX research methods. I’m simply arguing it has limitations we should acknowledge and strive to remedy.
What would truly continuous discovery look like?
Let’s stretch our thinking and try to imagine a truly continuous discovery process. What if we turned up the research parameters to extreme levels?
- participation: from 1 to 5 users per week → to 1,000s or more each week
- context: from structured or semi-realistic tasks → to full real-world context
- coverage: from a few specific focus areas → to all aspects of our products
- frequency: from a few times per week → to continuous insights every day
Imagine how effectively you could innovate with insights from this sort of truly continuous discovery process feeding into your product & tech teams.
But is that even remotely feasible?
You may be wondering if it’s even possible to manage the frightening logistics of large-scale, truly continuous discovery like that.
And, in one sense, you’re right —it’s not really feasible to extend CD or structured UX research to such frequent, high coverage, large-scale insights. Which presumably is why continuous discovery is done the way it is today.
But that doesn’t mean we can’t get the same sort of benefits in other ways…
The secret to truly continuous discovery is…
Let’s start by relaxing the constraint that customer insights should primarily be gathered by UX or product professionals in structured interviews.
With the right mindset and training, anyone in your team who interacts with customers can (and should!) capture powerful and relevant insights.
“Dedicated product teams in direct dialogue with customers always find ways to specify value more accurately and often learn of ways to enhance flow and pull as well.” — James P. Womack, Lean Thinking
Introducing your new best friends: Operations & Customer Support
Chances are that your front-line operations, account management, and customer support staff are already interacting with 1000s of people all the time on real issues that span every visible aspect of your product experience.
So the secret to truly continuous discovery is already within your grasp —
By connecting your front-line staff in a deeper, more integrated way with product development you can create a rapid & comprehensive learning loop to continuously improve your product much faster than competitors.
Of course, achieving this is not easy. For example, too much low-signal-to-noise interaction can distract software developers from deep work; product managers from the big picture; and operations staff from helping customers.
But it can be done. In this article, I’ll share how our SEEK startup has innovated effectively by involving the operations & customer support team in a customer discovery process that is much closer to being truly continuous.
How we do (more) continuous discovery at Certsy
First some context. As an early-stage venture in SEEK, Certsy is creating a digital credentials passport to help job seekers stand out on their merits. Since job seekers don’t traditionally verify their credentials early in the hiring process, we’re creating a new product category & challenging existing norms.
This makes it essential the entire Certsy team stays close to our users; has real empathy for their fears & concerns; understands their context & motivations; and gets a super fast feedback loop on what is working and what isn’t.
Here are some things we’ve learned to connect front-line functions directly with product and tech for more continuous discovery and rapid innovation…
1. Treat customer support as a strategic asset, not a cost centre
All too often, organizations treat operations and customer support as cost centers to be optimized for efficiency, instead of taking full advantage of their strategic value in generating insights and continuously improving the product.
There is nothing so useless as doing efficiently that which should not be done at all. — Peter Drucker
When creating a new product within or alongside an existing business, there’s often pressure to “leverage” the existing well-established support function for your new product. My advice: if rapid innovation matters, don’t be tempted!
Established support teams will almost always have scale efficiencies, better systems, clear processes, and so on — but these advantages can be outweighed by a slower learning loop because they lack your singular product focus.
Over time, investing in this learning loop leads to much higher efficiency at scale and better root cause elimination of many common support issues.
With Certsy, we built our operations & customer support in-house from day one. Online support tools (e.g. Zendesk) made it easy to get going quickly and to customize our processes over time. We also borrow proven ideas and practices from SEEK’s large customer support team where it makes sense.
In line with treating the function as a strategic asset, our head of operations & support is an important member of Certsy’s leadership team. This enables her to play a vital role in anticipating issues and user impact, improving our core product, and prioritising resources for innovative operational improvements.
2. Organize into autonomous cross-functional squads
To rapidly innovate and deliver better outcomes for our users, we need all functions to contribute their unique perspective and insights on an ongoing basis. Operations & support is closest to the customer, so their input is vital.
This was easy enough in a small team but after rapid growth to ~20 people we found it was getting harder. So we re-organized Certsy into a squad-based structure to encourage the right behaviour and cross-functional interaction.
Certsy now has 4 squads, each with a long-term opportunity area to focus on. Each squad is led by a cross-functional leadership team with real autonomy and accountability. While squad size & composition varies, there is always one leader from each of our 3 functions: i.e. engineering, product, & operations.
Cross-functional leadership and join accountability ensure that squad decisions consider all relevant product, technical, and operational issues. We find this gives the operations & customer support function a greater voice in product roadmaps and engineering work than typically happens elsewhere.
3. Focus on root causes and systemic solutions
It is vital to keep a high signal-to-noise ratio in interactions between front-line staff and your product & tech teams. Quality, not quantity, is the objective.
We encourage our operations & support staff not to pass along random bits of user feedback but instead to step back and ask why, spot patterns & themes, identify root causes, and suggest specific improvement areas and ideas.
Over time, this has helped us achieve user verification success rates far above industry average. For example, the team noticed a pattern of licences in one Australian state that wouldn’t verify at-source for a small subset of users — yet these licences seemed perfectly valid. Rather than shrug and accept it as an oddity of the government system, they rang the authority, spoke to customers, looked at patterns, and eventually diagnosed the root cause and how to fix it.
Similarly, our operations & support team reflected on what they’d learned verifying huge numbers of people, and distilled new concepts for our admin portal workflows. After refining this further with our engineering leaders, the new workflows were piloted on one credential and worked amazingly well in boosting efficiency and reducing cognitive load. So we’re now investing lots of engineering time in rolling out this new approach to all existing credentials.
4. Adopt an MVP mindset and “learning by doing”
We find that it’s often uncomfortable to launch a minimum viable product (MVP) but that’s why this practice is so vital for rapid learning & progress.
Naturally we do our desk research and upfront thinking, but we also try to hold ourselves accountable to launch basic MVP offerings as soon as possible. We then observe key metrics & behaviours, and engage closely with users (via Operations & Support) to understand issues so we iterate & improve quickly.
For example:
- Our “early access” program lets users on Certsy for other reasons verify a new credential before it is fully integrated with SEEK. This saves them coming back later, and lets us learn and improve new processes to handle real-world edge cases without being overwhelmed by huge volumes.
- Behind the scenes, we usually start with a manual process, rather than automating at the outset. This hands-on experience yields insights that help us design far superior automation & workflows. It also means we launch sooner, and have a fall-back option if ever an automation fails.
- We try to anticipate future problems but not immediately build solutions for them. Instead, we believe it’s better to feel the pain first — which requires patience and understanding from operations & support. But this way, if it is a real problem, we understand it more deeply and can solve it better; and if problems never eventuate, we’ve saved lots of time & effort.
5. Build relationships and channels for peer-to-peer communication
All of this works best in an egalitarian environment with psychological safety and practices that encourage people to talk directly with each other. Forget role titles, hierarchy and boundaries — good ideas can come from anywhere!
And, as the people closest to the customer, our operations & support staff often prove to be a particularly valuable source of ideas and insights.
To support this culturally, we invest a lot of effort in ensuring everyone understands our business and strategic context. We focus on hiring people who are curious and think beyond just their function. And we try to call out and celebrate examples of pro-active collaboration & innovation.
In terms of tooling, it’s pretty lightweight. We use Slack channels for general and project-based communications; and Trello for managing our roadmaps and work tasks in a way that is visible to everyone, including support.
The squad structure also helps, because everyone belongs to a small cohesive team that collaborates across multiple levels and functions. Plus, the functions —e.g. operations & support —also help us connect well across squads thanks to strong relationships and context built via functional rituals & processes.
How continuous is your discovery process?
I hope this article has inspired you to supplement your continuous discovery practices by connecting front-line staff more closely with product efforts; and that our experience sparks some useful ideas for how you can evolve your own approaches to regularly capture insights at scale for product development.
We’d love to hear your thoughts, experiences and insights on this topic, so please feel free to comment below and share what you’ve learned.
