Canvas-Driven Product Management

The Canvas-Driven Product Management (CaDPM™) Guide is a structured methodology that covers the full lifecycle of a digital product — from initial business idea through discovery, development, and all the way to market monetization. It was created by Anar Rustamov and first published in 2026.

CaDPM™ consists of 17 structured pipeline stages that keep all stakeholders — business owners, product managers, designers, developers, and AI agents — aligned around a single shared language: the Language of Digital Product.

The guide is not only theory. It is a theory + system model — the methodology is directly supported by the DPS System, which enables its practical application in real projects. (It is an open source system and you can download it here.) CaDPM™ encompasses three sub-frameworks:

• CaDAF™Canvas-Driven Architecture Framework — engineering architecture standard for AI-supported development.
• CaDPE™Canvas-Driven Project Execution — measurable execution indicators for tracking project health.
• Communication RingA shared language model ensuring every participant (human and AI) communicates using the same product terminology.

Anar Rustamov

Canvas-Driven Product Management Guide

Creator of CaDPM™, CaDAF™, CaDPE™ & DPS System

In the AI era, companies now demand that the processes of discovering, developing, and monetizing digital products be carried out faster and in a more systematic way with AI. This is because artificial intelligence (AI) can analyze business requirements more quickly, understand them more accurately, and help minimize risks. At the same time, AI has the potential to increase development speed by 10, 20, or even 40 times. As a result, companies achieve significant savings in both time and budget during the development and Quality Assurance (QA) stages.

On the monetization side, the goal is no longer only to make sales. The goal is also to identify customer segments, define potential customers (leads), bring them into the sales process, and sell to them again after the first sale. This approach creates a more sustainable and measurable revenue model.

The biggest challenge here is the existence of a communication war between teams. This problem is especially visible between the business side, the technical team, and AI agents. Even though all sides work on the same product, they do not speak the same language and do not think with the same logic. Software engineers, by working with Claude, ChatGPT, and other AI assistants, can significantly increase coding speed through AI prompts. For example, a product with a codebase of around 100k lines, shaped by business requirements, can be built in a much shorter time with AI support.

However, for the right prompts to be given, software engineers must understand business requirements very accurately. This is because AI produces results only as accurately as the direction it is given. When the requirement is not understood correctly, speed may increase, but the quality of the outcome may become weaker.

The main problem is that the business world uses unstructured business language, while the technical team uses structured technical language. Because of this, the sides cannot fully understand one another. The business side expresses needs in a more general and meaning-oriented way, while the technical team wants to see those requirements in the language of structure, logic, and systems.

That is exactly why one of the biggest problems between the product manager and the dev team is communication. When business requirements are not translated correctly into technical language, both time loss and quality mismatches appear in the product. This directly affects the speed of product delivery.

For this reason, companies are now looking for product delivery driven professionals. Market competition is extremely fast, and both time to market and product delivery time have now become strategic indicators.

Companies no longer want a long onboarding process. They want professionals who can enter a project quickly, understand the system fast, and deliver results at speed. In other words, a professional should not only be ready-to-work, but also ready-to-deliver value quickly.

To solve the problems mentioned above, the Canvas-Driven Product Management CaDPM™ Guide was created. This guide makes communication across the stages from product discovery to delivery more systematic, clearer, and more applicable.

The CaDPM™ Guide aims to eliminate the communication war that arises between teams. This approach creates a shared working language between business, product, the technical team, and AI. As a result, requirements are understood more correctly, translated more accurately, and executed faster.

At the same time, based on the CaDPM™ Guide, a fully applicable DPS (Digital Product Summary) System has been created. This system brings the logic of the guide into a practical environment and provides a structure that can be used directly in the daily work of teams.

By downloading the DPS System free of charge from GitHub, teams can quickly increase their onboarding-readiness level. This allows them to become ready-to-work and ready-to-deliver more quickly.

As a result, the CaDPM™ Guide and the DPS System together enable companies in the AI era to think faster, communicate more accurately, and bring digital products to market in a more systematic way.

The first three steps are primarily about building communication through standardized canvases. In these stages, the goal is to define needs correctly, describe services and functionality precisely, shape analysis and design properly, define the UAC model clearly, verify whether the data meets real needs, and confirm that the UX and UI direction matches customer expectations.

One of the strongest aspects of these canvases is that they are built to work well not only for human teams, but also for AI assistants. Even when a team communicates with AI in simple language, the structured canvas format helps produce more consistent and accurate outputs.

The Digital Product Summary (DPS) System is a practical system designed to carry out the discovery, development, and monetization stages of a digital product in a more systematic and manageable way. The main purpose of this system is to create a shared working environment between the business team, the product side, the technical team, the sales team, and AI Agents.

The DPS System is not just a task management tool. It is an approach that brings together the product's core needs, functionalities, design logic, acceptance criteria, backlog structure, and monetization side within one unified system. As a result, project-related information does not remain scattered — instead, it becomes visible, connected, and traceable.

One of the main strengths of the system is its canvas-based approach. Through the Business Canvas, UI Canvas, and Backlog Canvas, product requirements are written more clearly, a more accurate direction for development is established, and communication within the team becomes more precise. This approach also makes it easier to work with AI Assistants, because it becomes much easier to prepare AI prompts based on structured canvases, and the quality of the result improves.

Another important advantage of the DPS System is that it creates traceability. In other words, it becomes possible to connect the customer requirement with the UI requirement, the backlog task, the commit, and the development result. This makes the delivery process more transparent and helps preserve alignment between project requirements and the final output.

The DPS System does not only explain the theory — it enables its direct application. For this reason, this approach is not only theory, but also a practical model based on the combination of theory + system.

