• Lean gave efficiency.
• Agile gave speed.
• OKRs gave alignment.

AI — the most transformative technology yet — has none.

That absence explains why fewer than 1 in 20 pilots ever scale. MIT research shows that collapse once real work begins. The models aren’t broken. The management system is missing.

The result? Pilot theater instead of P&L impact. Portfolios fill with zombie pilots, capital stalls, credibility erodes.

What’s needed is an AI Operating System (AI OS) — not software, not more models, but a leadership discipline. Done well, it creates a flywheel where every application makes the next project cheaper, faster, and more impactful. This is how companies move from random acts of AI to compounding advantage.

The Broken Contract of Predictability

For fifty years, enterprise systems were deterministic: same inputs, same outputs. That contract of predictability enabled stable workflows, fixed standards, and linear planning.

AI breaks that contract. It is:

• Probabilistic → outputs vary.
• Fast-changing → models evolve weekly.
• Expectation-distorted → consumer chat resets what “good” looks like overnight.

This fracture shows up in three ways:

• People → trust erodes when employees trained for certainty get tools that deliver probability.
• Platform → reuse collapses when every pilot reinvents its own foundation.
• Portfolio → returns stall when weak pilots linger, tying up capital that should be compounding.

The AI OS provides the discipline to manage this new reality.

Pillar 1: People → Adoption Through Rhythm, Not Rhetoric

At a Fortune 500 I worked for, 600 employees were trained on AI. A year later, fewer than 2% still used it weekly. The models worked — but nothing in their daily rhythm had changed.

The problem isn’t comprehension. It’s predictability. Tools that don’t fit into daily rituals don’t survive.

The Two-Hour Budget of Change
Every team has about two discretionary hours each week to try new ways of working. If AI can’t collapse a two-hour task into twenty minutes inside that window, adoption fails.

That’s why quick wins matter. They’re intentionally small — the first behaviors that prove AI is worth using. A visible 20-minute save builds belief faster than a grand vision deck.

And belief accelerates when risk feels managed. A one-page Risk Ledger — simple enough to follow, strong enough to protect the business — gives people the confidence to experiment.

Leadership plays:

• Make augmentation feel like a gain, not a threat.
• Rewire one ritual — put AI on the calendar.
• Deliver a 20-minute win in 14 days.
• Publish simple guardrails, not dense policy decks.

Pillar 2: Platform → Scale Through Reuse

At one global bank, 22 AI pilots “worked.” None scaled. Each had its own tech stack, pipeline, and reporting.

That’s not compounding. That’s replication.
No leader would let every department pick its own ERP. AI deserves the same discipline.

The answer is minimum viable standardization. Every AI program has repeatable activities. The key is deciding which ones must be uniform across the org, and which can vary by team.

Ask two questions of each activity:

1. Does it stay mostly the same, or change often?
2. Do we all need to do it the same way?

From this, four zones emerge:

• Standardize → stable, uniform (data pipelines, audit logs).
• Guardrail → high-stakes (compliance checks, thresholds).
• Flexible → where differentiation matters (UX, prompt libraries).
• De-prioritize → low-value, one-off workflows.

Leadership plays:

• Appoint a platform owner with starter kits and safety defaults.
• Mandate one universal logging standard for cost, output, and quality.

Shared rails are what make audits meaningful. Without them, every evaluation is apples to oranges.

Pillar 3: Portfolio → From Motion to Margin

At one board review, 17 AI pilots were in flight. The CFO asked, “What’s the run-rate impact?” Silence followed.

That’s pilot theater: activity without compounding. Zombie pilots drain budget because no one wants to declare them dead.

To avoid theater and focus capital, treat every AI investment against four checkpoints before giving it more funding:

1. Adoption → a visible win in the first cycle of work.
2. Reuse → another team can adapt it within a month.
3. Trust → nine of ten outputs pass a human check.
4. Economics → unit costs improve with volume.

Rule of thumb: if a pilot fails two gates, kill or redesign.

