Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Gooddata-Data_Products__What_They_Really_Are__A...

Avatar for Marketing OGZ Marketing OGZ PRO
September 17, 2025
1

 Gooddata-Data_Products__What_They_Really_Are__And_How_to_Build_Them_Right_.pdf

Avatar for Marketing OGZ

Marketing OGZ PRO

September 17, 2025
Tweet

More Decks by Marketing OGZ

Transcript

  1. Ryan Dolley VP of Product Strategy at GoodData Host of

    Super Data Brothers show superdatablog.substack.com Today’s Host Connect with me on LinkedIn!
  2. GoodData: The analytics product platform Flexibility Embed data anywhere Simplicity

    Custom experience for every user Productivity Accomplish more with code Scalability Scale to your organization's needs
  3. According to Jean-Georges Perrin A data product is a reusable,

    active, and standardized data asset designed to deliver measurable value to its users — whether internal or external — by applying the rigorous principles of product thinking and management. It comprises one or more data artifacts (e.g., datasets, models, pipelines) and is enriched with metadata, including governance policies, data quality rules, data contracts, and, where applicable, a Software Bill of Materials (SBOM) to document its dependencies and components. Ownership of a data product is aligned to a specific domain or use case, ensuring accountability, stewardship, and its continuous evolution throughout its lifecycle. Adhering to the FAIR principles — Findable, Accessible, Interoperable, and Reusable — a data product is designed to be discoverable, scalable, reusable, and aligned with both business and regulatory standards, driving innovation and efficiency in modern data ecosystems. JGP, Sr. Product Manager at Actian & Technical Chair of BITOL project
  4. According to Anna Bergevin Anna Bergevin, Lead Product Manager at

    Resmed A product has product thinking. A product has clear lines of ownership, particularly if not all components are owned by the same team A product has robust engineering under it - quality tests, observability, version control, etc A product has strong product market fit and must be under continuous monitoring for usefulness and evolution.
  5. Do you currently build ‘data products’ and if so, what

    are they? How did you decide to take this approach? Is it working or not? And why? What do you think?
  6. 1. Start with the job, not the data 2. Design

    the interface first 3. Ship and MVP and iterate fast 4. Engineer like software, not BI 5. Performance is a feature 6. Ship to where work is done Design principles
  7. 1. Ignoring product principles 2. Just renaming your existing assets

    to ‘data products’ 3. Starting with tools and tech instead of user experience 4. ‘Self-service’ as an excuse for skipping design/front end 5. Building a giant monolith 6. Fear of deprecation 7. Rigid thinking and the need for definitions Common mistakes