As a result, the DPS System is the practical implementation environment of the CaDPM™ approach. It helps teams onboard faster, communicate more accurately, work more effectively with AI, and deliver digital products in a more structured and reliable way.

The CaDPM™ Guide and its practical implementation environment, the DPS System, provide the highest value when the team uses them not simply as documents to read, but as the main management and communication tools of daily work. For this approach to be applied correctly, the first step is for team members to adopt the same digital product language.

To begin using it, the project's purpose, core need, and the problem it is intended to solve must first be clearly defined. At this stage, the Business Canvas is used. Within the Business Canvas, it is written which problem the product solves, which user groups it serves, what the main functionalities are, and what value the product creates. This step is very important, because all later stages are built on the logic defined here. If the need is written in a confusing way at the beginning, the later development and monetization stages will also become confusing.

In the next stage, the product's user interface and functional flows are structured through the UI Canvas. Here, each page, component, input field, button, table, user behavior, UAC rules, and expected outcomes are documented in more detail. The goal is to ensure that no one works based on assumptions during the design, development, and acceptance stages. The UI Canvas is one of the main documents that connects customer needs with technical execution.

After this comes the stage of breaking the work down for development. At this stage, the Backlog Canvas is used. Through the Backlog Canvas, development tasks are prepared based on the UI Canvas and business requirements, priorities are defined, and the work is divided into modules and deliverable parts. The goal here is to break a large and complex project into smaller, manageable, and deliverable parts. This approach creates clarity within the team and also forms more accurate prompts and a clearer development direction for engineers working with AI.

In the CaDPM™ approach, the development stage should be carried out in an AI-supported way as much as possible. This means that software engineers should prepare AI prompts based on the requirements, acceptance criteria, and structured information written in the canvases, and continue the development process according to that logic. The important point here is not to use AI randomly, but to use it through a properly documented work structure. In this way, development speed increases while alignment with requirements is also preserved.

During use, the logic of acceptance and handover should not be forgotten. For each feature or module, acceptance criteria should be written in advance, and completed work should be accepted only on the basis of those criteria. After that, the result should be documented and handed over to the team in a clear form. This is especially important in terms of onboarding-readiness, because a newly joined specialist should be able to understand the logic of the project more quickly by looking at the system.

At the monetization stage, the product begins to be adapted for the market and the sales funnel. At this stage, it is determined how the product will be packaged, for which segments it will be adapted, how lead entry points will be created, and how the connection between the sales funnel and the technical system will be established. A separate canvas and structured approach should also be used in this part so that the product does not remain only as a developed system, but also moves into a revenue-generating form.

As a result, the CaDPM™ Guide and the DPS System are used best when the team works at every stage not through assumptions and verbal explanations, but through canvases, acceptance criteria, backlog structure, AI prompts, and a shared product language. This approach reduces the communication war within the team, increases development speed, shortens onboarding time, and helps ensure that the digital product is delivered more accurately.

It is essential for team members to know the Language of Digital Product. AI already works well with structured product language, so the main responsibility is for human team members to master it as well. CaDPM™ makes this possible through four shared product languages:

The Canvas-Driven Product Management (CaDPM™) approach was created to solve some of the most common and costly problems in digital product work. In many organizations, product management, project management, development, and monetization are handled in disconnected ways, with different teams using different terms, different logic, and different expectations.

As a result, projects become harder to manage, requirements are misunderstood, delivery slows down, and the final output often drifts away from the original business need. CaDPM™ addresses these problems through a shared product language, structured canvases, AI-ready workflows, and a more measurable delivery model.

The following table summarizes the main product and project management problems that CaDPM™ is designed to solve, together with its practical solution logic and the expected business result.

As a result, CaDPM™ does not only improve documentation or communication. It builds a more structured, AI-ready, and delivery-focused operating model for digital product work.

The Communication War is the breakdown of understanding between business teams, technical teams, sales teams, and AI Agents — caused by different languages, structures, and logic of communication. It arises in four key zones:

The journey of a digital product, from the Discovery stage to Monetization, consists of a total of 17 strategic steps. This pipeline ensures that the entire team moves toward the same goal using the same terminology.

Table 1. Digital Product Delivery Pipeline Stages

The Discovery stage captures the complete business and product foundation before any design or code begins.

Once requirements are fully captured in the Discovery stage, they are gradually transformed into executable work through six structured development steps.

Digital Product Monetization helps teams see the scalability potential of their digital product. Understanding how many users might use the product — and when — is critical for infrastructure scaling and revenue planning.

The Communication Ring is the core structure of interaction in the Digital Product Pipeline Management. It ensures that all human and AI participants can collaborate effectively by speaking the same language — the Language of Digital Product.

In traditional workflows, miscommunication happens because each participant speaks a different language: business uses high-level goals, design uses wireframes, development uses code, and management uses metrics — none of them fully compatible. The Communication Ring solves this by placing a shared structured language at the center.

The Communication Ring has 5 participant types:

The Language of Digital Product is the unified communication system that connects all participants in the product pipeline. It is not a tool or a platform — it is a structured vocabulary and model that every participant (human or AI) must use when contributing to a digital product.

This section explains the main role-profiles defined in the CaDPM™ Guide. Each role-profile has a different role in the digital product pipeline, but all of them are expected to work within the same product language, delivery structure, and execution logic.

The purpose of these role-profiles is to create stronger alignment between product thinking, technical execution, delivery responsibility, and practical collaboration.

The Canvas-Driven Product Manager is a modern product leadership role focused on delivery, not only documentation. This person does not stop at writing requirements and handing them to engineers. Instead, this role follows the product from discovery to delivery and keeps attention on the final result.

Responsibilities