Healthy portfolios climb in sequence:

• Capacity Creators → Automate repetitive work to cut costs and free budget. These wins create the dry powder for what comes next.
• Accelerators → Redeploy that capacity to drive revenue velocity — shorten sales cycles, accelerate underwriting, increase conversion.
• Multipliers → Invest in AI-native products and new revenue streams — the true long-term growth engines.

Skip a rung and you tie up capital in shiny bets without the base to support them.

Leadership plays:

• Prune visibly — kill zombie pilots in public.
• Define “good enough” in writing.
• Stage-gate funding — advance only if gates are cleared.

The Executive Mandate

Objection: “This is bureaucracy. It will slow us down.”
→ Reality: Random pilots are slow. Shared rails create speed.

Objection: “My team’s needs are unique.”
→ Reality: If the core isn’t reusable, it isn’t scalable.

Quick wins build belief. Shared platforms build speed. Disciplined portfolios build value. The Operating System ties it all together.

From Motion to Momentum

Picture your next board deck:
“Three scaled AI solutions driving $40M in run-rate savings, five sunsetted pilots, two new revenue streams in flight.”

That’s the discipline of an AI Operating System.

• People → Rhythm builds belief.
• Platform → Rails create speed.
• Portfolio → Returns compound.

Do this, and AI shifts from pilot theater to compounding impact. Leave it to chance, and the gap only widens.

AI isn’t a project. It isn’t a platform.
It’s a portfolio. And only an Operating System makes it compound.

Data, data everywhere…
While the rate of data generation is exponentially accelerating(90% of the world’s data was generated in the past 2 years) enterprises still continue to approach data management with similar strategies from a decade ago. While many executives preach the virtues of a data-driven organization, very few truly appreciate the evolution required to truly become “driven” by data. Oftentimes, these executives are up against a mountain of technical and cultural debt making this process much harder than starting from scratch. This includes:

• System fragmentation leading to data silos
• Locked into vendors with poor(or no) API access
• Locked into legacy systems with complex data models and antiquated technologies
• Data that is variably structured, or unstructured, in a variety of technologies and formats
• Non-compliant, and ungoverned data with little to no access control
• Poorly defined or non-existent data definitions, leading to confusion
• A lack of quality controls, leading to poor quality data and undermined consumer trust

As discussed in previous posts, this results in data consumers lacking access to the data they need, leaving it upon the IT team to deliver this data. Inevitably, this deluge of data from sources and requests from consumers leads to bottlenecked IT teams that are set up for failure from the start. In addition, somewhere between 70–90% of enterprise data remains “in the dark”. This is data that could be used for driving business outcomes but instead goes unseen and unleveraged. It’s crazy to think of the untapped potential business value just sitting out there on servers around the world.

When we step back to reflect and distill this problem down to its essence, it really comes down to managing the complexity of communication in an ever-digitizing world that is becoming more and more dependent on technology and data for operations and decision making.

Conway’s Law, a theory was first coined by scientist and programmer in 1967, saliently captures this by stating that “Organizations, who design systems, are constrained to produce designs which are copies of the communication structures of these organizations”.

In short, an organization’s output is directly related to how it communicates internally.

Over time this challenge of communication complexity has only become more pronounced with the specialization of roles and proliferation of systems(SaaS) for managing communication within and amongst them. Below is an overly simplistic representation of how we’ve gotten here.

To understand the value of data products, we need to better understand the nature of this complexity. To do so, I’ll employ the concept of Essential(Domain) and Accidental(Technological) Complexity.

Note: This concept was inspired by the prolific software engineer and Turing Award winner, Fred Brooks in his paper “No Silver Bullet” who built off of Aristotle’s concept of Essential & Accidental Properties. While this concept was originally intended for software engineering, I find the framework very useful for understanding the “why” of data products.

Domain(Essential) Complexity → the complexity inherent in the problem domain. It is caused by the problem to be solved and nothing can remove it completely. This includes things like:

