Co-Developing Products: A Deep Dive Into Customer Insights
Co-development means companies create products with their customers and users. Explore the benefits and three layers of customer insight.


Product teams spend a lot of time trying to understand customers. Sometimes the best way to do that is simply to build alongside them.
Co-development brings customers and users directly into the product development process. They help us understand the problem, challenge our assumptions, test ideas and, in some cases, shape the solution itself.
We use this approach extensively at Entrust. It gives our teams access to information that is difficult to get from market research alone: how a problem plays out in a customer’s environment, which constraints actually matter, and whether the thing we’re building works outside our own assumptions.
There are four reasons we find it particularly useful.
Four reasons to develop products with customers
Better customer insight
Customers know their business better than we do.
They understand their workflows, constraints, priorities and the workarounds they’ve already created. Working directly with them gives product teams a much clearer picture of the problem before committing to a solution.
The goal isn’t to ask customers what to build. It’s to understand their world well enough to make better product decisions.
Faster learning
Direct access to customers shortens the feedback loop.
Instead of building something, launching it and then discovering what we got wrong, we can test assumptions while the product is still taking shape. Teams can prototype, learn and adjust before decisions become expensive to reverse.
That can lead to faster delivery, but the more important benefit is faster learning.
New ideas
Working with customers regularly takes us in directions we wouldn’t have reached on our own.
A customer might expose an edge case we hadn’t considered, combine the product with another system in an unexpected way, or describe a problem that changes how we think about the opportunity.
Those conversations don’t replace product judgement. They give us better raw material to work with.
Lower risk
Every product decision contains assumptions. Co-development gives us a way to test more of them before launch.
The closer our development partners are to the customers we eventually want to serve, the more useful that learning becomes. It doesn’t guarantee product-market fit, but it gives us considerably more evidence before making a larger investment.
The three layers of customer insights
We originally used Emma Boulton’s Research Funnel to structure our User Research practice at Entrust. It provides a useful way of thinking about co-development. Customer involvement can happen at three different levels: exploration, strategy and tactics.

Exploration
At this level, we’re still trying to understand the problem.
We work with customers to understand who their users are, what they are trying to accomplish, where things go wrong and which problems are worth solving.
The output isn’t necessarily a product idea. Often it’s a clearer view of where the opportunity lies.
Strategy
Once the problem is clearer, customers can help us explore possible approaches.
We can test assumptions about the market, understand operational constraints and examine how different solutions would fit into existing systems and processes.
This helps us decide what to pursue before getting too far into delivery.
Tactics
This is the form of co-development most people are familiar with: testing and improving the product itself.
Customers might review prototypes, participate in usability studies, use an alpha release or help us understand how the product needs to behave in their environment. We also work in both directions.
We involve customers in the development of Entrust products, and work with them on the experiences they are building for their own users.
Getting the insight is only part of the job. It also needs to reach the people making decisions.
We use tools such as Productboard and Dovetail to make research and customer evidence available across Entrust, but the specific tool matters less than the habit. A useful insight trapped in a research repository has very little value.
Examples of co-development in Entrust products
Two products show what this looks like in practice.
In both cases, the teams worked in short cycles. They formed hypotheses, built or prototyped solutions, put them in front of customers and users, and used what they learned to shape the next iteration.
Motion
Motion lets customers check that an end user is physically present using a simple head movement.
The interaction looks simple. Making it reliable, accessible and resistant to fraud was not.
The team worked closely across design, engineering, research, customers and users, repeatedly testing and refining the experience. That process helped the team improve accessibility, examine potential bias and significantly improve fraud performance.
Giulia Di Nola explains more about how the team developed Motion and how customer and user research shaped the product.
Real Identity Platform
Our Real Identity Platform lets customers build identity verification and onboarding workflows visually rather than relying on constant engineering work or app releases.
In the Studio Editor, customers connect tasks on a canvas to define a workflow. They can add conditions, branching paths and different outcomes, including steps that are automated or escalated to a person for review.
Steve Dennis explains how the Studio team used frequent iteration and continuous discovery with customers to take the product from an early idea to something customers could use in production.
Why co-development is the future of product
The most useful thing about co-development isn’t that customers give you better ideas. It’s that they give you better evidence.
They expose assumptions that are invisible inside the product team. They show you where your understanding of the problem is incomplete. And they let you test decisions while there is still time to change them.
That doesn’t mean handing product strategy over to customers. Product teams still need to decide what to build, which problems matter and where to make trade-offs.
Co-development simply gives them a better basis for making those decisions.

Hook this up to your favourite commenting platform — Giscus, Disqus, or your own.
Continue reading

Data-driven Product Launch — Onfido Studio
How a data scientist approaches a B2B product launch from first principles — defining metrics before a line of code ships, building the data model, creating pre-launch dashboards, and learning from the first beta customers.

Remote Design Sprint: Learnings from Facilitating
Tales from a designer running his first remote design sprint — what preparation actually means, how to stay adaptable when things go sideways, and why team dynamics matter more than any template.

Causal Inference at Onfido
How Onfido's data science team built a Structural Causal Model of their document verification pipeline — and used it to simulate the impact of product improvements before shipping a single line of new code.