This profile is responsible for translating business needs into structured product direction, guiding discovery, aligning teams, clarifying priorities, and ensuring that delivery stays connected to product goals.

Practical Skills

They should understand product discovery, backlog thinking, business requirements, acceptance logic, workflow coordination, stakeholder communication, and the business and technical language of digital products.

The Design-Driven Product Engineer is a technical professional who combines coding ability with product thinking. This role is not limited to implementation only. It also considers usability, product value, layout logic, and the visual side of digital product structure.

Responsibilities

This profile is responsible for building product solutions that are technically correct, visually clear, and aligned with the intended user experience and business value.

Practical Skills

Frontend or backend engineering fundamentals, component logic, UI structure, API understanding, debugging, code quality thinking, and how design decisions affect user experience and product value.

The Product Engineering Manager stands between product leadership and technical leadership. This role helps both sides stay connected. It ensures that product goals are realistic from an engineering perspective and that engineering work supports business and product priorities.

Responsibilities

This profile is responsible for aligning technical execution with product direction, improving delivery flow, reducing confusion between teams, and supporting engineering decisions that serve the product outcome.

Practical Skills

They should understand product strategy, engineering planning, delivery coordination, team structure, technical trade-offs, risk thinking, and how to connect business expectations with engineering reality.

The Canvas-Driven Product Practitioner includes all other contributors in the digital product pipeline outside of product managers and software engineers. This role brings supporting participants into the same structured delivery logic of the CaDPM™ Guide.

Responsibilities

This profile may support discovery, communication, coordination, operations, testing, documentation, enablement, process follow-up, or other execution-related work needed for product delivery.

Practical Skills

They should understand the basic structure of the product pipeline, common product terminology, communication flow, delivery expectations, documentation discipline, and how their role contributes to the overall product outcome.

The Canvas-Driven Product Management (CaDPM™) Guide consists of 17 structured steps that cover the entire lifecycle of a digital product — from idea to market delivery. To help professionals learn these steps both theoretically and practically, and to apply them in real projects, a series of document templates called Canvases has been developed.

These Canvases — including the Business Canvas, UI Canvas, Backlog Canvas, Product Canvas, and Monetization Canvas — provide a clear visual and logical structure for defining a product's purpose, user flow, technical requirements, and business model. They serve as the foundational learning and application tools that connect strategy, design, development, and monetization within one unified logic.

To extend this learning into real practice, these canvases are integrated into the Digital Product Summary (DPS) system — a practical simulation and collaboration environment. Within DPS, teams and AI Agents work side by side, accelerating digital product development and minimizing resource usage while maintaining professional quality standards.

This model reflects the operational expectations of leading European and U.S.-based companies, where collaboration with AI tools and structured canvases enables teams to gain months of real-world experience in a much shorter time.

Every digital product begins with a clear and detailed business requirement analysis. This is the foundation of the entire project. Based on this analysis, key elements like database structure, system architecture, and APIs are planned — which then guide all subsequent UI Canvas and Backlog Canvas work.

The Digital Product Business Canvas is the primary tool for Stage 1. It captures the full business context: who the customer is, what problem they face, what solution is proposed, and what the product needs to contain to deliver that solution.

The Persona is the structured definition of the target customer group. CaDPM™ uses a precise formula to prevent vague audience definitions that lead to misaligned products.

This means that a persona should not be written in a vague form such as students, small businesses, or users. Instead, it should be written in a way that makes the target group more exact and actionable.

For example

• The group of retail businesses in Berlin with 1–5 employees and monthly turnover below 5,000 EUR that struggle with manual customer tracking and reporting.
• The group of university students aged 18–24 in Italy who use smartphones as their main learning device and need affordable practical digital skills training.
• The group of families that allocate up to 15,000 USD annually for education and expect structured, high-quality, outcome-oriented learning programs for their children.
• The group of individuals who use up to 5 GB of mobile internet monthly and need low-data, mobile-friendly digital learning solutions.

The purpose of this metric is to identify exactly who the target users or customers are, under what conditions they operate, what limitations they face, and what type of value they expect from the product. A well-defined persona gives direction to the next stages of the product pipeline, including requirement analysis, solution concept development, feature planning, and monetization logic.

The Persona Formula forces teams to be specific and measurable. Vague personas like “young professionals” are replaced by structured definitions that directly inform product decisions, pricing models, and lead generation strategies.

Without a clear persona formula, the team may define the audience too broadly, which usually leads to weak product focus, unclear feature priorities, and poor market fit.

Customer Requirement Analysis is the process of identifying, collecting, structuring, and analyzing the real needs, expectations, problems, constraints, and priorities of the defined target personas or customer groups.

This metric is used to translate customer pain points into actionable product logic. After identifying who the target users are, the next step is to understand exactly what they need, what is not working in their current situation, and what kind of result they expect from the future solution.

Requirements should not remain vague. Statements such as we need a better system or we want something easier are not enough. The requirement must be written in a way that explains the current pain, the expected improvement, and the practical outcome the customer wants to achieve.

This metric is important because product teams often fail when they build based on assumptions rather than actual customer requirements. Clear requirement analysis helps connect customer logic with business goals, UI planning, feature definition, development scope, and product delivery expectations.

Example

• The group of small retail businesses in Baku with 1–5 employees need a simple customer tracking system because they currently manage sales and customer records manually through notebooks and Excel files, which causes data loss and poor follow-up.
• The group of university students using mobile devices need short, structured, low-data learning modules because they often have limited time, unstable internet access, and low tolerance for long theoretical content.

Solution Concept Development is the process of defining the initial product solution approach that responds to the identified customer requirements and explains how value will be created for the target personas.

