top of page

Data Work Isn’t Project Work.It’s Product Work

    Split scene showing conveyor belt with papers on left, people working at desks with screens on right. Cool blue and warm orange tones.

    Most companies still treat data work like a project.


    You gather requirements. You scope the work. You assign timelines and milestones. You define “done” as a completed dashboard, data pipeline, or platform rollout.


    And then… nothing happens.


    Or worse, the business doesn’t use what you’ve delivered. You hear “thanks,” maybe even “great job,” but the adoption just isn’t there.


    That’s because most data projects stop short of what actually matters: making a real difference in how the business works.



    Projects are built to be finished. Products are built to be used.


    When you shift from project thinking to product thinking, everything changes:

    • You start small and evolve.

    • You prioritize adoption over delivery milestones.

    • You co-create with the business instead of handing off requirements.

    • You measure success based on outcomes, not output.


    Here’s the core difference:

    Projects

    Products

    Requirements-focused

    Needs-focused

    Focused on deliverables

    Focused on adoption

    Completed when scope is delivered

    Evolve based on feedback

    Success = on time, on budget

    Success = used, useful, trusted

    Built by a delivery team

    Co-created with the business

    Managed through timelines

    Managed through feedback loops

    Fixed plan and scope

    Iterative and adaptive

    Learning happens upfront

    Learning happens continuously

    Pauses for change requests

    Adapts in motion. Momentum never stops

    “Did we build it?”

    “Is it making a difference?”


    Real-world example: defining vs. evolving


    In project mode, a team might spend weeks gathering requirements upfront, trying to capture every detail.


    Once those are locked in, delivery begins and if anything changes, it’s a change request.


    In product mode, you treat your first delivery as version 1. You work with the business to prototype quickly, test ideas, get feedback, and adapt as you go. No change request needed — just momentum.


    The outcome? You learn faster, build better, and increase the chances that your solution actually gets used.



    What product thinking looks like in data


    At Fuse Data, we use a operating model called "Define to Deliver", which is built around product principles:


    • Define: We start by understanding needs, not just capturing requests.

    • Align: We prioritize based on value, readiness, and impact, not just stakeholder urgency.

    • Design: We sketch, test, and refine solutions before building.

    • Deliver: We support adoption, measure impact, and improve over time.


    The goal isn’t just to deliver a feature.


    It’s to create something that actually lands.



    Final Thought


    Projects end when the timeline does.

    Products evolve until they stop being useful.


    If you want your data work to make a lasting impact, don’t just treat it like a project.


    Treat it like a product.



    At Fuse, we believe a great data strategy only matters if it leads to action.


    If you’re ready to move from planning to execution — and build solutions your team will actually use — let’s talk.


    From Project to Purpose – How One Story Transformed Our Data Modernization Journey

      Five people in a meeting room discuss data on a giant screen. The setting is modern and bright, with blue and orange tones, showing charts.

      When you’re deep in the weeds of a technical project, it’s easy to lose sight of the bigger picture.


      You’re sorting through legacy code, cleaning up mappings, rewriting stored procedures, and solving problem after problem. It’s important work, no question, but it can start to feel abstract.


      Detached.

      Like you’re solving puzzles in isolation.


      That’s exactly where my team and I found ourselves during a recent data modernization project.


      We were tasked with moving a major enterprise off a legacy data platform and onto a modern, cloud-based stack. The system we were replacing had been in place for nearly 20 years. It was a patchwork of overlapping reports, hand-coded ETLs, and tightly coupled logic that had grown alongside the business in all the worst ways. Our job was to unravel it, salvage what still worked, and build something scalable and future-ready.


      If you looked at our project plan, you’d see all the usual suspects:


      ✅ Migrate reports

      ✅ Rebuild pipelines

      ✅ Clean up technical debt

      ✅ Improve performance

      ✅ Reduce cost

      ✅ Unlock new use cases


      All of it was true. All of it was necessary.

      But none of it felt particularly inspiring.

      And that’s how the work was going. It was technically solid, but emotionally flat.


      The team was grinding through the backlog, hitting targets, solving blockers. But something was missing. The work lacked emotional texture. It was just work.


      Until one meeting changed everything.



      A Story from the Field


      It was the first time we were given the go-ahead to engage directly with the business.


      (As a rule, I prefer to start with the business and work back to the technology. But this was a politically sensitive environment, and business users had been kept at a distance early on.)


      Our first conversation was with the VP of Sales, and within minutes, everything shifted.


      She didn’t start with requirements. She told us a story.


      The night before, she was picking up her daughter from dance class. Around 7 PM, her sales dashboards finally refreshed — late, as usual.


      She noticed an odd dip in revenue.

      At the same time, she got an email from the CEO asking for more detail.


      So there she was, parked outside the studio, laptop open, firing off emails to her regional directors. Some were finishing their day. Others were getting ready for bed.

      After nearly an hour, they traced the issue to a store closure that hadn’t been properly reported.


      The root problem? The data loads were just too slow.

      Not broken. Not unreliable. Just too delayed to support how the business operated today.


      Because of that lag, sales leaders were stuck chasing down answers after hours, instead of handling issues during the workday.


      That story hit home.


      Suddenly, our work wasn’t just about faster queries or cheaper infrastructure.


      It was about making sure someone didn’t have to work from a parking lot.

      It was about giving people their evenings back.

      It was about letting leaders focus on running their teams instead of tracking down anomalies at night.


      That became our “why.”



      When You Know the Why, the Work Changes


      After that meeting, the energy in our team changed.


      We weren’t just building a platform.

      We were creating peace of mind.

      We were enabling focus.

      We were giving people space to do their jobs well and then go home and be present.


      Once a team sees that connection between their effort and a real human outcome, everything improves.


      The code gets better. The testing gets tighter. The collaboration gets stronger. Because it matters more.


      Technical work is never just technical.

      It always touches someone’s day, their schedule, their stress levels, their ability to do great work.


      Find that person. Hear their story. Share it with your team.


      Because when you understand the why behind the work, the project becomes a mission.

      And that’s when great things happen.



      At Fuse, we believe a great data strategy only matters if it leads to action.


      If you’re ready to move from planning to execution — and build solutions your team will actually use — let’s talk.


      Choosing a Data Tool? It’s Not Just About Features and Price

        Five people in a meeting room discuss data on a giant screen. The setting is modern and bright, with blue and orange tones, showing charts.

        Over the last 20 years, I've run more than 100 technology evaluations (some formal, some informal) and one thing has become clear:


        In mature markets like data and analytics, it’s rarely just about features anymore.

        Vendors in this space tend to converge over time. The must-have features stabilize.


        Everyone starts checking the same boxes. And while feature fit still matters, it’s no longer the whole story.


        Here are three other things I’ve learned to pay attention to and things that often get overlooked but can make or break your implementation.



        1. What’s the vendor’s origin story?


        Like any good Marvel hero, every vendor has an origin story.


        Some started as on-prem players and have since pivoted to the cloud. Others were cloud-native from the start. Understanding where they came from and why tells you a lot about where they’re going.


        If you’re looking at a legacy vendor with a new cloud offering, ask:

        • What drove the pivot?

        • How are they planning to support both products?

        • What’s the revenue split between legacy and modern platforms?

        • How are they balancing technical debt reduction vs innovation?


        If most of their business is still tied up in the legacy product, there’s a good chance that’s where their focus will stay. That’s not a deal-breaker, but it’s something you want to know now, not 12 months into a 3-year contract.



        2. Where are they going next?


        Roadmaps aren’t guarantees, but they are signals.


        Ask the vendor:

        • What bets are you making over the next 12–18 months?

        • Are you doubling down on a particular capability?

        • Are you adding a companion product?

        • Are there major feature overhauls on the horizon?


        You want to see if their vision aligns with yours. If you’re both heading in the same direction, great. If not, it’s better to find out now while you still have options.



        3. Will this fit with your team?


        This is the one that often gets skipped and it’s the one that matters most in the long run.


        Every software choice is also a people choice. You’re not just buying a tool. You’re asking your team to adopt it, use it, and support it day-to-day.


        So ask yourself:


        Does this match our skillset?

        Are we a dev-heavy team that prefers code-first tools? Or do we need low/no-code options?


        Does it align with our current stack?

        Are we a Microsoft shop looking at introducing Looker or Qlik?


        Does it fit our team’s appetite for change?

        Are they feeling stuck and eager for something new?


        If your team is excited to learn and frustrated with your current stack, now might be the right time to introduce something different. But if the new tool requires a big cultural or technical shift, you need to plan for that or risk rejection.



        Final thought


        Every vendor has a deck of features and a polished demo. But adoption happens in the real world with your team, your tools, your constraints.


        So by all means, vet the features. Compare the pricing. Make sure it checks the boxes.


        But also ask: does this fit our story?


        Because a great tool that doesn’t land with your team… won’t deliver much at all.



        At Fuse, we believe a great data strategy only matters if it leads to action.


        If you’re ready to move from planning to execution — and build solutions your team will actually use — let’s talk.


        2345
        fuse data logo
        bottom of page