A data product is often defined by its technical output: a dataset, API, dashboard, analytical model, or AI application. That definition is useful, but it leaves out much of the work that decides whether the product creates value.
Before a data product reaches development, an organization needs to define the business problem, gather evidence, shape use cases, assess expected value, expose assumptions, compare priorities, and make an investment decision. After approval, the initiative still needs requirements, delivery planning, development, governance, adoption, and value measurement.
These activities form the workflow around the technical product. That workflow decides what gets built, why it gets built, whether the right information reaches delivery teams, and whether the organization can later see if the investment produced its intended result.
Workflow as Product in Data Products starts from a simple claim: the end-to-end workflow from business need to measurable outcome should receive product-level attention. It has users, owners, inputs, decisions, quality needs, governance, dependencies, feedback, and measurable performance.
The idea connects several established areas of research. Decision-science research highlights business problem framing and decision design. DORA emphasizes end-to-end value streams and the risks created by handoffs. McKinsey links mature product operating models, especially ways of working, with stronger business performance. MIT CISR extends data-product ownership into adoption, reuse, continuous improvement, and value realization. NIST treats governance as a lifecycle activity rather than a one-time approval event.
Together, these ideas support a broader view of data-product management. The workflow around the technical product should not remain a set of disconnected documents, meetings, approvals, tickets, and status reports. It should be intentionally designed and managed.
What Workflow as Product Means
Workflow as Product means treating the workflow around a product as a managed product in its own right.
For data products, that workflow starts with the business need rather than with technical development. Existing reports, strategy papers, customer requirements, operational issues, regulations, and management discussions provide the context from which possible data-product initiatives emerge.
Teams then need to turn that information into something decision-makers and delivery teams can use. They define the problem, identify potential users, develop use cases, gather evidence, estimate value, document assumptions, compare alternatives, assess risks, and prepare an initiative for review.
Approval does not end the workflow. The approved initiative needs to become delivery work. Requirements need to retain the original business purpose. Delivery teams need enough context to understand the expected outcome. Governance needs to accompany the initiative. Progress needs to remain visible to business owners.
After deployment, adoption and realized value need to be compared with the assumptions that justified the investment. Workflow as Product treats this whole chain as something that deserves intentional design.
The workflow has users: executives, business owners, product managers, analysts, governance teams, and engineering teams. It has defined inputs and outputs. It contains decisions and dependencies. It requires traceability and quality controls. It produces information that other parts of the organization depend on. Its performance can be measured through decision time, handoff quality, rework, delivery alignment, adoption, and realized value.
Seen this way, the workflow is more than administration around the technical product. It affects the product itself.
Why It Matters
A weak workflow does more than slow down an initiative. It changes what reaches the customer or business user.
If the original problem is poorly defined, a technically successful product might solve the wrong problem. If evidence disappears during approval, decision-makers lose the basis for assessing the investment. If assumptions disappear before delivery, engineering teams work without knowing which conditions were expected to be true. If the expected business outcome is reduced to a list of Jira tasks, successful task completion can become disconnected from successful business performance.
The research behind this article identified this separation as a recurring issue in data-product initiatives. Business context, evidence, planning, decisions, and delivery often live in different documents and systems. As initiatives move between them, organizations risk losing the reasoning that originally shaped the product.
This makes workflow quality part of product quality. The technical artifact remains essential, but technical quality alone does not determine whether a data product creates value. The surrounding workflow determines whether the organization selects the right opportunity, preserves its business meaning, governs it, executes it consistently, and learns from the result.
The Product Starts Before Development
The distinction between data science and decision science helps explain why the product starts before development.
A 2025 study in Harvard Data Science Review compared the skills associated with data science and decision science. Data-science roles emphasized coding, machine learning, modeling, data analysis, and data management. Decision-science roles placed more weight on business understanding, problem solving, planning, decision-making, and decision modeling.
Organizations need both sets of capabilities when moving from technical analysis toward business action. For data products, much of the eventual value is shaped before technical implementation starts. The organization needs to understand what decision or business process it wants to improve, which problem deserves attention, what evidence supports the initiative, and what outcome would count as success.
Those activities are not preliminary paperwork. They shape the definition of the product. Workflow as Product connects this business and decision context with technical delivery instead of treating them as separate tracks.
Handoffs Are Product Quality
Many organizations have recognizable chains of handoffs around data-product initiatives.
A business report becomes a presentation. The presentation becomes a business case. The business case becomes an approval request. The approved initiative becomes a requirements document. Requirements become Jira epics, features, and issues. Delivery status later becomes another presentation for management.
Each transition creates a point where information needs to survive.
DORA's research on value streams gives a useful way to understand this problem. DORA recommends looking at the complete flow of work rather than optimizing isolated activities. Its value-stream guidance examines information flows, waiting times, bottlenecks, and handoffs between teams.
Handoffs matter because they introduce opportunities for delay and miscommunication. In a data-product initiative, they also introduce opportunities for business context to disappear.
A use case might reach the delivery team without the evidence that supported it. A feature might arrive without its value hypothesis. Leadership might approve one version of an initiative while engineering later works from a differently interpreted requirement.
The problem is not only how quickly work moves between systems. It is whether the meaning of the product survives the movement.
Operating Models Point in the Same Direction
The development of product operating models provides another parallel.
McKinsey research across more than 400 publicly listed companies examined the relationship between product and platform operating-model maturity and business performance. Companies in the upper half of maturity showed 60 percent higher total shareholder returns and 16 percent higher operating margins than companies in the lower half. McKinsey presents these results as correlations rather than proof that the operating model alone caused the performance difference.
The finding most relevant to Workflow as Product concerns ways of working. Among the operating-model areas examined, ways of working had the strongest correlation with overall business performance. This area included lifecycle responsibilities, dependency management, common processes, standard artifacts, shared tooling, and consistent product-management and engineering practices.
This supports an important principle. Product performance depends on more than the capability of the technical team or the quality of an individual tool. The surrounding operating system matters.
For data products, that operating system includes how opportunities enter the portfolio, how evidence is evaluated, how decisions are made, how approved initiatives reach delivery, how governance operates, and how value is measured after deployment.
Ownership Does Not End at Delivery
MIT CISR's research on data products provides direct support for extending product thinking beyond technical creation.
Its 2025 research on adopting a product mindset for data describes data products as managed assets and solutions whose owners remain responsible for their returns over time. That responsibility includes understanding consumers, encouraging use, improving the product, and managing its lifecycle.
This changes the meaning of done. A dataset existing in production does not demonstrate value. Neither does an API responding correctly, a dashboard being released, or a model being deployed. Value depends on what happens after technical delivery.
MIT CISR's July 2026 synthesis of a decade of data-monetization research describes a chain that runs from data capabilities and reusable assets through organizational use and monetization initiatives to measurable business outcomes. The research argues for owners who maintain and improve data assets across their lifecycle.
The implication is that delivery represents one stage in a longer value process. Workflow as Product makes that longer process explicit. The original value hypothesis needs to remain connected to adoption and measured results. Otherwise, organizations know what they delivered but struggle to determine whether the reason for building it was valid.
Availability Alone Does Not Produce Value
MIT CISR's research on data democracy provides useful evidence of the difference between creating data assets and achieving business use.
Its 2025 research found that, on average, only 28 percent of employees used reusable organizational data assets. Organizations where at least one-third of employees used those assets reported that data-monetization initiatives represented 15 percent of total revenue. In organizations with lower use, the figure was below 5 percent.
The study does not show that workflow design caused this difference. It does show why a data-product lifecycle should not stop at availability. Products need consumers. Consumers need access, context, motivation, skills, and organizational support. Owners need evidence about adoption and outcomes.
Workflow as Product therefore extends beyond the path from idea to deployment. It also includes the feedback process through which organizations learn whether the product is being used and whether it is generating the expected value.
Governance Should Travel With the Product
Governance is often implemented as a parallel process. Teams build products while governance teams maintain policies, conduct reviews, request documentation, and operate approval gates.
Workflow as Product suggests that governance should instead remain attached to the initiative throughout its lifecycle.
NIST's AI Risk Management Framework provides a useful example of lifecycle governance. Its Govern, Map, Measure, and Manage functions operate across the lifecycle of an AI system rather than as one isolated approval exercise. Although the NIST framework specifically addresses AI risk, the operating principle applies more broadly to data products.
Evidence should remain connected to the initiative. Assumptions should remain visible. Reviews should create traceable records. Approved versions should remain identifiable. Decisions should remain connected to the information available when they were made. Changes should trigger reassessment. Delivery status and later outcomes should remain connected to the original purpose.
Governance then becomes part of the way the product works rather than documentation recreated around it.
Context Is Part of the Product
Data Mesh thinking provides another related concept. Research published by Martin Fowler and Thoughtworks on data-product fitness functions describes qualities such as discoverability, interoperability, security, trustworthiness, accessibility, and standalone value as characteristics of good data products.
These qualities do not come from the underlying data alone. They require metadata, ownership, standards, monitoring, policies, and controls. This already expands the concept of product quality beyond the payload itself.
Workflow as Product extends that logic toward the business lifecycle. If metadata, governance, interoperability, and trust form part of data-product quality, then the integrity of the business context, decisions, ownership, and value hypothesis should also receive deliberate management.
MIT CISR's 2026 research on semantic layers adds another useful perspective. Semantic layers exist because data often loses important business meaning when it moves away from the systems and processes where it originated. Terms, relationships, rules, ownership, definitions, and other context need to remain understandable to people, analytical systems, AI models, and AI agents.
Workflow as Product applies a similar principle to the business context around a data-product initiative. Organizations need to retain why the product exists, which business problem it addresses, what evidence supported the investment, which assumptions were accepted, who approved it, what value was expected, what changed during delivery, and whether the resulting product produced the expected result.
These relationships form part of the meaning of the product. Losing them creates the business equivalent of losing semantic context from data.
A Jira Issue Is Not the Full Requirement
This becomes especially important when approved data-product initiatives enter delivery systems. Jira and similar tools are well suited to managing delivery work. They provide structure for epics, features, stories, tasks, ownership, priorities, dependencies, and progress.
The full business requirement contains more. Delivery teams need to understand the objective behind the work, the user need, source evidence, value hypothesis, assumptions, risks, decision history, and expected outcome.
Moving work into Jira therefore represents a handoff rather than the end of the business workflow. If business context becomes disconnected at that point, delivery teams might complete exactly what was written while producing something different from what the organization originally intended.
Workflow as Product does not require Jira to become a business strategy system. It requires the relationship between delivery work and business context to remain intact.
A Working Definition
The research streams discussed above approach the problem from different directions. Decision science emphasizes problem framing and business decisions. DORA focuses on end-to-end flow and handoffs. Product operating models focus on lifecycle ownership and ways of working. Data-product research focuses on consumers, reuse, continued ownership, and measurable value. NIST embeds governance throughout the lifecycle. Data Mesh treats metadata, trust, governance, and interoperability as product qualities.
None of these sources defines Workflow as Product in Data Products exactly in the form proposed here. Together, they provide strong foundations for it.
Workflow as Product in Data Products means treating the end-to-end workflow from business need to measurable value as a managed product.
That workflow includes the business problem, source evidence, use-case development, value assumptions, prioritization, leadership decisions, requirements, delivery planning, governance, development, adoption, monitoring, learning, and value measurement.
A broader definition of a data product follows from this principle. A data product consists of the technical asset, the business context that gives it purpose, the workflow that moves it from need to delivery, the governance that maintains trust, and the feedback process that determines whether it creates value.
What This Means for Maysano Studio
This concept provides a clear foundation for Maysano Studio. Studio is not intended to replace every system involved in creating and operating a data product.
Business source materials continue to exist in their original systems. Delivery teams continue to work in Jira and other engineering environments. Technical products continue to run on data and AI platforms.
Studio addresses the continuity between those environments. Existing business material becomes structured data-product initiatives while retaining source evidence, business objectives, use cases, assumptions, expected outcomes, and decision context. Teams review and develop those initiatives before leadership decisions. Approved work moves into Jira while retaining its relationship to the original business context. Execution progress then returns to the same initiative context rather than becoming a separate reporting exercise.
This creates a connected business-to-delivery workflow. The purpose is not to place every activity inside a single application. The purpose is to preserve context across the lifecycle so that people making decisions, people delivering the product, and people measuring its results are working from the same underlying business rationale.
That is the practical meaning of Workflow as Product in Data Products. The technical data product still matters. The organization should apply the same product discipline to the workflow that determines what gets built, why it receives investment, how it reaches delivery, how it is governed, and whether it ultimately creates value.