This metric defines the overall answer to the customer problem before going too deep into features or development details. It helps the team explain what kind of solution will be built, how it will function at a high level, and why this direction is relevant for the intended users.

A solution concept is not yet a detailed feature list. It is the structured business and product logic behind the solution. It connects customer problems to a proposed answer and gives all stakeholders a shared understanding of the intended product direction.

This metric is critical because many teams move too quickly from requirements into design or coding without clearly defining the solution logic. As a result, features may become disconnected, priorities may become unclear, and the final product may lose focus. Solution Concept Development helps maintain strategic alignment before execution begins.

Example

• The product will solve manual customer follow-up problems by providing a lightweight web-based CRM platform that enables small businesses to store customer records, track communication, and monitor sales progress in one place.
• The product will solve low engagement in practical education by providing a mobile-friendly learning platform that enables students to access short lessons, complete guided tasks, and track their progress with minimal data usage.

Product Features Development is the process of identifying and defining the specific features, functions, and user-facing capabilities that the product must include in order to implement the approved solution concept.

This metric transforms the solution concept into a practical product structure. Once the overall direction of the solution is clear, the team must define exactly what the product will do, what features the users will interact with, and which capabilities are essential to solving the target problem.

Features must be selected based on customer needs and business value, not on assumptions or personal preference. Each feature should clearly support a real requirement, workflow, or outcome. This also helps the team later with backlog creation, UI design, API design, technical estimation, and sprint planning.

Feature definition is one of the most important bridges between discovery and development. It turns high-level thinking into executable product scope.

Examples

• To deliver the lightweight CRM solution, the product must include customer registration, customer notes, follow-up reminders, sales status tracking, and simple reporting features.
• To deliver the mobile learning solution, the product must include user login, lesson listing, progress tracking, downloadable materials, quiz completion, and certificate generation.

Product Acceptance Criteria Development is the process of defining the exact conditions that a product, feature, module, or user flow must satisfy in order to be considered complete, correct, testable, and acceptable.

This metric defines what “done” means in practical and measurable terms. A feature should not be considered complete just because it was coded or visually designed. It must meet the agreed conditions that prove it works correctly, supports the intended business rule, and satisfies the original requirement. Acceptance criteria help product managers, developers, testers, and stakeholders align on the exact expected result. They reduce misunderstanding, prevent subjective approval, and create a strong connection between development output and business expectation.

Examples

• The customer registration feature will be accepted if a user can create a new customer record, mandatory fields are validated, invalid input shows an error message, and the saved customer appears immediately in the customer list.
• The lesson progress feature will be accepted if a student can mark a lesson as completed, the progress percentage updates automatically, the dashboard reflects the new status, and the progress remains saved after the user logs out and logs in again.

After completing a thorough business requirement analysis using the Digital Product Business Canvas, the next step in the CaDPM™ Guide is UI design. The UI Canvas is a structured format designed to bring together all key players — UI Designers, Developers (frontend, backend, mobile), QA Engineers, Architects, Product Managers, Business Teams, and AI Agents — into one unified communication space.

The UI Canvas plays a vital role in eliminating the Communication War between business and technical sides. It ensures that everyone communicates using the same framework — the Technical Language of Digital Product — improving clarity and reducing misinterpretation at every stage.

One of the core principles of the CaDPM Guide is Communication over Visualization. The UI Canvas empowers teams to collaborate visually, enabling 100% alignment between stakeholders and AI Agents by translating ideas into clear visual representations.

Since a digital product is typically made up of multiple pages — 20, 50, 100, or even more — a separate UI Canvas should be created for each page. This ensures detailed, page-level clarity throughout the design and development process.

While many AI Agents can generate basic page views from business inputs, these views alone are not enough for deep collaboration between teams. The UI Canvas provides the shared structure and visual detail necessary for smooth coordination across all roles throughout the entire Digital Product Pipeline Management.

The UI Canvas consists of three main parts:

• Canvas Description
• UI Visualization
• Inputs and Descriptions

The Canvas Description provides a high-level overview of the entire page's user interface design. It summarizes the purpose and structure of the digital product page, including the key input components, their descriptions, intended functionalities, and how they relate to the Solution Concept from Stage 1.

The Canvas Description also plays a crucial role in working with AI Agents. It can be used as a structured prompt to generate or assist with:

• Initial UI visualization of the page to understand the overall layout.
• Draft UI design elements for fast prototyping.
• Suggestions for improving usability and accessibility.
• AI-generated code scaffolding for frontend implementation.
• Documentation drafts for developer handover.

The UI Canvas includes a standardized list of core components that can be used across digital product pages. These components help teams describe page structure with a shared visual and technical vocabulary.

Table 5 below summarizes the 16 core UI components and explains where each one is commonly used.

Table 5. The List of 16 Components

Designing a page is not only about placing UI components — the most important part is defining the inputs: the fields that collect or display data. If a digital product handles over 3,000 inputs — such as customer details, payments, logistics, performance, employees, authentication, and more — these inputs must be thoughtfully distributed across pages in a logical and business-related structure.

While AI Agents can often suggest suitable inputs for each page, the real challenge is teaching them the relationships between inputs. AI Agents do not automatically understand how your business works. You must train them properlyto get meaningful, usable results.

Here are the key factors to consider when designing input fields for your pages:

• Input Name: What kind of data is expected? (e.g., Student Name, Document Type, Product Name)
• Input Order: Inputs should be arranged based on their priority, requirements, and importance. This improves usability and guides users logically through the form.
• Input Width: Space matters — especially on mobile and tablet screens. Designing inputs with appropriate width helps maintain a clean and user-friendly layout.
• Component Type: Choose the right input component (e.g., text box, date picker, select box). This helps both users and AI Agents understand whether data needs to be collected or displayed.
• Input Content: Inputs often need initial values or options (e.g., country list, city names, payment types). This makes the input field clear and avoids Communication War.