1. Process Complexity(the way things are done) — think order of procedure, business rules, etc.
2. Semantic complexity(the meaning assigned to things) — different names for the same thing or the same name for different things.
3. Regulatory Complexity(government keeping companies accountable) — think compliance like GDPR, HIPAA, SOX etc.
4. Emergent Complexity(how fast the above 3 change) — consider the above in context of biotech vs. construction.

Technical(Accidental) Complexity → the complexity born from the way in which we have chosen to solve the problem. This is complexity that can be continuously improved upon through better engineering.

1. Data Sourcing(where is the data) — on prem or cloud, this table or that one.
2. Data Processing(why so many formats) — data duplication and inconsistency.
3. Pipeline Complexity(what is this black box) — unintelligible data rules embedded in a proliferation of one-off data pipelines.
4. Architectural Complexity(no standard patterns) — leading to governance complexity and ballooning costs.

A Way Forward..The Data Product(productization of data)

Fortunately, the field of Product Management provides us with a robust set tools and processes for overcoming complexity through the process of productization. This means that we can systematically abstract Essential (Domain) and Accidental(Technological) Complexity from data tasks to create higher value experiences for data consumers. We’ll dive into the how more in future posts but, in short:

1. Data products reduce essential complexity by narrowing the gap between the domain knowledge and the data through abstracted representations. Reducing this gap acts to tighten the feedback loop between the reality of the domain(the business) and the representation of it(the data). The tighter the feedback loop the closer the representation is to reality. This results in higher quality data sets for operations and higher fidelity models of reality for better decision making.
2. Data products reduce accidental complexity through the implementation of standardized approaches to the management of data that saves time and money. Through the use of data catalogs, reusable platform components, streamlined governance tooling and much more the technological complexity of managing data is becoming easier every year.

While “data product” means different things to different people in different contexts, all data products share the same 3 principles:

1. They serve a persona/s(specific target consumer/s)
2. They are owned by someone (xyz Data Product Manager)
3. They go through a product life cycle, just like any other product.

At its core, the goal of any Data Product is to provide the means to abstract complexity while retaining the highest level of fidelity of the data as a representation of reality.

Up next → Types of Data Products by Level of Abstraction.

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:

1. 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.
2. 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.
3. 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:

1. 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).
2. 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.
3. 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

TL;DR — “Data Product” means different things to different people in different contexts. While it would be convenient to have a single definition, it’s simply not practical. Instead, I’ve found some heuristics especially helpful in trying to wrap my mind around the scope and meaning of the “data product” in context.

Over the past couple of years, the concept of a “data product” has seen a rise in both interest and confusion. This is no doubt due to its adoption within the business and technology communities under different contexts. This has resulted in the concept having multiple meanings. To make things even more difficult, vendors often push the version that suits them best, adding more noise to an already noisy space.

Although there is no hard and fast definition of a data product, I have found some heuristics especially helpful for finding some sense in the ambiguity:

Heuristic #1 — Does the data facilitate value directly or indirectly?

DJ Patil, the US chief data scientist, defines a data product as “a product that facilitates an end goal through the use of data”(from his book Data Jujitsu: The Art of Turning Data into Product, 2012).

No super helpful DJ… So, pretty much everything on the web is a data product then right?? Not so fast.

Simon O’Regan, current head of Monetization at TikTok, draws an important distinction; “the distinction between products that use data to facilitate an end goal and products whose primary objective is to use data to facilitate an end goal.” In other words, true data products are the medium by which end users interact with and extract value from data. The data product’s purpose is to facilitate this interaction with data in a way that maximizes value for the consumer.

Heuristic #2 — Who is referring to the “data product”?

One’s “level” within the organization does a lot to frame their understanding and intent. Oftentimes, the “higher” one resides on the organizational pyramid the broader their scope of context. This is no different with “data products”.

Organizational-Level

At a leadership level, an executive may view the organization’s data product as the collection of every piece of data, and the tools used to generate, access, and analyze that data, within that organization.

