IIP-130: Redesign of Product Onboarding Process - Jan 2022

Status: Proposed
Author(s): Product Working Group
Created: 24th January 2022

Simple Summary

As our product team takes more ownership of our roadmap it is unnecessary and adds additional overhead to have two Decision Dates. This process was necessary when Index Coop first launched to ensure it devoted effort on products the community thought would be successful. The new PWG onboarding process provides a higher degree of confidence that the products being built will help IC achieve its organizational goals. Because of this, we request that the DG1 step be eliminated from the onboarding process.

In some circumstances a batch of products may be put through this process if things like market opportunity, technical requirements and launch parameters are similar. An example of this would be the FLI products.


When Index Cooperative launched it didn’t have a robust product department performing standard functions such as:

  • Managing a roadmap and backlog of product ideas
  • Brainstorming product ideas
  • Performing market research
  • Developing a long-term strategy (eg which products should we focus in 3, 6, and 12 months)
  • Analyzing underlying liquidity for feasibility
  • Performing in-depth technical analysis to develop product solutions
  • Engaging with external protocols to build innovative products
  • Maintaining Profit & Loss (P&L) metrics
    • This is a new capability we’re spinning up to ensure each product has a profitability roadmap.
    • For reference, at DPI’s currently AUM it would take ~7 years to recuperate operational cost required to grow the product


As we take more ownership of our onboarding process we have a higher degree of certainty over the success of each product. We also don’t have as many financial negotiations (fee split, capital spend, etc.) that varied drastically and required community feedback.

In order to streamline the onboarding process we’d like to remove some of the overhead required to get products out the door. Each product will still go through a rigorous review but most of this work will now be completed prior to being presented to the IC community.


Our pod and PWG team have gained the skills and have set up the process necessary to ensure the highest quality products make it to market.

Some functions that might have required additional community approval, such as liquidity spend and fee splits, have been largely taken out of the product process. The liquidity pod now manages the capital spend necessary to launch products. The Compensation Framework also outlines the standard fee split to individuals working directly on each product. The only negotiation piece is the fee split with branding partners, which we would also like to standardize.

Removing DG1 allows the team to spend more time focusing on the critical pieces of the onboarding process rather than supporting two decision gates by the community.


The original onboarding process was necessary because we needed a way to vet product ideas before considerable effort is being spent to develop each product. When an external methodologist would approach us with a product idea, we had no idea how successful a potential product would be in our portfolio.

DG1 was a way to approve or reject a product idea before all aspects of development were researched. PWG was on the hook for all work pre- and post-DG1

The old onboarding process looks as follows

  • Agree on Commercials with methodologist to establish the fee split, where to launch, how much capital is required to launch and how much to spend on incentives
  1. Final Work Team Assessment completed by third-party team to provide an overall ‘success score’ based on final PRD and Financials
  2. DG2 - signifying whether the community thinks EWG should build the product given the technical requirements, commercials/financials and success score
  3. If DG2 is passed EWG begins building the product
Step Name Description Shared
1 Receive product idea External methodological approaches us with a product idea Internally
2 Initial review PWG does an initial review for obvious challenges with the product Internally
3 Forum Post Methodologist post the product idea to the forums Publicly
4 Community Call methodologist can introduce themselves and describe their methodology Publicly
5 Work Team Assessment Initial Work Team Assessment (WTA) completed by third-party team to provide an overall ‘success score’ Publicly
6 DG1 Community votes on whether PWG should commit more time to this idea Publicly
7 Product Requirements Document Develop PRD to outline all technical requirements EWG would need to build the product Publicly
8 Commercials Agree on Commercials with methodologist to establish the fee split, where to launch, how much capital is required to launch and how much to spend on incentives Publicly
9 Work Team Assessment WTA completed by third-party team to provide an overall ‘success score’ based on final PRD and Financials Publicly
10 DG2 Community votes on whether they think EWG should build the product given the technical requirements, commercials/financials and success score Publicly
11 Build & launch product Work with GTM Manager and EWG to build the product Publicly

By PWG taking control of the roadmap they will have a much better understanding of market opportunity (success score), profitability (financials/commercials) and technical requirements (PRD) prior to announcing it to the community.

The new onboarding process I’m recommending looks like:

Step Name Description Shared
1 Product ideas prioritized on product backlog Brainstorm product ideas as a pod and perform market validation. Prioritize based on market opportunity Internally
2 Research high priority product ideas Initial smoke test performed on products deemed to have a high market opportunity. This includes a review of underlying liquidity and technical overview (eg are all tokens in the sector ERC-20, or another token we don’t yet support) Internally
3 Develop initial composition Once product ideas pass the above steps the product designer works with the Quant to develop an initial composition and share it with the community Publicly
4a Develop PRD Product designer and Quant work with external protocols and EWG to develop the PRD. This provides an estimate for development Publicly
4b Find Branding Partner Pod works to find a branding partner that meets the narrative of this new product. This may require some negotiation depending on the partner but fee splits should largely be set Publicly
4c Internal Fee splits Unnecessary as those are predetermined Pod Comp Framework
5 Work Team Assessment Work Team Assessment completed by third-party to provide and unbiased success score Publicly
6 Request DG/IIP Request approval from community to build Publicly
7 Build and launch product Work with GTM Manager and EWG to build the product Publicly



  • Remove DG1 from product onboarding process


  • Keep DG1 from product onboarding process

