Data Projects vs. Data Products — Why Mindset Matters
TL;DR — Projects have a clear definition of what needs to be delivered while products do not. This fundamentally changes how teams are incentivized and what it means to “do work”. This is especially true with most data teams today, where the ticket-taker mentality proliferates. Fortunately, a product-led approach centered around the user is gaining momentum.
Over the past few years, companies have been investing in transforming how they structure teams to harness digital, data and analytics to drive better outcomes for customers. Core to this transformation is a switch from a project-centric mindset to a product-centric mindset.
Distinguishing between a Project and Product mindset is critical to understanding the power of data products. Before diving in, let’s align on terminology… hang in there, it’ll be worth it:
A product is anything that can be offered to a market to solve a problem, or to satisfy a want or need. Products are often designed for personas (archetypal recipient of value) and consist of multiple lifecycle stages at which product value is realized.
On the other hand, a project is a temporary undertaking intended to deliver a clearly defined scope, within budget and on time.
Projects have a clear definition of what needs to be delivered while products do not. Just as customer needs evolve over time, so must the products that serve them.
This draws out the fundamental difference between Projects and Products → the mindset of what it means to “do work”.
Projects → Work = Complete Tasks
Products → Work = Maximize User Value
As we step back and observe, you can begin to appreciate the uniquely challenging and somewhat ambiguous task of building a product. While a project has a clearly defined scope and expectations, products live in this constantly evolving state of defining and designing to maximize consumer value.
Fortunately, the Product Management discipline has provided us with a rich repertoire of strategies and tactics for managing this. More on this later when we dive into the role of the Data Product Manager.
Let me be clear, I am not saying that a project mindset should never be taken. In fact, plenty of work is best approached from this mindset. Work that can be clearly defined with little-to-no ambiguity in the end-state objectives. For example, infrastructure upgrades, systems migrations and change requests would all be candidates for project work.
*It all comes back to managing uncertainty, knowledge and feedback.
In the Project model, the scope is clear — migrate this system, change this payment service etc. On the other hand, in the Product model, the future state is uncertain, driven by the needs of the customer.
To bring order to this ambiguity, there must be a Product Manager to manage and orchestrate the knowledge that is generated throughout the product life cycle. This means coordinating with stakeholders, customers, engineers, designers, etc to build a comprehensive understanding of what the product is meant to be (much more on this later).
A key aspect of this knowledge generation is delivering continuous value to the customer in the form of incremental improvements. Why? Because customer feedback is one of the(if not, the) most effective forms of product intelligence and the sooner you release, the sooner you get feedback. While the scope of what is to be built will change over the life cycle, customer feedback often remains the highest fidelity means of understanding value.
To sum it up, beware of project work that is intended for a customer. There is a good chance the customer’s needs will be forgotten in pursuit of project deadlines. The result is completed projects but a lack of adoption, resulting in little to no realized business value.
Before diving into the role of the Data Product Manager, let’s round out the discussion of Project vs. Product work by understanding the implications of this framing on the data team.
Data Teams of Today → Project oriented ticket takers
Historically, data teams have been buried within the IT function. These teams usually emerged as an afterthought, only after business stakeholders realized that they couldn’t make sense of the increasing quantity and complexity of data.
These data teams are brought on and built up like service-based departments where business stakeholders sponsor projects or submit tickets with specific requests and the data teams work their magic to come up with the answers.
This naturally results in a ticket-taker/task-master mentality, where data teams are measured by the number and speed of tickets closed, not on the value delivered to the customer. This mindset stretches from how they manage and govern data to how they generate reports, conduct data science and so on.
Can we really blame data teams though? Not entirely. Most data teams are abstracted from the customer and many business stakeholders simply see the data team as the masters of the data, rather than partners in defining customer value (In a future post we’ll explore how cross-functional teams can help reframe the data teams role).
This Project-oriented model has many flaws, most notably:
- It incentives for task completion and not customer value
This is a major problem because many businesses fail to become data-driven due to employee(customer) challenges(i.e. — unable to make sense of a dashboard). Many data consumers need a more intuitive experience to sufficiently engage with the data. While the project may be delivered, the value may never be realized. - It squanders the data team’s unique positioning to connect the dots
Data teams are in a unique position to identify patterns within the requests coming across functions. For example; let’s imagine that Jill from marketing wants to know the performance of a persona-centric ad campaign and Mel from Finance wants to know about customer activation this past month. If Rahul, on the data team is simply pulling tickets from the queue, he may never see the broader connection between the two, although he’s the only one in the organization uniquely positioned to do so. - It results in data team dependency and bottlenecks galore
In this model the data team is the gatekeeper to the data and anything needed, from a pretty dashboard to a simple data API, has to go through the data team. This is simply not sustainable in a world where knowledge workers are making hundreds of decisions a day. Instead data consumers need products that are flexible and scalable for their needs, when they need them.
All of this translates to a poor customer experience with slow time-to-delivery and a greater risk of delivering data that is no longer relevant.
Data Teams of tomorrow → Product-led value seekers
Instead of focusing on servicing tickets and tasks, product-led data teams focus on building data products that deliver continuous value to their consumers. While the distinction may seem trivial, I assure you it is not. In the service model throughput scales linearly, whereas the product-led model enables super-linear scale.
Think → a service is one where you are trading time for money while a product is one you are able to sell repeatedly without having to reproduce your effort each time. The same principle applies here, for data.
This approach does exactly what its name implies, it places product principles at the heart of organizational data management. This means adopting a user-centered approach that is laser-focused on driving customer value. This shift in approach has many benefits including:
- Success is measured as a function of impact
In the product-led model, success is not about tickets closed but business value generated. This can be measured in the number and volume of decisions you’re enabling and/or by the quality of those decisions with respect to a KPI. This provides both a clear mandate to the data team as well as a common language to win leadership support for data initiatives (more on this when we discuss the Data Product Manager role). - A deep understanding of consumer problems means better solutions
Deeply empathizing with the consumer to understand their needs and challenges results in solutions that actually get adopted. Simply put, solutions are more likely to get adopted if they are user-friendly and fit within the existing workflows for the user. Data teams often fall short in the “last mile”, where consumers actually derive their value from the data product. Without usage, the entire investment is for naught. - Clear priorities to solve the right problems at the right time
A clear prioritization framework enables data teams to work with different stakeholders around common goals. Without a clear prioritization framework, data teams risk creating underutilized data products(highlighted earlier), resulting in a waste of resources and a lack of perceived value by business stakeholders.
Okay great, so now we’re aligned on the difference between the Project and Product Mindset. We also have a solid understanding how these concepts apply within data teams. Now let’s explore the role of the Data Product Manager to understand how this all comes together.
Have anything useful to share? Please leave them in the comments below and, if they resonate, I’ll include them in a future post. Thanks for reading!
Up next → The Data Product Manager: What, why and how