All of these details are essential when prompting or training AI Agents.

Each input must also include a clear business and technical description. This ensures everyone — human and AI — understands its purpose and how it fits into the system. These descriptions must not be placed in the Canvas Description section. The Canvas Description covers the overall page; input descriptionsshould focus on specific fields.

A template of common input descriptions is given as below:

• Is Mandatory – Field must be filled before submission.
• Is Unique – Value must be unique across entries.
• Is Editable – Field can be changed by the user.
• Is Not Editable – Field is locked and cannot be modified.
• Is Integer – Accepts only whole numbers.
• Is Float – Accepts decimal numbers.
• Is String – Accepts text input.
• Is Dropdown – Enables dropdown selection.
• Is Readonly – Visible but not editable.
• Is Current User – Automatically sets value to the current user.
• Is Current Date – Sets the default value to the current date.
• Is Current Time – Sets the default value to the current time.
• Is Minimum Value – Marks this field as the minimum value in a range.
• Is Maximum Value – Marks this field as the maximum value in a range.
• Is Row Count – Automatically counts rows (e.g., in tables).
• Is Average Value – Calculates average value of related inputs.
• Is Summary – Shows a summary or total field.
• Close After Click – Closes the window after user interaction.
• Disappear After Click – Hides the field/component after it is clicked.
• Maximum length is – Sets a maximum number of characters allowed.
• Minimum length is – Sets a minimum number of characters required.
• Minimum value is – Sets the lowest numeric value allowed.
• Maximum value is – Sets the highest numeric value allowed.
• After redirect to – Defines the page to redirect after form submission.
• Default value is – Pre-fills the field with a default value.
• Successful message is – Message shown after successful action.
• Warning message is – Message shown for warnings or incomplete input.
• Error message is – Message shown for invalid or failed input.
• Placeholder is – Hint text displayed inside the field before typing.
• Minimum selected item count is – Minimum number of items that must be selected.
• Maximum selected item count is – Maximum number of items allowed to be selected.
• Date format is – Sets the date input format (e.g., MM/DD/YYYY).
• Time format is – Sets the time input format (e.g., HH:MM AM/PM).
• Mask is – Input pattern or formatting mask (e.g., for phone numbers).

To train AI Agents effectively and avoid miscommunication within development teams, using the Technical Language of Digital Products is essential. This technical understanding allows teams to create a more detailed and precise UI Canvas.

The DP UI Canvas can be extended by adding key technical connections, such as:

• Related database tables and fields connected to each input
• Data flow direction (sending or receiving)
• API relations for each input field
• Event actions (e.g., load, click, change, mouse move) — especially important in the description of button components

Defining input-to-database field mappings is critical for understanding how data moves across the system. This is not only useful for software engineers and system architects but also helps AI Agents build more accurate systems.

Adding precise API integration details — including endpoint names, request/response structure, and supported formats like JSON or XML — gives AI Agents the context they need for better code generation. Without this technical information, many AI Agents struggle to generate functional source code due to missing details about dependencies, third-party integrations, authentication methods, and data formats.

By including this kind of structured, backend-focused detail within the UI Canvas, teams can dramatically improve the communication quality within the Communication Ring and reduce misunderstandings during development.

Before starting any development, the Backlog — a clear list of tasks and issues — must be fully prepared and well-structured. In the CaDPM Guide, this backlog ensures smooth collaboration between AI Agents and development teams.

The Backlog Canvas allows both AI Agents and human developers to collaborate efficiently using a shared structure and terminology — the Technical Language of Digital Product.

Typical issue assignments in CaDPM are as follows:

This structured issue breakdown, built directly from the DP UI Canvas, helps avoid miscommunication and prevents delays during the digital product development pipeline.

The structure of the Backlog Canvas is shown in Figure 6.

In the CaDPM™ Guide, each issue recorded in the Backlog Canvas must be clearly defined and linked to the appropriate element in the UI Canvas — particularly inputs and input descriptions. This precision ensures effective communication, accurate time estimation, and correct implementation by both human developers and AI Agents.

Types of Issues

• New Request: When a UI Canvas is being developed from scratch.
• Change Request: When updates are required during the development process, such as:

• Adding/removing inputs
• Renaming inputs
• Adding/updating/removing input descriptions

Issue Relationships and Guidelines

• Every issue must have a direct relationship with the UI Canvas.
• Input-related change requests must be clearly linked to the Input Name.
• Input description issues should refer specifically to the Input Description in the canvas.
• Only architectural, testing, or UI design tasks may be independent of specific inputs.
• Each Input Description should be recorded and assigned as a separate issue.
• Input-related issues may have multiple Assigned Teams (e.g., backend, mobile, QA).

API issues should include:

• Input and output parameters
• Expected operations and logic
• Data format (e.g., JSON, XML)

Time Estimation and Performance Tracking

Since issues are defined at a granular level (per input or API), time estimation becomes easier and more accurate:

• Each issue, even those handled by AI Agents, should include Maximum Spent Time (MST) for review, control, and validation.
• On average, MST may range from 2 to 6 hours, with a default of 4 hours being suitable for most projects.
• Weekly or bi-weekly performance tracking should be applied to all roles in the Communication Ring.
• Spent hours per issue helps estimate total time for completing a full UI Canvas.
• Tracking historical data across canvases improves overall performance monitoring for both teams and individuals.

Once the Digital Product Backlog Canvas and UI Canvas are completed, it becomes possible to prepare a detailed User Acceptance Checklist. This checklist serves as a structured roadmap for evaluating deliverables and ensuring every issue is completed, reviewed, and handed over correctly.

