Product Onboarding Process Revamp

Product Products
1

Hi all,

As the product pipeline has grown, the Product Working Group has recognized that our current onboarding process is not scaling well or meeting the needs of our community, product team, or methodologists. We’re working on a project to revamp that onboarding process. Since this has a potential high impact on future projects and has been a frequent topic of discussion, I wanted to provide some background on what we’re solving for, our goals, and timeline. Feedback is, as always, highly appreciated and encouraged!

Problem Statement: The current product onboarding process does not provide methodologists with clear options and pathway to launch, particularly between DG1 and live. It is unclear what the engineering requirements and constraints are and what engineering prioritization looks like. Additionally, many members of the Coop are currently unclear on the launch process and current status of product launches. Products aren’t getting launched after the technical infra to scale is there.

Goals: Create clear, step-by-step guidelines for how products go from idea to on-chain assets at the Coop. Any crypto-native individual, whether they are a member of the Coop or not, should be able to read these guidelines and understand how the Coop evaluates and launches products. These guidelines should be the result of feedback from methodologists, the community, and the product & engineering expertise of various Coop members. These guidelines should both clarify existing expectations as well as clearly outline what is required from Product, Engineering, and Methodologists and give some expectation of timelines to launch various types of products.

Deliverables:

  1. Diagram/Flow chart of product launch process
    a. Status: In progress
  2. Revised Gitbook entry with highly detailed launch process
    a. Status: In progress
  3. Documentation on various levels of engineering complexity
    a. Note: This includes both the current matrix that engineering uses to score difficulty, as well as documentation created by Punia that details the technical requirements for previous launches, costs, and examples of what they might look like moving forward. The matrix will be instructional whereas the documentation will be educational.
    b. Status: Not started
  4. Documentation of roles/expectations for Product, Engineering, and Methodologists
    a. Status: In progress
  5. Roadmap for current products in pipeline
    a. Status: Not started, blocked by dependencies on prior items

In accordance with Coop and Product principles, we’ll look to show our work & take feedback as we go, and release deliverables as individual MVP assets when ready!

Proposed Timeline:

Week of 8/3:

Week of 8/10:

  • Post docs #1-4 on forum for feedback.
  • Incorporate feedback & create IIP (or forum poll) to get community buy-in.
  • With passing of poll / IIP, post updated versions to Gitbook

Weeks of 8/17-8/31:

  • Using updated docs, collaborate with EWG, Simple Indices, and Leveraged Indices pod on initial roadmap. Decide how frequently this will be revisited, what format it will take, who will maintain, and where it will live
16 Likes
2

Thanks @catjam ! This is a great step for us - let me know how I can help!

2 Likes
3

Hi Catjam. I would like to contribute towards the process design and documentation. Will DM you on discord. Thanks

2 Likes
4

As @CatJam said there are a number of things we are looking at to try and improve the process for methodologists / INDEXcoop and workgroups.

For me, the aim is to try and be clear about the process but also ask for more details from the methodologists so they can be agreed upon early and frozen by the time DG2 goes to vote. This includes specifying a number of activities to run in parallel between DG1 and 2:

  • Community discussion on the forum.
  • Work team assessment
  • Initial Product Requirements Doc (PRD) - This will attempt to freeze the launch specification and so allow EWG to make an informed assessment on the complexity of the product.
  • User fee / fee split / liquidity negotiations.

While we are still reviewing these and getting feedback from methodologists, I thought I would share some drafts.

The new product prioritisation rubric can be found here: Revised Product Scoring Chart

Draft revamped Process to DG1:

image
image594×738 84.2 KB

Revamped process to DG2

image
image588×731 88.6 KB

These diagrams are intended to become part of a revised gitbook entry on the whole process. A recent draft is here. INDEXcoop New Product Process 03Aug21 - Draft

Based on this approach, a new product tracker has been put together: INDEXcoop idea to DG2 tracker

1122×694 72.4 KB

Ongoing works

We are also looking at the following: Copies to be shared in the future.

  1. a modified IIP template for DG1 (/ DG2) to focus attention on the information required for a product launch.
  2. A tool to help methodologists and the community understand the engineering challenges/time requirements for different design decisions. (To be added to the git book)
7 Likes
5

@overanalyser @catjam

Great work on redesigning the Product Onboarding Process! From the perspective of a Methodologist, this is much needed and important work. Thank you for doing it. :smiley:

Here are some of my initial questions and comments:

  1. What is the Private Discussions section in row 2? What does blue (is this blue? I am colorbind) vs green mean? I’ve represented DATA in every PWG weekly meeting for the past 2 months and had 1-on-1s with both @puniaviision and @overanalyser so I was surprised/confused by the meaning of this row.

  2. I think the detailed, sequential process flow is a big improvement over the process, but I’d like to see more iteration and feedback. Does a successful DG1 vote and a failed DG2 vote mean that the product is permanently discarded? That doesn’t seem right to me. For instance, a DG2 vote is really a vote for the whole package (i.e. product, methodologist, liquidity strategy, engineering prioritization, etc.). A failed vote could mean lack of consensus around any individual element of the entire package. How do we incorporate community and tokenholder feedback at every step of the process to build consensus and overcome setbacks (i.e. failed DG1 or DG2 vote)?

Excited to talk 1-on-1 with @catjam this afternoon and also see the modified IIP template and tool to understand engineering challenges!

1 Like
6

Excellent questions!

Potential methodologists sometimes approach PWG members in private before they post on the forum and some times they don’t. I think it is a useful option for people. However, maybe we don’t need to track it…

Re: iterative loops, I think they exist, but we have not tried to explicitly state them in the flow (at least not yet).

1 Like
7

Hi @overanalyser and @catjam, this is a significant initiative contributing to IC’s growth and scalability. Also learning so much on the current and future states of the process from the steps, flowcharts, tracker and templates shared in a clear manner. Is there a template already in place for the PRD? If not, I would love to help create one. Also, would be happy to help in anyway possible.

4 Likes
8

Thanks so much @Alks4778 – I’ve dm’d you and @jcooper and am grateful for the help :slight_smile:

1 Like