Management-Level

At a management level, a VP of marketing may view their Dashboard/Visualization as a data product.

Product-Level

At a product level, a Product Manager may view the algorithm data scientists are exposing for them to consume as a data product.

Developer-Level

At an engineering level, a developer may view the set of APIs for a specific domain as a data product.

Heuristic #3 — Does the data product fit on the hierarchy of abstraction?

Simon O’Regan introduced a useful framework for categorizing data products. In his post, Designing Data Products, he introduced 5 types of data products. I’ve further elaborated on this concept with the “Functional Hierarchy of Data Products”.

This model proposes that we can organize data products into 5 broad functions, listed in terms of increasing internal complexity and decreasing(ideally) user complexity. In other words the greater we ascend the data product functional hierarchy, the greater the data product internalizes complexity.

Let’s ascend the hierarchy from the bottom-up:

1. Raw Data → At this level we are simply collecting and exposing data from the source. While this provides significant flexibility, most of the work is left to be done on the user’s side. Example: A data engineer connecting an API to a data warehouse.
2. Derived Data → With derived data, some processing is done within the product. Consider the case of sales data; we could add additional attributes like market sales segmentation or opportunity conversion rates. Example: A data analyst connecting to an executive dashboard.
3. Algorithms → With algorithms, date is “ran through” the algorithm(linear regression, K-means clustering etc) to return new information or insights for the consumer. Example: A product manager leveraging a KNN algorithm owned by the data science team to intelligently bucket cohorts of users based on specified features.
4. Decision Support → As the name implies, these data products are specifically designed to help users with decision-making. It is important to note that the data product is not making the decision but rather presenting the most relevant data in a way that assists the user in making better decisions. Example: The Executive team’s KPI dashboard they use for quarterly planning.
5. Automated Decision-making → At the top of our functional hierarchy, we totally outsource our intelligence to allow the algorithm to determine the final output for the user. Machine learning models are often employed for these types of data products. Example: The recommender system for an organization’s intranet.

Heuristic #4 — How is the data product being consumed?

While most traditional digital products are consumed by end customers(B2C) or businesses(B2B), in the form of applications, data products offer a spectrum of interfaces for consuming this value. Each interface, with its own distinct consumers and product design and development considerations.

APIs.
While many would consider APIs purely technical, properly designing them requires a mix of technical know-how and product best practices. A solid API Data Product must be intentionally designed to provide a desirable and valuable experience to API consumers in light of many constraints and trade-offs. This means more than just providing a connection to a data source, but also:
 — Providing users frictionless onboarding
 — Creating useful API documentation & tutorials
 — Providing an API sandbox /playground
 — Documenting and sharing an API roadmap
 — Etc.

Dashboards & Visualizations.
Dashboards and visualizations are most often positioned as decision support tools for managers and executives. Selecting what data to share in what format is especially important for these types of data products. Understanding the questions consumers would like to answer along with their data/statistical proficiency is critical when designing dashboards as design decisions can significantly influence how the data is perceived.

Web Elements.
Web elements are the least technical(from a consumer standpoint) of data product interfaces. These types of data products can include search, AR, embedded analytics, dynamic maps and more. These data products are especially powerful as they can meet the user where they are, providing tools in context. Additionally, their abstracted nature often means that technical and non-technical users can engage with the data product. Finally, ease of access also lowers barriers to engagement. While embedded data products are still in their early years, you can expect to see more of these in the years to come.

While there is no single definition for a “data product”, heuristics like the ones defined above can be helpful for finding some clarity in the ambiguity.

Have any useful methods for defining data products? Please leave them in the comments below and, if they resonate, I’ll include them in a future post. Thanks for reading!

Up next → Data Projects vs. Data Products — Why Mindset Matters

For the past 5 years working as a Product Management Consultant in a variety of industries(Finance, Insurance, Energy etc) I’ve seen a growing tension between business and technology teams over all things data. Business teams are frustrated by a lack of actionable high-quality data, while technology teams feel burdened by competing priorities and a lack of strategic alignment and support.

