nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Idea / Brainstorming: Designing a Single Source of Truth for Product Data in Wrike

Alexzander Hernandez Cruz

I’m exploring a longer-term idea for how we could structure product information in Wrike and would be interested in hearing how others have approached something similar.

The overall goal would be to create a single source of truth for our product portfolio, where key information about each project/product is maintained in a consistent, centralized structure. Depending on the project, this could include information such as:

Project/product type and current stage or tollgate
Innovation or strategic classification
Financial metrics and projections
Resource intensity
Technical risk
Relevant employee/role information
Expected and actual launch dates
Other key product and project attributes

One question I’m trying to work through is how best to structure this information within Wrike.

Would it be better to have one centralized database/data structure containing all of the relevant fields for each product, or would it make more sense to separate the information into logical areas (for example, financials, resources, product information, etc.in separate databases) while maintaining relationships between them?

My initial thinking is that a centralized source of truth could have some significant advantages. For example, if a financial value, launch date, project status, or other attribute changes, that information could potentially flow through to the appropriate reports, dashboards, project folders, and other views rather than having the same information maintained in multiple places.

This could also make reporting more scalable over time and reduce the risk of different teams or reports referencing outdated versions of the same information.

I’m curious how others would approach the data architecture and organization for something like this in Wrike. Are there best practices around when to use one centralized structure versus multiple related structures? Are there particular considerations around reporting, custom fields, relationships, or maintaining a single source of truth that I should be thinking about before designing it?

This is still very much in the idea/brainstorming stage, so I’d especially appreciate perspectives from anyone who has built a similar portfolio or product-data structure in Wrike.

Find more posts tagged with

datahub

project-tracking

use-cases

Project Management

Comments

Janelle Tyler

This is a really interesting idea, @Alexzander Hernandez Cruz! My instinct would be to establish one centralized product record as the source of truth for the core information that should only exist once, such as product type, stage, status, launch dates, strategic classification, and other key attributes. Then I’d use Wrike’s different views, dashboards, reports, and project structures to surface that information where it’s needed rather than maintaining duplicate versions of it.

For more specialized information, like detailed financials or resource data, I could see value in keeping those in separate but related structures, especially if they have their own workflows, owners, or reporting requirements.

I think the biggest question I’d ask when designing it is: Who owns each piece of data, where is it updated, and how do we make sure it only needs to be updated once? If that’s clear from the beginning, it seems like it would go a long way toward creating a true single source of truth.

I’d be really interested to hear how others have structured something like this in Wrike too!

Alexzander Hernandez Cruz

@jtyler81 Thank you for the insight! This helped give me a clearer vision of how I want to approach building this out. I really appreciate you taking the time to share your perspective.

Sherrie Besecker

HI! I think if this is more a "dataset" then yes - a database would be a great idea - that way it is the single source of truth… If you are thinking more like a repository of different items (things with assets, guides, links and more) - you might think about setting up a space that is public and references all this (kind of like make it a Sharepoint location) - that way you can leverage both database and house other important items there too!

John_Egleston

@Alexzander Hernandez Cruz I applaud your systematic approach to this effort. @jtyler81's suggestions are right on. My most relevant experience was in a previous org helping manage technology products we used or developed.

There we kept high-level product definition data (name, product owner, description, website/s, internally developed or externally purchased, vendor, vendor owner, next contract renewal date, etc.) in another platform and didn't integrate that directly with Wrike. In Wrike Enterprise (no access to Databases f.k.a. Data Hub) we had

A central product space for consolidated request intake form and views of backlogs, roadmaps, and sprints.
Each major product/platform had its own space with its backlog, roadmap projects, and sprints (often shared between related products).
The intake form and a custom item type (product-related request) used the product names in a custom field to route and track requests through their various spaces.

Your approach - if you have Pinnacle - can be more elegant. We added maybe a product or two per year, so the manual configuration was sustainable. We also didn't press far upstream into product ideation. Good luck and glad to interact more!

Later: Now I see @Sherrie Besecker's suggestion. If you use Wrike alongside Microsoft 365, I recommend the SharePoint integration so that serves as a single point of truth for persistent files (i.e., not ephemeral screenshots of errors), both internal and potentially external.

Alyssa Spangenberg

A database sounds like the perfect solution. Although, my first question would be whether or not you have Pinnacle and that option. Assuming you do, I'm actually not opposed to the idea of separating out into multiple databases. BECAUSE, you can link info between databases and also pull that information into custom fields so having one more layer of organization certainly wouldn't hurt. Especially if only certain people should be editing certain information. This can help prevent errors and create smaller, easier to manage databases for teams. Databases in my option are so much like excel that i don't find them that fun to navigate for information. Dashboards are created for this reason. The filtering has gotten even better to create dashboards powered by projects and initiatives instead of sifting through lines of data.

Alexzander Hernandez Cruz

Hello @Alyssa Spangenberg , I totally agree with you that's why I am purposing this idea because once a single source of truth is established everything downstream such as dashboards, reports and folders will ideally hold the correct information. Also, yes this is for Pinnacle. Thank you for the insight!