How Productboard uses Productboard


Userlevel 4
Badge +1

I enjoyed the presentation about how Productboard used Productboard in Product Makers Summit. I love the problem vs solution split.

I am curious to learn more and have some questions:

  • Are insights being tagged to things in problems only?
  • 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
  • Productboard has different areas of focus (or if we want to label then as “modules”). Is everything under solutions based on components reflecting that or also JTBD components, because I saw in the video things like API etc.

14 replies

Userlevel 7
Badge +12

@Cberman @Sophie Lalonde care to share some thoughts/comments?

Userlevel 3
Badge

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.
Userlevel 4
Badge +1

Thanks @Kami this is great. I believe you answered my 3rd question. So if I understand this right you have one JTBD Product for all the solutions you have that captures all customer problems + one product for each solution you have (features, roadmap etc.)? Is that correct?

 

Reason why I am asking is that while we have a couple of independent solutions but one common thing is that they need to be configured through our dashboard which also has its own features etc. So I always find it weird when we have to break things or move things around in the hierarchy. Although we did try a “Common Components” product but that didn’t really work well for us.

Userlevel 3
Badge

@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. 

Userlevel 4
Badge +1

Thanks this has been very helpful :) 

Userlevel 4
Badge +1

@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 ?

Userlevel 3
Badge

@Samkay I’m a big fan of timeline roadmaps personally, it makes it easier to manage the roadmap across multiple teams. Our main high-level roadmap is objectives on timeline. 

For more tactical purposes some teams, including mine, also use release based roadmaps. To make sure things are in sync I keep a private feature board view, which is organised by release and has timeline column. I review it each week so that I don’t need to open each feature sidebar. 

Userlevel 4
Badge +1

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 ^ 😜

Userlevel 7
Badge +12

@Samkay we have a few sessions planned in that space around some upcoming themes. In the meantime you might enjoy our Academy on-demand content about how Productboard uses Productboard https://academy.productboard.com/on-demand-webinar-how-productboard-uses-productboard/1144657

Userlevel 4
Badge +1

ohhhh nice thx

Userlevel 7
Badge +12

And there are regular weekly office hours as well in both North America and EMEA available on the academy https://academy.productboard.com/page/training-webinars

Userlevel 4
Badge +1

thanks folks

Badge

Hi @Kami @Samkay,

Thanks for this thread! Those are very interesting thoughts and comments.
I’m wondering how do you link the JTBD to the different solutions?

Also, do you prioritise both JTBD and solutions?

Thanks!

Userlevel 3
Badge

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 

Reply