While this tension is not new, it has become increasingly pronounced over the last decade with the rise of “big data” and the need to leverage data for decision making to stay competitive. Fortunately, the storing and processing of data at scale has become significantly more efficient and affordable.

Additionally, data tooling(think dbt, Fivetran, Preset, Rudderstack etc)has become much more efficient and accessible. What used to require an entire team and take months can now be done by a few people in a couple of weeks(or days). Still, organizations continue to struggle to make sense of their data assets. How can this be?

“Good communication is the bridge between confusion and clarity.” ~ Nat Turner

Making Sense of data requires good communication

As these tools continue to advance, the scarce resource is no longer the means to store and process data, but the ability to make sense of it and communicate it in a way that maximizes value creation for the organization. Unfortunately, organizations are rarely structured around value-driven communication but, instead, hold onto their hierarchical function-centric structures.

While the hierarchical model limits operational complexity(in theory), it also decreases the flow of information and increases communication friction across functions. This is compounded by the fact that each function often utilizes different operational systems, resulting in siloed data.

This model may’ve worked in the decision-making cycle of yesteryear where data was not treated as an outcome driving asset, but it doesn’t cut it in a world where today’s data drives tomorrow’s strategy.

If you’re interested in learning more about organizational communication structures and knowledge dissemination, Tristan Hardy has a great post on Scaling Knowledge.

Organizations are catching on and realizing that their current structures fall short. They understand that data consumers should be able to access the data they need, when it is needed, from an identifiable and trusted source. The challenge is that many organizations have dumped massive amounts of data in cheap storage out of fear that they may lose insights.

This has backfired though and now organizations are trying to make sense of years of data with no formal governance, standards or ownership structure. Nobody knows exactly what data is available to them or where to look for it. Even worse, each function is only aware of its own data(best case scenario). Good luck trying to get metrics on data that spans multiple functions and operational systems.

Product Management to the rescue(I say only somewhat sarcastically)

Increasingly organizations are turning to a tried and true method of bringing order to communication chaos — applying product management processes & methodologies to data. In this model, data is treated as a product and made available to consumers that have specific problems to solve. Data Product Managers work across functions, breaking down the communication barriers common in the hierarchical organization.

This fundamentally reframes the data challenge by redefining how data needs are communicated and served within the organization, all while unlocking a whole new set of Product Management tools, such as:

• Product Vision & Strategy
• Cross Functional Roadmap
• Hypothesis-driven measurement and iteration
• Measurable KPIs etc…

While these data products vary significantly(as we’ll soon see), they generally have the following overarching objective: to manage, organize and serve data to consumers in a way that drives the greatest value for the organization.(I’ve kept this intentionally vague — we’ll dig deeper later).

** These posts assume the reader has knowledge of Product Management — the methodology, mindset, lifecycle etc.

Why & How I Write

While data product investments are often undertaken with the best intentions, Product Managers in these positions are often ill-equipped for the world they’ve found themselves in. I’ve seen too many good PMs go from excited→confused →frustrated →disillusioned. This can stem from a multitude of reasons but almost always has its roots in a lack of proper context and understanding of the role upfront.

Instead, many PMs are led to believe that this is simply “product for data’’. While this is true in some sense, it’s far from the full picture. I hope the following posts help Product Managers who’ve found themselves increasingly responsible for data find some clarity in the ambiguity of the role.

Before going any further, I’d like to note a few things:

• I consider myself a student of these topics, not an expert. I write to help elucidate my thoughts, with the hope of contributing to a community of mutually interested folks.
• I believe strongly that everything is a remix. You’ll find that most of this content was inspired by others. I’ll do my best to cite the inspiration.
• I welcome all constructive criticism and feedback so long as it is in good faith :)

Up next → What the heck is a “Data Product” Anyway? (hint-depends who you ask)