Collateral Engineering Services Product Plan

Collateral Engineering Services Product Plan

In prior CES MIPs, we discussed the concept of collateral productization. We will be building on those concepts here and discuss the details of productization, or more formally known as product management, as it relates to our collateral.

As mentioned in MIP39, the CES Product and corresponding deliverables focus on the tools, technology, and documentation enabling anyone to onboard collateral. Following the Learn, Optimize, and Enable approach, the Product Plan and roadmap outlines the details on feature delivery and timing.

It is important to understand decentralized product management is a relatively new concept and builds upon the best practices of iterative software development. Where applicable, we will modify the processes to meet the unique requirements of working within a DAO and our community.

Where to focus?

At a meta level, collateral classes or types fit into two categories: 1) crypto native and 2) real world. Within each of these categories, we can divide them into their corresponding subcategories. For example, crypto native, ERC-20 tokens.

For the moment, the Product focuses on crypto native assets since the protocol has a strong understanding and experience with these collateral types. It is important to start with what we know, automate it, and apply that learning going forward to other assets like non-ERC-20, Layer 2, and real world.

Product and Collateral Priorities

To be clear, Product and collateral priorities are different. There is a subtle and distinct difference between the two.

Product priorities focus on feature delivery to help:

  1. Understand if a collateral has a business or strategic need as is relates to scaling the Dai supply

  2. Answer the “how to onboard collateral” need by providing tools, technology, documentation, and support

  3. Determine the incentive reward for onboarding a specific collateral type

  4. Reduce or eliminate Governance issues or bottlenecks

  5. Provide guardrails to ensure the stability and security of the protocol

  6. Understand the progress of scaling Dai

Collateral priorities utilize the Product features to help:

  1. Delegate the decision to the community on which collateral is the best to onboard

  2. Reveal/expose/present the risk/reward ratio for better contributor/implementer decision making

  3. Support the ongoing need of diversification of our collateral

  4. Address issues with volatility in the crypto native markets

  5. Ensure the Dai peg is maintained

The Product priorities help enable the collateral priorities and supports the CES Mission of decentralizing the collateral choices and implementation. It is important to understand CES focuses on the Product priorities and the Collateral priorities are the responsibility of the community and contributors.

Planning Concepts

Product Planning involves two key components: 1) Ideation and 2) Prioritization.


As a best practice, all products go through a phase where a ton of ideas are presented and somehow, a decision needs to be made on which features make the most business or strategic sense to implement.


Once we have a short list of ideas that are vetted by business or strategic viability, a prioritization is performed to understand what features deliver the most value to our customers.

The Product Planning concepts are introduced here to bring visibility into the process that we use to define the Product. There are entire disciplines, frameworks, and books written on both of these concepts. Overall, it is best to experience the concepts in action as we will be doing in the upcoming weeks and months ahead.

Product Planning

Now the fun begins. The starting point for the Product builds upon several artifacts:

  1. MIP6

  2. Diagram Overview of the Collateral Onboarding Process

  3. Introduction to MakerDAO Collateral Onboarding

  4. Collateral Status Index

  5. Collateral Framework Official

The Ideation and Prioritization process involves the following steps:

  1. Identify what we do today - This work is to ensure we understand the processes, technology, and tools in use today and discover our baseline Product delivery flow. Confirmation of the artifacts is important since the processes and documents might have been modified and we need to capture those changes for the baseline state.

  2. Identify what we think we need - With the goal of automating collateral management, we will do a gap analysis of the baseline vs. the future state. This results in an unordered list of functionality or features.

  3. Identify high-value items and key priorities - Based upon the prior step, we will take our list of features and determine which represent the highest value for the Product. Using the concepts behind Weighted Shortest Job First, each feature will be ranked to understand its importance to the Product.

  4. Build a high-level product roadmap - Since this will be our first iteration of a product roadmap, we will keep it very meta and give a general indication of the order of top milestones. The timeline will be better understood and communicated once we are able to commit resources to the actual work in the product backlog.

  5. Build a product backlog - The high-value items and key priorities will need to be broken down into smaller units of work and prioritized for the team. Much of this effort focuses on creating user stories which bring clarity to the details and allows the product and engineering team to know when something is complete (done-done).

  6. Iterative development - Knowing all of the above, the team will run two-week sprints to complete the work.

Please keep in mind this is a fluid, ongoing process. The product manager is continually working with stakeholders, refining ideas, reprioritizing work, and providing additional details for the user stories being developed or in-progress. All of this is refined down to support the goals of completing the current sprint and always have the most valuable work lined up for the next iteration. A lot of work goes into that effort.

Also, this is a transparent process and we will inform the stakeholders and community on an ongoing basis.

The last item to mention is that of metrics and reporting, both internal and external. The internal metrics are driven by the iterative software development process and are useful for the team but not so much for the community. Externally, as the product roadmap is developed, we will put in place meaningful metrics for the community to track the progress of scaling the Dai supply.

Next Steps

Now that a high-level plan has been developed, we will be working through the steps described above to implement this process. This is in preparation for CES ratification at the end of September 2021 and to hit the ground running with our new team hires.

Let us know if you have any questions or feedback. There will be more updates in the weeks ahead.