Should Product Discovery tasks be tracked on your kanban or sprint board

Product Discovery involves a lot of different tasks, executed by a cross-functional product team of product manager, product designer, and tech lead, as well as developers on the broader team.

But how do you keep track of all these tasks? How do you keep an overview and make the work visible? Should the product discovery work be tracked in the backlog where engineering and design work is tracked?

Let's look at common product discovery activities

Product teams interview (potential) customers to discover high-impact customer pain points, needs, desires. Structure and prioritize customer problems. Brainstorm potential solutions. Identify and prioritize critical assumptions. Defines experiments. Run experiments. Capture learnings. Decide on a single solution that solves the problem best.

Most of these activities are some form of meeting, whether it's a customer interview, a working session to narrow down the highest impact problem, or a brainstorming session to come up with multiple potential solutions. Most of these activities are very fluent and unpredictable and are mostly driven by the product manager, product designer, and tech lead. As you cycle through this process there is always a certain amount of time per week that needs to be dedicated to product discovery.

How to stay on top of your product discovery work

Document the state of your product discovery in Confluence, Notion, Google, etc. This allows you to always reference back to your understanding of the problem space, learnings from experiments, and your thought process of how you aimed to impact a certain outcome. Artifacts created as outputs from the discovery process are incredibly important intellectual property for your product.

Aside from capturing the state of your discovery, you might track and coordinate your tasks to schedule interviews and meetings that represent discovery activities. The development board is not the right place to do this. These are mostly tasks driven by the product manager and product designer, and in some cases, the tech lead. Tracking this in the development board would add too much noise, screw with metrics and be irrelevant for the execution focus this board should have.

How to account for the developers time in Product Discovery

Product discovery should be done continuously. Every week there should be customer interviews, every week you should continuously push product discovery forward. Instead of trying to shoehorn general discovery tasks into an engineering workflow, allocate a certain amount of time for product discovery for the team. Plan for developers attending customer calls, or product discovery working sessions. Use retrospectives to find the right balance of how much involvement is appropriate.

That said, there is one set of tasks that should go into the backlog.

What tasks to track in the development board

Tasks to implement experiments for assumption testing. These are usually the only tasks where coding or designs are required, therefore should be tracked in your backlog especially when they need the involvement of the broader development team. These might be design mockups, code prototypes to test performance, validation if all data needed for calculation is available, or a quick PoC of integration with a 3rd party tool, etc. The outcome is always learning and a change in confidence in the validity of the assumption. The design and code is throwaway code, not meant to end up in production. At this time you are testing the assumption of potential solutions, so only one (or none) will end up for delivery. Spend only a minimal amount of time to satisfy the experiment.

A good practice is to differentiate on your board between discovery and delivery tasks. This gives you better visibility of what work is done by your teams and allows you to filter tickets for additional performance analysis.

If you are interested in how to measure product discovery efficiency check out the post from Teresa Torres on how to measure product discovery and guide your team