Hi @Mringz can I please schedule this for snapshot.

Gm DocH. I very much like the new streamlined approach. I have 1 (hopefully constructive) comment and 2 questions.

I think the branding partner should be engaged much earlier at around stage 3 since they will hopefully have important input on the composition, their early buy-in is key, and the fee-split negotiation could get protracted and hit the critical path. Stage 4b could then be used to confirm the branding partner’s role and fee-split.

My questions are which roles will be responsible for marketing research and raising the seed funding? I think the marketing research is currently with PWG but is there an argument for having it with Growth since they’re much closer to the customer? Also is securing the seed funding the responsibility of the Product Manager, the GTM Manager or the liquidity pod? I think this is currently a major gap, particularly given how centrally important launch AUM and liquidity are for the success of the product. Other than that I think the new process is excellent and I’m looking forward to working with you to make it a great success.


Hey @DocHabanero ,

Really excited for 2022, and supportive of removing any friction for Product in the onboarding process. Will be voting for your recommendations.

Had a few questions:

  1. As we become more proactive with product idea vetting and selection, what is the impact on external methodologist’s coming to us with ideas, and the community being involved in the selection process? Is Product deciding a concrete roadmap and backlog? If DG1 is removed, is there a way for the community to suggest themed ideas or show support for potential products pre-vetting? I’m personally confident Product Nest is best positioned to make the call on product suitability/validation, just wondering if there’s an impact on closing the loop.

  2. I might be out of the loop here, apologies if this was explained somewhere else, but what exactly is a ‘branding partner’? Does this mean we are becoming the methodologist, and then seeking out an external branding partner to collaborate with on the product?

  1. This is Go To Market Manager right? Who has traditionally filled this role? Is it internal, what does it involve?
  1. We’d (Community Nest) love to see an official step in the process (right between steps 5 and 6) - Community Mobilisation : Which would involve us (in collaboration with Product + Growth) preparing a more strategic roadmap to engage the community.

Love your work @DocHabanero

It’s an interesting point on when to approach branding partners. On the one hand we want them to provide feedback on the composition, but could slow the process down and could degrade the quality. Given you and I have a few products coming down the pipeline let’s test this out.

It’s a great question. I view market research by product as a way to uncover customer needs. Whereas marketing led research validates value propositions and messaging. Ultimately I don’t have a strong opinion as long as the research is being done. This could also could be a function of the pod so multiple provide input on the process.

The current idea is to have the liquidity pod provide seed funding. In the short-term this shouldn’t cause issues. As we scale and launch more products we’ll need more capital. This means we either need to find more capital (more of an IC than Pod task), or figure out how to launch products with less capital (PWG capability). This will be a core capability we think about when developing products. If capital becomes an issue I’ll work with IC on a long-term strategy.


Great question! We’ll always provide a way for external methodologist, or community members to approach us with product ideas. We’re working on a compensation package that carves out this capability. What we’ve noticed over the last year tho, is very few novel ideas have been brought up.

That’s exactly right. We spend a considerable time training external methodologist. Now that we have so much expertise in house it makes sense to develop the products ourselves. We’ll then find a strong brand that matches the product narrative. It allows us to keep a larger portion of the streaming fee while paying out a more fair evaluation of the expertise we provide.


I recommend we keep DG1. It would be very wasteful and time-consuming to go through the entire process of PRD, branding partner identification and negotiations, WTA, etc, only to be voted down at DG2 with no feedback and no opportunity for revision. DG1 gives the project an early go/no-go decision, hopefully feedback from our largest tokenholder/s, and the opportunity to incorporate that feedback into a better proposal for DG2 or an alternative product.

I believe it is sensible to eliminate DG1 given the increased ownership taken by each of the nests/verticals and DG1 not being fit for purpose as the DAO and onboarding process has evolved. DG1 causes unneeded time spent on tasks that are now covered by the product department. While only on DG seemingly does not leave room for feedback loops, one can create another type of early feedback loop that does not constitute a DG, to solve for the problem related to incorporating feedback from largest tokenholder(s)

What would this process be? And why would it be more efficient than a DG1 Snapshot vote?

@Mringz @mel.eth can we please schedule a snapshot vote for next Monday.

1 Like

Hey @DocHabanero, an IIP Number (130) has been assigned and snapshot vote has been queued for later today at 1800UTC.
Snapshot here

1 Like

@DocHabanero sorry if I am asking a question that is public somewhere else that I missed. Is this Compensation Framework the Product compensation that was proposed last week on the Feb 2 Leadership Forum detailing the fee split for the quant, product manager, gtm manager etc?

That’s correct! I’m working on posting that for more feedback. Should have that out today.

Confirming that this IIP has passed with 279.5K INDEX (99.46%) voting FOR. :white_check_mark:

1 Like

Update: PRDs will continue to be a critical step in the product development process, but they will not be shared publicly within product proposals.

However, they will be available to contributors upon request, per @DocHabanero 's comment on the FIXED proposal.

cc @mel.eth @sixtykeys