This checklist serves as a structured roadmap for evaluating deliverables and ensuring every issue is completed, reviewed, and handed over correctly — whether handled by development teams or AI Agents.

Purpose

The User Acceptance List provides a clear, traceable path from requirement to implementation. It is used to:

• Ensure each UI component and input has been developed according to its specification in the UI Canvas
• Confirm that every task in the Backlog Canvas has been completed and meets the defined Acceptance Criteria
• Help product managers, business teams, and testers validate functionality before final approval
• Serve as a handover checklist from AI Agents and developers to the business team

Acceptance Checklist Should Include

• All inputs (fields, buttons, components) are visually implemented as shown in the UI Canvas
• Each input has the correct component type, label, order, width, and initial content
• All inputs are tied to their functional descriptions, including business and technical explanations
• Corresponding API connections and database field relations are implemented as described
• Event actions (click, change, load, etc.) behave exactly as specified
• Each issue from the Backlog Canvas is marked as completed and tested
• All Change Requests are verified and reflected in the UI
• The page functions correctly across mobile, desktop, and tablet views
• Testing results (manual or automated) show that issues have been resolved
• AI Agent-generated output (code, content, layout) is reviewed and validated by a human

Final Handover Approval

Once all items in the User Acceptance List are verified, the page or feature is marked as Accepted. Only after full acceptance is the issue officially closed and handed over as “Ready and Working”.

This structured, visual-based acceptance flow ensures clear communication across the Communication Ring and avoids ambiguity — a core goal of the CaDPM Guide.

Once the UI Canvas, Backlog Canvas, and the User Acceptance Criteria are clearly defined and confirmed, the development process can officially begin. At this point, the entire Communication Ring — including AI Agents and development teams — is aligned and ready to build the digital product.

The preparation done in the earlier stages ensures that:

This strong foundation eliminates communication gaps and minimizes rework, making the development process faster, clearer, and more efficient.

Development Process Flexibility. At this stage, any software development methodology can be applied based on the team's structure and product nature, including:

Key Outcomes of This Stage:

Digital Product Monetization helps you see the scalability potentialof your digital product. In today's cloud-driven world, understanding how many users might use your product — and when — is critical for resource planning, infrastructure scaling, and architecture design.

This part of the canvas provides a clear strategy for entering the market by estimating the size of your customer base, planning how to reach them, and deciding how your product will generate revenue. It also helps align business expectations with the design and development process — especially when working with AI Agents and development teams.

It also helps define the go-to-market strategy, communication channels, and business models, including how you'll reach the customers and earn revenue. These factors often influence system architecture, especially when integrations with partners, platforms, or third-party services are needed.

Monetization Canvas Table

The final steps of the CaDPM™ pipeline focus on converting the built product into revenue by creating structured customer acquisition channels.

This document defines the official engineering architecture standard for DPS frontend development. DPS operates as a multi-product ecosystem consisting of four independent product universes: Public, Education, Coach Console, and Course Creator. Each universe is architecturally isolated — there is no shared server state, no shared API layer, and no cross-module data dependency.

This standard ensures: clear module boundaries, query isolation, scalable architecture, predictable development, zero cache contamination, and clean engineering governance.

Each product universe is treated as an independent system inside a single frontend application. This is the foundation of everything CaDAF™ enforces.

Each product universe has its own route prefix, shell component, and dedicated QueryClient. The mapping is fixed:

Each product universe must have its own QueryClient instance defined as a singleton. QueryClients must never be shared across universes.

import { QueryClient } from "@tanstack/react-query";

export const publicQC  = new QueryClient();
export const eduQC     = new QueryClient();
export const coachQC   = new QueryClient();
export const creatorQC = new QueryClient();

Each universe must be wrapped in its own QueryClientProvider inside a dedicated Shell component. The Shell is the architectural boundary.

export default function EducationShell() {
  return (
    <QueryClientProvider client={eduQC}>
      <EducationRoutes />
    </QueryClientProvider>
  );
}

6.1 Application-Level Structure — each module is a sealed boundary. No cross-module imports of api/, queries/, or mutations/.

src/
  app/
    router/
      AppRouter.tsx
    providers/
      queryClients.ts
    shells/
      PublicShell.tsx
      EducationShell.tsx
      CoachShell.tsx
      CreatorShell.tsx
  modules/
    public/
      api/  queries/  mutations/  pages/  components/
    education/
      api/  queries/  mutations/  pages/  components/
    coach/
      api/  queries/  mutations/  pages/  components/
    creator/
      api/  queries/  mutations/  pages/  components/

6.2 UI Canvas Folder Structure — every ui-canvas/uic_<canvas_name>/ directory must follow this fixed internal structure:

ui-canvas/uic_<canvas_name>/
  components/    → UI components (Table, Drawer, Modal, Form)
  hooks/         → React state and effect logic
  handlers/      → UI event orchestrators (onClick/onSubmit → calls service)
  services/      → Clean async functions for Firebase/API (no UI dependency)
  configs/       → Table columns, form fields, and static config objects
  utils/         → Pure helper functions (format, normalize, map)
  types/         → TypeScript interfaces and types (1 file = 1 type)

7.1 The Golden Rule: 1 File = 1 Export. Every function, method, interface, or type must live in its own file. In a large codebase, search, refactoring, ownership, testing, reuse, and import management are only predictable when each file has a single, clear responsibility.

getActiveProjectById.ts
→ export async function getActiveProjectById(...){}

UploadedFile.interface.ts
→ export interface UploadedFile {}

backlogService.ts
→ 10+ functions inside

