How to structure cross-product API and integrations features

  • 6 October 2022
  • 3 replies


Hello community,

I’m curious to hear your best practises regarding structuring API and integration topics which span over different products (no product, one product, multiple products) in Productboard. I tried different approaches but I’m not yet happy with the result. What I tried so far:

  • API / Integrations as a new product
    • Pros: flexibility to structure the feature board and roadmap, easy to capture requirements which belong to no or multiple products 
    • Cons: duplicate features because the product teams capture similar requirements in their feature board, missing alignment as product teams work with their own features
  • API / Integrations as a component within each product 
    • ​​​​​​​Pros: single, product-focused view
    • Cons: API structure needs to fit to product structure, duplicate features if integration/API needs to be assigned to more than one product, not easy to filter only the API specific content for feature board and roadmaps

Moreover, I want to distinguish API and integration requirements on business level (which scenarios?) as well as the technical level (which technical integration / API development), which makes the scenario even more complex. Currently: Business Level = component, concrete integration = feature

Any advice is highly appreciated!


Thank you


3 replies

Userlevel 7
Badge +13

Hi @Manuel Taechl,

I just noticed that no one replied to your post, so jumping in with some thoughts.

Overall I think there are a number of options, as you pointed out, with various pros/cons. I’ve seen both done. I will not that there is no one right way.

What I might suggest is joining one of our office hour calls to chat with our team some more about your particular situation. There's a session coming up next week on October 27 (Europe and North America). You may also find it helpful to watch our training on hierarchies. There’s a good on demand one about building the right hierarchy as well as a deep dive session.

Userlevel 6
Badge +12

@Manuel Taechl -- There are some pros and cons to both ways you’ve mentioned that you approached with outlining API development/growth in Productboard. Another thing to take into consideration is how your team(s) handle these stories and what the purpose of presentation will be when adding these features  to Productboard. 

We’ve recently been working out our API development in a similar way and we generally approach it with the “API as a Product” perspective. While there are going to be overlapping features, but you may want to approach it from the use-case perspective. The cross-platform boards can be used to capture use-cases per-component/product while you can use that to empower the “API as a Product” board around feedback and discovery. 

I do think it would be beneficial to watch the “Building the Right Hierarchy” on-demand video that Scott linked - it does contain some meaningful advice as to how to approach the pros and cons. 


@scott.baldwin @david.morgan thank you very much for sharing your thoughts! I will definitely have a look at the proposed content! Furthermore, we are currently in touch with some experts from Productboard to improve the adoption of Productboard. We also discussed my requirements in one of the calls.