Tracking Product Discovery

Product Discovery

In recent years, product management has expanded from focussing on “building it right” – ensuring that a backlog is delivered to an acceptable cadence and quality – to “building the right thing”. This means moving away from the illusion of certainty to embracing experimentation.

Coupled with experimentation is an acknowledgement that a product manager is probably not the most qualified person to design the interface or do detailed data mining. More and more, product management teams are being formed of User Researchers, Data Analysts, UX and UI designers as well as Product Managers. The goal of this team is to identify user needs and create services that meet those needs whilst driving business value.

The diagram below shows how this system can work. We begin with insights, identify user needs for a given target group that will drive business value and hypothesise concepts that will satisfy these requirements. These hypotheses are necessarily experiments: we might be right, we might not. We only find out by creating something (or better, things) and testing.

Discovery and Delivery process
Discovery and Delivery process

Following this product discovery process we create artefacts that aid communication and understanding: user stories; prototypes; acceptance criteria.

And after some validation, we are ready to build – which is where familiar tools such as JIRA or Rally are used.


Coordinating the elements of Product Discovery can be difficult. I’ve known teams attempt to create a Todo / Doing Done board within JIRA; however, the issue is that there is no single task that moves.

When a development team works on a story, the story card remains constant and moves into different stations (e.g. Analysis, Design, Build, Test, Deploy for the classic Scrum-as-Waterfall model).

Tracking progress through Development
Tracking progress through Development

However, in product management, we identify Insights that help us identify one or more user need. Concepts answer these needs – ideally more than one concept as we should be testing. And a Concept may meet more than one need.

Each concept will give rise to one or more user stories and one or more designs.

So there’s an issue with what we are tracking – we tend to think of stories but are actually tracking the meeting of needs. And even these may be met by more than one concept, so there isn’t a neat 1:1 mapping from one phase of discovery to the next.

Flow in Product Discovery
Flow in Product Discovery

From what I’ve seen of many tools, the collaborative product management approach is supported by “Hey colleagues, send me your ideas and we’ll vote on them!”. While it’s great to gain ideas from the wider company, these are actually only insights, from which we must still identify user needs. I also have my reservations about voting. Ultimately we want to drive business metrics, not popularity.

Observed Problems that need resolving

There are several issues that I’d like a tool to resolve:

  • a lack of a central storage space means that team stores insights separately. This causes research to be repeated and learning is not shared across teams
  • a lack of tracking means that we cannot easily trace development requirements back to the originating insight. At best this leaves teams open to HIPPO prioritisation; at worst it means that the stories for a development team might not answer the original need
  • No common storage or version control causes teams to fake this on Google drive (or similar) or on local storage. The main issue with Google drive is that people forget to remove staff who’ve left; it’s an administration headache.
  • No natural coordination between work in progress and product roadmaps. Sure, we don’t want roadmaps going forward for years. But we ought to be able to identify themes and track the progress of concepts that we believe meet the needs within those themes.
  • Tracking associated non-development tasks (e.g. creating a case study, training customer support) gets tracked in yet another place, such as Trello. Again, Trello is a great tool but it’s not integrated with this process.

What I’d like to see

  • Easy storage of user insights
  • Traceable progress from insight through to development backlog (and maybe even MVT…)
  • Building of roadmaps
  • Easy and ready sharing of concepts / prototypes, etc


To conclude, I’d love a tool that does this or that can be readily adapted. Should I find one, I’ll be sure to publish my experience with it. So please leave your thoughts below.

Tool vendors, I’d love you to join in! Feel free to add comments about how your tools fit with these needs.

Appendix: User Stories for Product Discovery


As a User Researcher, I want to log and share insights and research, so that effort is not duplicated and learning is not lost.

As a User Researcher, I want to easily retrieve stored insights from across the business, so that I can start to identify related user needs.

So we need a big data store that swiftly searchable and trivial to add to. It’s essential that we can tag and log basic information. It’d also be useful to have easy addition by, say, email.

And we need to be able to swiftly pull back these insights. See the age of them, who logged them, etc.

User Needs

As a User Researcher, I want to distill insights into needs, so that I can identify what our user truly wants.

As a User Researcher, I want to tag which insights have been pulled into user needs, so that we can later identify which insight sources are most effective or which insights are most helpful

OK, so we might not use the tool to *derive* user needs – this could be a group exercise done on a whiteboard. But when we’ve detailed them we need some means to track them for analysis and so that we can see where our user needs come from.

Concepts & Hypothesis

As a member of a Product Management team, I want to pull user insights, data insights and KPIs into a coherent hypothesis, so that we can build better concepts and tests.

As a member of a Product Management team, I want to track where my concepts come from, so that we understand the user need we are building for and the outcome we believe that we’ll see.

Again, this might not be *done* within the tool. But we need to be able to track the activity: where things come from and what we’re doing. And attach the concepts / reference where they’re stored.

Story Creation

As a Product Manager, I want to be able to trace back to concepts, needs and insights when writing stories, so that my dev team and I are reassured that we are adding value and meeting needs.


As a UI designer, I want to be able to trace back to concepts, needs and insights when creating designs and prototypes, so that I am reassured that I am meeting the correct user needs.


As a Product Manager, I want to create Roadmaps based on opportunity, so that the team can work toward these strategic goals

Non-Development Items

As a Product Manager, I want to track associated tasks so that I can deliver a complete product and track progress toward that goal


Author: Stuff Rich Writes

Cyclist and Product Manager. I blog about both.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s