createIssueTypes.interface.ts
→ 3 interfaces inside

7.2 File Name = Export Name (100% Match). The file name must exactly match the name of the exported entity.

7.3 Naming Conventions by Layer:

8.1 Handler — UI Event Orchestrator. A handleXXX function manages only UI events and state. It must not contain data-access logic. A handler: sets loading state, shows messages, calls a service, handles errors, updates UI-relevant mappings.

// handleBatchAddCommits.ts
export const handleBatchAddCommits = async (e: React.MouseEvent) => {
  setLoading(true);
  try {
    await serviceCreateCommits(data);
    message.success("Commits added.");
  } catch {
    message.error("Failed to add commits.");
  } finally {
    setLoading(false);
  }
};

❌ A handler must never behave like a service (no direct Firestore/API calls).

8.2 Service — Data Access & Integration Layer. A serviceXXX function handles only data retrieval and persistence. It must not interact with UI. A service: executes Firestore queries, makes REST API calls, returns data.

// getActiveProjectById.ts
import { db } from "@/config/firebase";
import { doc, getDoc } from "firebase/firestore";

export async function getActiveProjectById(id: string) {
  const docRef = doc(db, "ui_canvas", id);
  const docSnap = await getDoc(docRef);
  return docSnap.exists() ? docSnap.data() : null;
}

❌ A service must never use: message.success/error, setLoading, setState, DOM events, AntD or any UI components. Avoid id: any — use string as the minimum type constraint.

8.3 Utils — Pure Functions. Utils contain stateless, UI-independent helper logic: formatting, parsing, normalizing, mapping.

// utilFormatDate.ts
export const utilFormatDate = (date: Date): string => {
  return date.toISOString().split("T")[0];
};

Even though QueryClient instances are isolated per universe, namespace-based query keys are mandatory for DevTools clarity.

11. API Layer Governance. Each universe must maintain a completely isolated API layer. No API function may be reused across universes. No shared baseURL across universes. Each universe manages its own authentication strategy.

