The Data Journey

Roland Brown

The Data Journey: Big Ideas, Small Time Looking to stay ahead in data architecture, education strategy, and leadership—but short on time? The Data Journey delivers actionable insights in under 10 minutes, weekly. Each episode is designed for busy professionals: quick, practical, and easy to apply. No fluff, no filler—just the strategies and frameworks you need to make smarter decisions, faster. Subscribe to the newsletter at www.thedatajourney.com and transform your coffee break into a mini-masterclass in modern data and leadership.

  1. Episode 69: Killing Bad Data Products: Sunsetting Properly

    1 DAY AGO

    Episode 69: Killing Bad Data Products: Sunsetting Properly

    Most organisations are very good at building data products.They are far less good at stopping them. In this episode, Roland Brown tackles one of the most uncomfortable yet essential capabilities of mature data organisations: sunsetting data products properly. Building directly on the failure modes discussed in Episode 68, he explains why keeping bad or outdated data products alive quietly damages trust far more than removing them. Roland shows that most data products don’t linger because they are still valuable they linger because organisations avoid difficult conversations. “Someone might still be using it.” “We might need it later.” “It took effort to build.” These well-intentioned hesitations result in products that are neither alive nor dead, creating ambiguity, confusion, and false confidence. The episode reframes sunsetting not as deletion or failure, but as a deliberate lifecycle stage one that was already implied in the anatomy of a good data product introduced in Episode 62. Products are born, they mature, they evolve and eventually, they should retire. Roland outlines the clearest signals that a data product should be considered for retirement: • The decision it supported no longer exists• Trust has eroded to the point of constant validation• No one is willing to own the outcome• A clearer, better product has replaced it None of these are failures. They are signals of change. The episode then walks through what responsible sunsetting actually looks like in practice: • Making the decision explicit instead of letting decay continue• Identifying who is still impacted and how• Providing a clear replacement or exit path• Running a managed transition period• Retiring interfaces cleanly and visibly Roland explains why silent decay is far more dangerous than visible retirement. Products that quietly rot teach consumers that data products can’t be trusted not just the bad ones, but all of them. A practical revenue example illustrates how sunsetting, when done transparently, actually increases confidence rather than disrupting it. Consumers know where to go, what to use, and what no longer applies. The episode closes with a powerful maturity signal:healthy data ecosystems are not defined by how many products they have but by how confidently they can let go of the ones that no longer serve decisions. Sunsetting is not an admission of failure.It is an act of respect for consumers, for clarity, and for trust. Discover insights on: • Why bad data products linger longer than they should• The hidden cost of keeping outdated products alive• How to recognise when a product should be retired• Why sunsetting is a lifecycle capability, not cleanup• What responsible, low-risk retirement actually looks like• How killing bad products strengthens the entire ecosystem “A product you’re afraid to killis a product that’s already dangerous.” 🎧 Listen to The Data Journey wherever you get your podcasts, or visit thedatajourney.com

    7 min
  2. Episode 68: Why most data products fail

    4 DAYS AGO

    Episode 68: Why most data products fail

    Most data products don’t fail because the data is wrong.They fail because the conditions required for trust, accountability, and value were never designed in. In this episode, Roland Brown confronts an uncomfortable reality: despite modern platforms, sophisticated pipelines, and well-intentioned teams, most data products still fail to deliver lasting value. Building directly on Episodes 64 through 67, he explains why these failures are rarely dramatic and almost always avoidable. Roland shows that data product failure rarely looks like an outage or a rollback. Instead, it shows up as slow erosion: declining trust, growing workarounds, duplicated logic, and products that technically exist but are no longer relied on. The episode walks through the most common failure modes seen in practice: • Starting with artefacts instead of decisions• Assigning ownership without real authority• Treating trust as a feature instead of infrastructure• Measuring activity instead of confidence• Turning everything into a “product”• Ignoring lifecycle and sunsetting altogether Each failure mode is connected back to earlier episodes in the series, revealing how skipping even one foundational principle consumer-first design, ownership, contracts, or honest measurement quietly undermines everything else. Roland explains why many data products survive on paper long after they’ve failed in practice. They aren’t removed, because no one wants to admit failure. But by lingering, they actively damage the wider ecosystem teaching consumers that data products cannot be trusted. A key insight of the episode is that motion is often mistaken for value. Teams continue delivering pipelines, dashboards, and enhancements, while confidence continues to fall. Without anchoring products to decisions and behaviours, delivery becomes theatre. The episode reframes failure as a design signal rather than a maturity problem. Data products fail when clarity is avoided when teams hesitate to commit to intent, ownership, contracts, measurement, or endings. Roland closes with a critical reminder:most data product failures are not caused by lack of skill, tooling, or effort they are caused by the absence of deliberate design choices. When those choices are made explicitly, failure becomes preventable. Discover insights on: • Why data product failure is usually quiet, not visible• The most common and preventable failure modes• How trust erodes long before usage drops• Why over-productisation damages ecosystems• How ignoring lifecycle guarantees decay• Why clarity not complexity determines success “Data products don’t fail because data is hard.They fail because clarity is avoided.” 🎧 Listen to The Data Journey wherever you get your podcasts, or visit thedatajourney.com

    8 min
  3. Episode 67: Measuring Data Product Success: Reuse, Adoption, and Trust

    6 DAYS AGO

    Episode 67: Measuring Data Product Success: Reuse, Adoption, and Trust

    Most organisations measure their data success by how much they build.Pipelines delivered. Tables published. Dashboards created. And yet, trust still erodes, duplication spreads, and decisions remain slow. In this episode, Roland Brown challenges one of the most entrenched habits in modern data teams: measuring activity instead of value. Building on the foundations laid in Episodes 64, 65, and 66, he explains why traditional data metrics often create the illusion of progress and why real data product success shows up in behaviour, not dashboards. Roland makes a clear distinction between usage and reliance. A data product can be queried frequently and still not be trusted. It can be reused widely and still be reinterpreted every time. When teams measure volume instead of confidence, failure hides behind busy charts. The episode introduces three signals that consistently reveal whether a data product is actually succeeding: • Adoption are the right consumers using the product to make real decisions?• Reuse is the product reducing duplication and rework, or just feeding more downstream variations?• Trust do consumers rely on the product without validation, disclaimers, or reconciliation? Roland explains why adoption is often a lagging indicator and why trust-related behaviours like increased validation, shadow calculations, and side-channel confirmations are some of the earliest signs that a product is in trouble. Drawing on the product anatomy discussed in Episode 62, he shows how success metrics change when data products are treated as long-lived capabilities instead of one-off deliveries: • Adoption aligns to decision cadence, not query counts• Reuse is measured by work eliminated, not consumers added• Trust reveals itself when products are used without hesitation A practical example demonstrates how two products with similar usage statistics can have radically different outcomes one stabilising decisions and the other quietly creating more work depending on whether trust is present. The episode also addresses a common leadership mistake: assuming that low adoption means more training is needed. Roland explains why adoption problems are almost always design or trust problems, not education problems — and why better metrics often reveal uncomfortable truths about ownership, contracts, and intent. The episode closes with a reframing that ties the entire data product arc together:data products do not succeed because they are visible they succeed because they are relied on. When adoption, reuse, and trust are measured honestly, teams stop optimising for output and start optimising for confidence. Discover insights on: • Why activity metrics hide data product failure• The difference between usage and reliance• How to measure reuse without incentivising duplication• Why trust is the most honest and quietest success signal• How behaviour reveals value long before dashboards do• What leaders should measure if they actually care about outcomes “You don’t measure data products by how often they’re touched.You measure them by how rarely they’re questioned.” 🎧 Listen to The Data Journey wherever you get your podcasts, or visit thedatajourney.com

    8 min
  4. Episode 66:Data contracts in practice (not theory)

    2 FEB

    Episode 66:Data contracts in practice (not theory)

    Most organisations don’t lose trust in data because of bad intentions or poor tooling.They lose trust because expectations are implicit, undocumented, and constantly shifting. In this episode, Roland Brown takes one of the most talked about and least understood concepts in modern data architecture and brings it firmly down to earth: data contracts. Building on the ownership and accountability foundations laid in Episode 65, he explains why trust does not emerge organically in complex data environments and why contracts are the mechanism that makes trust operational. Roland challenges the common misconception that data contracts are a technical artefact or a schema enforcement tool. Instead, he reframes contracts as explicit agreements between producers and consumers agreements about meaning, quality, freshness, availability, and change. Without these agreements, even well-owned data products slowly decay into ambiguity and workarounds. The episode explains how most organisations already have implicit contracts hidden in Slack messages, tribal knowledge, and one-off explanations and why making those expectations explicit is the difference between fragile trust and reliable confidence. Roland walks through what a practical data contract actually includes: • what the data represents not just its structure• which decisions it supports• how fresh it is expected to be• what “good enough” quality means in context• what happens when expectations are not met• how changes are communicated and versioned Crucially, the episode makes clear that contracts are not about rigidity or perfection. They are about predictability. Consumers do not need flawless data they need to know what they can rely on, when, and why. Drawing on Episode 62’s product anatomy, Roland shows how contracts strengthen every component of a data product: • Intent stops being aspirational and becomes enforceable• Ownership becomes real because expectations are explicit• Semantics stabilise because definitions are agreed, not inferred• Quality shifts from abstract targets to decision-level fitness• Interfaces become safer because usage expectations are clear• Lifecycle management becomes possible because change is governed A practical example illustrates how revenue data without contracts leads to endless reconciliation, duplicated logic, and mistrust while the same data, under a clear contract, becomes a stable input into forecasting, reporting, and compliance decisions. The episode also addresses a common fear: that contracts will slow teams down. Roland explains why the opposite is true. By reducing interpretation, clarification, and rework, contracts actually accelerate delivery and adoption while protecting consumers from silent breaking changes. The episode closes with a powerful reframing:data contracts are not bureaucracy they are care.Care for consumers.Care for decisions.Care for trust over time. When contracts are explicit, trust stops being personal and starts becoming systemic. Discover insights on: • Why trust cannot be scaled without explicit expectations• What data contracts really are beyond schemas and tooling• The practical components of a usable data contract• How contracts protect both producers and consumers• Why predictability matters more than perfection• How contracts make ownership and accountability real “Trust doesn’t come from knowing who to ask.It comes from knowing what to expect.” 🎧 Listen to The Data Journey wherever you get your podcasts, or visit thedatajourney.com

    8 min
  5. Episode 65: Ownership Models: Who Is Accountable for Value?

    30 JAN

    Episode 65: Ownership Models: Who Is Accountable for Value?

    Most organisations don’t struggle with data because they lack platforms, pipelines, or tooling.They struggle because no one is truly accountable for the value their data is supposed to create. In this episode, Roland Brown tackles one of the most misunderstood and quietly destructive aspects of modern data product thinking: ownership. Building directly on Episodes 60 through 64, he explores why so many data initiatives stall after delivery, why trust erodes over time, and why value disappears even when the data is technically sound. Roland explains that many organisations claim to have “owners” for their data products but what they really have are custodians of pipelines, tables, or dashboards. When ownership is defined around assets instead of outcomes, accountability becomes fragmented, decisions slow down, and responsibility evaporates the moment something goes wrong. The episode breaks down the most common ownership models seen in practice: • platform-owned data• centrally governed data• engineering-owned outputs• domain-owned products and explains why only one of these reliably scales value. A critical distinction is introduced between being responsible for data and being accountable for decisions enabled by data. Roland shows how true data product ownership means standing behind definitions, quality trade-offs, prioritisation, and change not just delivery milestones. Drawing on earlier episodes, he connects ownership directly to the anatomy of a data product introduced in Episode 62: • Intent becomes enforceable only when someone owns the decision it supports• Semantics stabilise when one owner resolves ambiguity• Quality becomes contextual when owners understand how data is actually used• Interfaces improve when owners feel the pain of poor consumption• Lifecycle management becomes possible when someone can say “this no longer delivers value” The episode also confronts a hard truth: shared ownership often means no ownership. When accountability is spread across committees, centres of excellence, or “the data team,” products survive technically but fail operationally. Consumers compensate with workarounds, shadow logic, and parallel definitions slowly draining trust from the system. A practical ownership test is introduced:When this data product causes harm not just inconvenience who gets the call? If the answer is unclear, the product doesn’t truly have an owner. Roland grounds the discussion with familiar examples from revenue, customer, and risk domains, showing how ownership models directly influence whether data products are trusted inputs to decisions or merely optional references. The episode closes with a reframing that sits at the core of product-oriented data organisations:ownership is not about control — it’s about accountability for outcomes.When someone is clearly accountable for the value a data product is meant to deliver, trust becomes durable, decisions accelerate, and platforms finally start paying for themselves. Discover insights on: • Why asset ownership is not the same as product ownership• The most common ownership models and where they fail• How accountability shifts when decisions come first• Why shared ownership often destroys trust• How ownership connects directly to data product anatomy• A practical test to identify whether your products are truly owned “Pipelines have operators.Platforms have administrators.Data products need owners who are accountable for value." 🎧 Listen to The Data Journey wherever you get your podcasts, or visit thedatajourney.com

    9 min
  6. Episode 64: Designing Data Products for Consumers, Not Producers

    27 JAN

    Episode 64: Designing Data Products for Consumers, Not Producers

    Most organisations don’t fail at data because of poor engineering or weak platforms.They fail because they design data products for the people who build them not the people who depend on them. In this episode, Roland Brown tackles one of the quietest but most damaging design mistakes in modern data teams: producer-first data product design. Building on the foundations laid in Episodes 61, 62, and 63, he explains why many technically sound, well-engineered data products still struggle with adoption and why that failure is almost always a design outcome, not a behaviour problem. Roland shows how producer-first thinking creeps in through reasonable but misordered questions: schema first, pipelines first, reuse first. He explains why starting from data instead of decisions leads to generic, broad products that rely on tribal knowledge and constant interpretation eroding trust even when the data is “correct.” The episode introduces a clear shift in perspective: consumer-first design. Instead of starting with data availability or platform convenience, consumer-first products are designed backwards from decision, to question, to signal, to interface, and only then to data. This shift forces commitment, clarity, and accountability the very traits that separate assets from products. Roland connects this directly to the anatomy of a good data product introduced in Episode 62, showing how consumer-first design sharpens every component: Intent becomes specific instead of vagueOwnership moves from pipelines to decision outcomesSemantics become explicit rather than assumedQuality becomes contextual instead of abstractInterfaces become intentional instead of exhaustiveLifecycle becomes real, not theoreticalA simple but powerful test is introduced:If this product disappeared tomorrow, who would notice first?The answer reveals whether something is truly designed for consumers or quietly maintained for producers. A practical revenue example brings the concept to life, demonstrating how the same underlying data can support multiple consumer-first products each with its own intent, cadence, and interface without sacrificing reuse beneath the surface. The episode closes with a reframing that sits at the heart of modern data product thinking:data products are not artefacts they are commitments. Commitments to clarity, to consumers, and to decisions. When products are designed for the people who rely on them, trust stops being aspirational and starts becoming operational. Discover insights on: Why adoption is a design outcome, not a training problemHow producer-first thinking quietly undermines trustWhat consumer-first data product design really means in practiceHow product anatomy changes when decisions come firstA simple test to identify who your data product is truly forWhy reuse should happen under the surface not at the expense of clarity“Datasets store facts. Reports show views.Data products are commitments to decisions.” 🎧 Listen to The Data Journey wherever you get your podcasts, or visit thedatajourney.com

    9 min
  7. Episode 63: Data Products vs Reports vs Datasets

    22 JAN

    Episode 63: Data Products vs Reports vs Datasets

    Most organisations don’t struggle with data because of tooling or platforms.They struggle because they mix up fundamentally different things and then expect them to behave the same. In this episode, Roland Brown tackles one of the most common and damaging category errors in modern data teams: confusing datasets, reports, and data products. Building on the foundations laid in Episodes 61 and 62, he explains why so many teams believe they have “built the product” when what they’ve actually delivered is a dataset or a dashboard. Roland shows how this confusion leads to fuzzy ownership, inconsistent definitions, fragile reporting, and ultimately low trust. He explains why more pipelines and more dashboards don’t fix the problem and how treating movement as progress quietly traps organisations in delivery theatre instead of value creation. The episode cleanly separates the three concepts: Datasets as reusable ingredientsReports as consumption viewsData products as deliberately designed, supported capabilitiesDrawing on practical experience and ideas commonly referenced in data mesh thinking (including perspectives popularised by Martin Fowler), Roland reframes data products not as artefacts, but as commitments — with intent, accountability, expectations, and lifecycle discipline. He introduces a simple three-test decision framework that teams can immediately apply to determine whether something is truly a data product, or just an asset wearing a product label. A concrete churn example brings the distinction to life, showing how the same underlying data can exist as a dataset, a report, or a trusted product — depending on how it is owned and operated. This episode connects product thinking, data architecture, and operating models, reinforcing a critical idea: definitions are not semantics — they shape behaviour. When language is clear, expectations are clear. And when expectations are clear, trust becomes possible. Discover insights on: Why datasets, reports, and data products are not interchangeableHow category confusion undermines trust and accountabilityWhy reports should rarely be treated as sources of truthThe three tests that reveal whether something behaves like a productHow intent, ownership, and expectations separate value from inventory“Pipelines move data. Reports show information.Data products are what people can rely on.” 🎧 Listen to The Data Journey wherever you get your podcasts, or visit thedatajourney.com.

    9 min
  8. Episode 62: The Anatomy of a Good Data Product

    19 JAN

    Episode 62: The Anatomy of a Good Data Product

    Most organisations don’t fail at data because of technology.They fail because what they build isn’t designed to be used. In this episode, Roland Brown breaks down the anatomy of a good data product and explains why simply adopting the language of “data products” doesn’t automatically lead to trust, adoption, or value. Building on the foundation set in Episode 61, he moves from definition to design, unpacking what must exist for a data product to survive in practice, not just on slides. Roland explores why treating data products as abstract ideas leads to confusion and fragmentation, and why clarity at the component level is what separates real products from accidental data assets. He walks through the core elements every effective data product needs from clear intent and ownership, to shared semantics, reliability, interfaces, and lifecycle discipline. The episode connects product thinking, data architecture, and operating models, showing how trust is designed, not assumed, and why predictability matters more than perfection. From meaning before metrics to interfaces that remove guesswork, Roland reframes data products as living assets that require care, accountability, and intentional design. From pipelines that move data to products that enable decisions, this episode explains why anatomy matters and why missing components quietly undermine even the most modern platforms. Discover insights on: What makes a data product “good” in practiceWhy intent and ownership are non-negotiableHow semantics and context prevent confusion at scaleWhy reliability and interfaces drive adoptionHow lifecycle thinking separates maturity from clutter “Pipelines move data. Platforms host data. Products are what people actually use.” 🎧 Listen to The Data Journey wherever you get your podcasts, or visit thedatajourney.com.

    11 min
See All (69)

About

The Data Journey: Big Ideas, Small Time Looking to stay ahead in data architecture, education strategy, and leadership—but short on time? The Data Journey delivers actionable insights in under 10 minutes, weekly. Each episode is designed for busy professionals: quick, practical, and easy to apply. No fluff, no filler—just the strategies and frameworks you need to make smarter decisions, faster. Subscribe to the newsletter at www.thedatajourney.com and transform your coffee break into a mini-masterclass in modern data and leadership.

Information

  • Creator
    Roland Brown
  • Years Active
    2025 - 2026
  • Episodes
    69
  • Rating
    Clean
  • Copyright
    © 2025 Roland Brown

You Might Also Like