How to get from insights to features?

  • 20 February 2023
  • 5 replies

Userlevel 1

I’ve been using Productboard for the last 3 months since joining the business and am rolling it out across the teams. I’m the only maker at the moment but I have lots of contributors from all levels within the business, adding notes and insights. This isn’t so much a question about productboard, it’s more about the process that people follow.

I’ve been asked to help get a stakeholder group (senior leadership at the moment) to be part of the process of taking ideas and insights through discovery, planning and development. I want to run a session with them talking through and deciding on a process we can follow and build on. That’s what I would like some advice on.

We have some slightly wooly objectives, but it’s a good start (more than I’ve had in some previous roles).

If I get ‘too producty’ I think I will lose them, so I want to keep things simple and come up with a process we can start with to help us decide where we should focus our attention.

How have you taken those first steps for an org that is bought into the process, wants to explore and discover, but at the same time, isn’t very familiar with doing so?

I’ve talked them through the higher level double diamond approach, which was well received, so now it’s that next level of how are we going to apply that and move forward which I need to crack.

5 replies

Userlevel 7
Badge +13

Hi @Garry,

In short, this comes down to selecting those items that are most important to your customers (informed by insights) and most beneficial to your business, then advancing them though the problem space and solution space. Every team has their own way of approaching this collaboratively, but you might find some value in reading books like Sprint or reviewing processes used by others (e.g. Basecamp’s ShapeUp ) as you figure out your own.

We’ve written about our double diamond approach on our blog: 

A process might look like:

  • Take a kick at what you think the priorities should be, create a view in Productboard showing those priorities and how you came to that decision, then bring them together and walk through it and why. Leave some space for debate and discussion and give them a chance to share why they might have a different perspective to share, adjust your priorities where needed.
  • Once you have a clear list of candidates, try to sequence their importance and get your team to do discovery work -- making sure you truly understand the problem space
  • Then your team can dig into exploring solutions and how best to address those needs, looping back with customers that shared the feedback or did discovery with you to validate early concepts and/or prototypes
  • Once you have clarity on your solution path, you can start building, while bringing your same customers into the fold through early access or beta programs, giving them a chance to test it out and share feedback on the solution
  • Lastly you can ship the capability/feature and see if it drives your desired outcomes, reporting on the metrics and outcomes.

And on the discovery side of things, our recent session with our PM, Kami might be helpful in getting your team started on an approach: 


Userlevel 5
Badge +2

I agree 100% with @scott.baldwin’s points. I’ll expand on his starting point …

showing those priorities and how you came to that decision


Knowing how you got there is a HUGE first step for a lot of orgs. I, unfortunately, learned the hard way a few times before I got this part down.

Ensure the leadership team can agree on their current strategic position and how they plan to move forward. They need to agree on the big opportunities in front of them, which one (maybe two) is worth focusing on, and generally how they plan to address it. With that framework, a leadership team have rational conversations about prioritizing programs, projects, and experiments at a tactical level.

If you put a leadership together to prioritize before that foundation is in place, the outcome will be unpredictable at best. Politics, siloes, and opinions are the currency and the strongest personality in the room tends to come out on top.

Userlevel 4
Badge +4

I echo what @scott.baldwin said as well. Lots of good tactics in his post.

Productboard is a tool I use to gather insights from around the business and customers directly to help better understand the scale and urgency of a problem, then looking at all of the possible candidates as a whole, I can better prioritise what to build next.

We have even gone a step further and filed all features/improvements into a jobs to be done framework within Productboard (each job is the top level in our hierarchy) and we use these jobs as levers to help decide what impact we want to make on a particular iteration of the roadmap.

In general, I don’t think senior leadership should be the ones deciding what exactly should be build next, but rather setting the objectives of what the business is trying to achieve (e.g. become a profitable company, have X MRR by Y date, become a major player in ABC market etc.). Then the product team takes it from there to do discovery and prioritise what should be done next to meet those objectives. It’s easy to start solutionising when talking about what to build next, but product teams are really good at first deeply understanding the problem, then finding the appropriate solution for the user and the business. If the people involved in making solution decisions aren’t involve din discovery, they likely won’t make the best choices for the user. Ultimately, this is what product teams are hired for: building a product that meets user needs and propels the business forward.

Userlevel 7
Badge +13

Great points and additions @plainclothes and @Parveen Downer -- thanks for adding your wonderful and practical perspectives to this. @Garry let us know if this helps you in your journey and exploration.

Userlevel 1

Thank you for the responses, they are very useful.

My next step is agreeing how we are going to apply some level of value at these early stages and what that means. I’ll also be diving into the objectives/goals some more to try and get a little more detail. This will help them understand how we make the decisions and take a lot of the politics etc out of it.

Once we all agree and understand why we are making the decisions, then the product team will have that confidence to run with it.