How Productboard uses Productboard

Hi @Samkay, 

this topic is very close to my heart so I’ll chime in with how I approach this.  

Are insights being tagged to things in problems only?

It depends on how the initial note is phrased and whether I have any possible solutions or existing solution to extend in mind for a given problem. I do often find myself linking to multiple areas in the hierarchy, both JTBD and Solution section. 

Do features/components move from problem to solution? Or do you just create new ones and mark that problem is solved. Curious to know more about the flows you have. 

When I start working on a new problem area, I usually break things down into potential solutions under our JTBD hierarchy. Once we validate which solution(s) are the most promising and we want to built, I’d move them into Solutions area for further break down into stories. 

Could you expand on your 3rd question, please? I’m not sure I understand what you are after here. 

I can also share how I think about the split and how I decide where to track ideas/features.

Hierarchy is organised into several Products:

• Multiple Solution Products [e.g. Insights, Prioritization & Roadmaps] 
  • Product Surface Areas or Solutions centric part of our hierarchy
  • Captures existing features, requested improvements or scoped features in development
  • Grows as we develop new features
  • Covers Delivery phase or Discovery for incremental improvements of existing solutions
• JTBD Product
  • Describes jobs related to our product & customers
  • More stable as jobs stay the same over time (mostly)
  • Supports Discovery phase, unless we are working on incremental improvements of existing solution
  • Allows for radical innovation, as going Job-first makes it easier to think outside of our existing solutions.

@Samkay happy to help. 

Yes, single JTBD product for now and multiple solution products. We did discuss splitting JTBD product by tribe too but it’s still manageable from one place in our case. We originally had all solutions under single product but as we grow and also retain a lot of freedom in how teams/squads manage delivery, our sidebars were insanely cluttered and became unusable. 

It’s always tricky to manage shared areas that are in multiple places of your product or fulfil multiple JTBDs, e.g. editor, APIs. We iterate on how these overlapping areas are reflected in the organization/ownership as well as product hierarchy. The best I can advise is to clearly agree what goes where and who are the interested parties to talk to as it may impact them too. 

@Kami i have another question for ya, we’re contemplating to start using timeframes. What we have done before if a feature was considered for a Q2-Q3 period, we would set 2 quarterly releases for it which then shows up in roadmap views etc. What we’ve seen is that our revenue team will just communicate that this is Q2 instead of communicating it is Q2-Q3 timeline. So we were considering timeframe as a replacement to avoid maintaining both which is a bit of an overhead considering we have another release for monthly as well. 

Wondering how you use timeframe at productboard ?

very insightful thx :) i might just get inspired by that. you should have a productboard AMA / Office hours - ppl join and ask question how productboard does things :) 

@scott.baldwin ideas ^ 😜

ohhhh nice thx

thanks folks

Hi @Jerome, 

JTBD and Solution mapping is something that helps us a lot and drives even how our teams get organized. While JTBDs remain pretty stable, Solutions evolve reasonably quickly and even the mapping changes a bit over time but not very much. The representation in PB isn’t natively supported but you can workaround with description mentions, tags or custom fields. 

For prioritization we like to start with the company vision and strategy and based on that we identify objectives we want to achieve. Depending on the objective framing, we look for opportunities among both solutions or JTBDs. Obviously, some objectives are more solutions or JTBD centric. 

Hope this helps, 

Kami