modules/education/api/*
modules/coach/api/*
modules/creator/api/*
modules/public/api/*

12. Authentication Isolation. If authentication exists in multiple universes, token storage must be namespaced:

13.1 No Method Passing via Props. In CaDAF™, passing functions (callbacks) as props between components is forbidden. Only data (string, number, object, array) may be passed as props. This prevents prop drilling and enforces component isolation.

const CreateIssue = ({ handleSave }) => {
  const data = getData();
  return (
    <button onClick={() => handleSave(data)}>
      Save
    </button>
  );
};

const CreateIssue = () => {
  const data = getData();
  const handleLocalSave = () => {
    serviceCreateIssue(data);
  };
  return (
    <button onClick={handleLocalSave}>Save</button>
  );
};

13.2 The Silent Component Principle. “Components must be deaf and mute.”

14.1 Action Naming Convention. Format: [Universe] / [Module] / [Action Name]

EDUCATION / COURSE_LIST / SET_LOADING
COACH / STUDENT_DRAWER / OPEN

SET_DATA
SET_LOADING

14.2 Store Isolation — Universe Slicing. Each product universe must have a dedicated Redux slice. One universe must never read another's state.

// src/app/store/slices/educationSlice.ts
export const educationSlice = createSlice({
  name: 'EDUCATION',
  initialState,
  reducers: {
    setCourseData: (state, action) => {
      state.courses = action.payload;
    }
  }
});

14.3 Dispatch Over Method Propagation. Golden Rule: If a parent component needs to know about a child's action, the child dispatches a Redux action. The parent listens via a selector. No method is passed down.

15.1 Conditional Rendering Over CSS Hiding. Never hide components with CSS — this keeps the component mounted, Firebase listeners active, and resources consumed. Always use conditional rendering.

<Component style={{ display: 'none' }} />

{activeTab === 'target' && <Component />}

15.2 Always Return a Cleanup Function. Every useEffect that creates a Firebase listener must return an unsubscribe function.

useEffect(() => {
  const unsubscribe = onSnapshot(ref, (snapshot) => {
    // handle data
  });
  return () => unsubscribe(); // cleanup on unmount
}, []);

15.3 Persist Data in Redux, Not in Component State. When a component unmounts, its local useState data is lost. To preserve data across tab switches:

15.4 Global Drawer Pattern. “One Drawer per application, not one Drawer per row.” Place a single central Drawer at the application level and pass only an ID as a prop. The Drawer's content updates as props.id changes.

The following are strictly forbidden. Violation of these rules results in architectural contamination.

17. Refactoring Reference — Service Decomposition.

backlogService.ts → 10+ functions

services/
  getActiveProjectById.ts
  getApiCanvas.ts
  getApiJson.ts
  getTasks.ts
  subscribeTasks.ts
  createIssue.ts
  getTaskById.ts
  editComment.ts
  updateDescription.ts
  updateClosedDate.ts

19. Standard of Acceptance. A contribution is accepted when it:

All components and their sub-components within a UI Canvas must be named in a clear, structured, and hierarchical manner. Each sub-component must explicitly include the name of its parent component to ensure traceability and consistency.

Format: [ParentComponent] - [SubComponent] or [ParentComponent] / [SubComponent] or [ParentComponent]_[SubComponent]

Header - Logo
Header - Navigation
Header - Profile Menu
ProductCard / Image
ProductCard / Title
ProductCard / Price
ProductCard / Action Button
DashboardHeader_NotificationIcon
DashboardHeader_UserMenu
Sidebar_MenuItem
Sidebar_SubMenuItem

Button
Title
MenuItem

This naming convention improves structural clarity, enhances readability of the UI architecture, and ensures consistency across the UI Canvas. It also simplifies communication between design, development, and product teams.

All files inside any types/ directory must use PascalCase naming. Type definitions are considered domain models and must follow a single consistent naming style.

ComponentJson.interface.ts
→ export interface ComponentJson {}

MotionProps.interface.ts
→ export interface MotionProps {}

Actions.ts
→ export const Actions = [...]

componentTypeLabel.ts
actions.ts
motionProps.interface.ts

To monitor digital product development in a more measurable, structured, and execution-focused way, Canvas-Driven Project Execution (CaDPE™) indicators have been developed. These indicators make it possible to evaluate the real status of project execution not only through subjective updates, but through numerical, AI-supported, and canvas-linked measurements.

In many projects, managers and stakeholders can see tasks, screens, backlog items, and commits, but still cannot clearly answer: How much of the project is actually completed? How much work is still remaining? How close is the code to the original requirement? How realistic is the completion forecast? CaDPE™ is designed to answer these questions with greater precision.

The main purpose of CaDPE™ is to connect UI Canvases, API Canvases, Backlog Canvases, user activity, and delivery outputs into one measurable execution system. CaDPE™ is especially important in AI-supported delivery environments, where engineers work with tools such as ChatGPT, Gemini, Claude, and similar AI coding assistants. Speed alone is not enough — what matters is whether code volume, execution progress, estimated completion, and requirement alignment can all be tracked in a structured way.

Estimated Code Lines is the indicator used to calculate approximately how many lines of code the project is expected to require based on the defined UI Canvases and related product structure. This estimation is generated with the help of AI agents and is intended to provide an early technical size projection before the project is fully developed.

The value of this indicator lies in helping the team understand the likely engineering scale of the product at an early stage. Instead of waiting until implementation begins, the project can be evaluated in advance from a technical effort perspective. This gives product managers, engineering managers, and stakeholders a clearer sense of expected workload and delivery size.

For example, if a project contains a large number of UI canvases, data-entry forms, tables, role-based workflows, API integrations, and state management logic, AI agents can help estimate the approximate code volume required. This does not produce an exact number, but it creates a realistic technical baseline for planning.

In CaDPE™, Estimated Code Lines serves as one of the first measurable execution anchors. It helps define the total expected development body and later becomes the reference point for measuring actual progress, remaining work, and estimated completion.

Developed Code Lines is the indicator that shows the total volume of real code written and committed by engineers during the development process. In other words, it represents the actual development output produced across the project with or without AI assistance.

This indicator is important because it transforms development activity into a measurable execution signal. Instead of relying only on statements such as “the task is in progress” or “the feature is almost done,” the team can examine the actual written code volume connected to the project. This creates stronger visibility into delivery progress.

In a canvas-driven system, Developed Code Lines can be linked to Backlog Canvas items, task completion records, commits, and associated UI Canvases. This makes it possible to understand which parts of the defined product scope have already received engineering implementation and which parts remain untouched or only partially developed.

Remain Code Lines is the indicator that shows how much of the estimated project code volume is still unfinished. It is calculated as the difference between Estimated Code Lines and Developed Code Lines.

This indicator is one of the most practical execution measurements in the CaDPE™ model because it gives a direct view of the remaining technical workload. It helps the team understand how much implementation effort is still expected before the project reaches its planned delivery scope.

For example, if the project is estimated to require 20,000 lines of code and only 8,000 lines have been developed so far, then 12,000 lines remain. This remaining volume can then be analyzed together with team speed, sprint capacity, AI-supported development acceleration, and backlog readiness to make more realistic forecasts.

Remain Code Lines is especially useful for planning the next stages of delivery. It supports workload estimation, sprint discussions, engineering capacity planning, and management reporting. More importantly, it gives product and delivery leaders a clearer understanding of whether the current pace is sufficient to meet expected deadlines.

Estimated Completion is the indicator used to forecast the approximate project completion timeline by evaluating the remaining code volume together with the team's AI-supported development speed. Its purpose is to transform current execution data into a realistic projection of when the project may be completed.

In many projects, completion dates are often set based on assumptions, pressure, or rough planning. CaDPE™ improves this process by connecting completion forecasting to measurable technical signals. When the team knows how much code has already been developed, how much remains, and how fast the team is delivering over time, the completion forecast becomes more grounded and credible.

This indicator is highly valuable for delivery communication because it helps stakeholders understand whether the project is moving toward completion at a sustainable pace or whether delays, bottlenecks, or scope issues are likely to affect delivery. It also helps delivery managers identify whether more resources, AI assistance, backlog clarification, or technical simplification may be needed.

Project Requirement Alignment is the indicator that measures how closely the development output matches the requirements originally defined in the UI Canvases. It evaluates the relationship between the specified requirements, the related commits, and the code lines written for each canvas or requirement group.

This indicator is critical because a project cannot be considered successful only because code has been written. The code must also reflect the intended business logic, user flow, functional expectations, and requirement details defined earlier in the product pipeline. Without alignment measurement, a project may appear technically active while still drifting away from what was actually required.

In CaDPE™, this indicator helps answer a deeper question: Is the team building the right thing, not just building fast? It compares delivery output against the requirement source, making it possible to see whether a canvas has been properly implemented, partially covered, weakly matched, or still requires review.

For example, if a UI Canvas defines a table view, filter controls, role-based visibility, and save logic, the alignment indicator helps examine whether the related code and commits truly reflect those conditions. If the result is weak or incomplete, the system can mark the canvas as requiring attention or further evaluation.

In addition to the five main indicators, the CaDPE™ dashboard includes several supporting execution signals that improve project visibility.

The following terms are used throughout the CaDPM™ Guide. Understanding them is essential for using the framework effectively across all role-profiles.