Proposal : Robot Index Working Group (RIWG) - **Temperature Check poll added**

Leadership & Governance Proposal
#4

I think this proposal deserves attention and hope to see many weigh in on this structure - we are setting another foundation for how we support internal products at the Coop.

I am trying to think into a future where we have many internal products launched - do all these products have their own working groups? It feels more likely that we will want a more modular structure…

For example - in the Organization section, we seem to be able to cover 3 of the 4 bullets with current working groups:

  • data analysis - AWG
  • marketing & growth - GWG
  • product development - PWG

The “Market Research” and rebalancing is really what we require a methodologist to bring to the table, whether they are internal or external. So maybe a better route is just look look at bringing rebalancing and market research capabilities into a structure like the Simple Indices Pod?

I think it makes sense to think about dedicated resources to market research (see below) for existing products and future products - maybe as a sub-function of PWG or AWG, or maybe its own WG?

In summary, I think it might make more sense to explore what it looks like to support this product with the fee split coming back to the Coop w/out actually creating a Working Group dedicated to one product. Looking forward, I am not sure this is the best foundation for internal products.

Looking forward to feedback on this!

4 Likes
IIP-89: Launch Polygon Diversified Index (PDI)
#5

As stated by JD, a more modular structure for product maintenance would be more ideal in comparison to a working group dedicated to just one product. We already have contributors more than capable of undertaking the work that needs to be done. Perhaps a better approach here would be to create something akin to the pods for leveraged products.

As to this point, I am also curious as to the type of work that will be funded by the streaming fee. Will Index Coop contributors who work on initiatives tied directly to the Robot Index come to you directly for compensation, or will the streaming fee only be used to compensate contributors working full time on the Robot Index?

1 Like
#6

@Monportefeuille would love to get your thoughts/feedback on my post! In my mind, making sure that you and any core conributors to iROBOT are compensated by the 30% fee split coming back, but doing it through the existing WG structures rather than having a singular working group for just one product.

2 Likes
#7

Hey @jdcook sure, thanks for keeping the discussion rolling and sorry about the late reply here ! I’ve been working on the final IIP until last minute to bring it to the forum tonight, but will now focus on a thoughtful and timely reply to your post :wink:

2 Likes
#8

Hey @jdcook really like the input, it’s an interesting idea for sure, especially the cross-functional approach of PODs makes a lot of sense. What’s still unclear to me, however, is where would this place Julien (or other internal methodologist)? Would they fall under the product WG? And I’m also not fully getting the compensation approach, would that go through a WG?

Having seen some of the work that went into the iRobot methodology, in my mind this product will require quite a fair bit of work for maintaining the methodology (namely the market research and maintenance of the data/formula). Hence, forming a WG focusing on this made a lot of sense to me. My understanding was that the work around product, marketing or analytics are more around coordination with the WGs, rather than doing everything isolated within the iRobot WG, but @Monportefeuille correct me if I’m wrong.

On the topic WG vs POD, I’m lacking context around PODs and would like to hear from people with more experience on this (tagging: @puniaviision @afromac @allan.g). Do you also think that PODs are a better fit for this purpose?
I suppose in the end it comes down to which set-up is more efficient for both the Coop and the methodologist, and how can we ensure fair compensation (incl. some upside on the product’s success) for the methodologist.

2 Likes
#9

Betting on past winners isn’t always good because it’s hard to distinguish luck from skill, i.e., volatility vs intrinsic performance. It would be helpful to show …

  • Momentum, ie, immunity to ‘reversion to the mean’
  • The stability of the allocations
  • That optimizing the Sortino ratio leads to a different allocation than optimizing the Sharpe ratio
3 Likes
IIP-71-Final : Launching the Robot Index (iRobot)
#10

Strongly agree to @jdcook 's thoughts. Based on my short experience collaborating with the Leverage Indices Pod as an AWG contributor, there are instances where I need guidance from other members of the AWG. So usually 1 person lifting the weight of a complete function like Analytics, Growth etc would not yield the best results for the Coop. I think a modular structure with a ‘Point of Contact’ in a specific product working group would be better, where the Point of Contact/representative of a WG would attend Product specific calls and stay updated on the progress on behalf of the WG.

6 Likes
#11

Hey @jdcook , @sixtykeys , @sidhemraj - thanks a lot for your interesting feedback !

I agree with JD that, besides the Robot Index, we’re trying to lay the foundations of an important framework, that will hopefully enable lots of innovative product ideas to pollinate within the community.

Maybe I should clarify that the idea of the RIWG is neither to substitute nor to vampirize the talents already at work in other Working Groups, but, as mentioned by @lavi, to coordinate the community’s efforts around the Robot Index in a transparent, accountable and incentivizing manner.

As such, the Working Group format provides at the moment the most clarity to me - but it may be due to a lack of context on the way that Pods are operating, that’s why I’m happy to be educated by @afromac and @Financial-Freedom.

From an operational point of view, it seems that the Pods format is effectively compatible with the activities listed in the proposal and how WG’s currently interact (interesting comment from @sidhemraj).

But, in my mind, it raises a number of questions on other topics that have been partially covered in @lavi’s post :

  • In which position does that leave the internal methodologist, both in the organization and in terms of compensation ?
  • How is he / she associated with the product’s upside ?
  • How do we keep track of the Pods funding ?
  • What are the metrics used to evaluate their performance ?
  • How is the reporting on these done ?
  • Aren’t conflicts of interest likely if further internal products are managed under this structure ? (ex. : the Simple Indices Pod is currently looking at our roadmap and product pipeline, I’m naturally biased towards iRobot :wink:)

Again, any feedback from the actual members of the Automated or Simple Indices Pods is welcome here (tagging @puniaviision & @overanalyser for PWG visibility).

4 Likes
#12

Let’s set up a call Julian. I’d be happy to talk through some of this stuff with you and see can I help.

6 Likes
#13

Hi @Monportefeuille,

Setting up a pod to manage a single product might be a good place to start, but I don’t think this a optimal scalable solution. I come at this problem from a different perspective.

If the product generates revenue for the methodologist and the methodologist wishes to distribute that to others for performing a task - that is great and 100% the methodologist call. I would think of this as a methodologist hirers freelancers to support the product and for this to be funded by the methodologist.

Rather than a working group, a partner could be engaged to provide such support with the added network benefits that come with a partner. PAY went this route. This was something suggest to me by @puniaviision as a way of boosting SYI potential and it was great advice.

Either way, I see the methodologist role as maintaining the product and providing input into mainly EWG and also other working groups. BDWG and GWG are key groups that drive AUM, distribution and integrations with defi.

I think the methodologist should be doing this and should only receive revenue and methodologist incentives. I don’t really see the need to add an alternative to this structure. This structure is clean, scaleable and easy to work with. It also means Index Coops has no cost exposure to supporting methodologists.

Forgoing the methodologist incentives is an interesting choice, I would encourage you to revisit that. The revenue and methodologist incentives should financially support the methodologist contributions for the product. This the best way to align incentives. Methodologist should be incentivised to grow the product and should not receive any contributors rewards or funding from Index Coop to perform methodologist role.

I think having an internally funded iROBOT pod/working group is not a good model, it just greys the lines to much. I don’t think Index Coop should be budgeting to pay methodologist when we have revenue splits and incentive programs. The cleanest way is to pay the methodologist via the programs we have and let the methodologist manage it from there.

5 Likes
#14

Hey @Matthew_Graham, thanks for sharing your feedback !

As a first note on this :

It’s important to clarify that, rather than a top-down approach, the general intention of this proposal is to empower / incentivize the community to develop and take ownership of new product ideas from the bottom up.

This has worked before with MVI and I’m sure can work again - we just need to get the framework right to make it :

1/ Enticing (both for methodologists and the Coop) : acknowledge the work that is going in a methodology prior to submission / inception, support the project in its bootstraping phase, associate the methodologist and the project contributors with the product upside - all funded in the most sustainable way, hence the proposed structure.

2/ Transparent : both in terms of organization (who’s doing what), budget (who’s paying who) and reporting to the community.

3/ Scalable : can it be replicated for several products without exponentially increasing our structure’s complexity ? As such, I agree with you and @jdcook that creating a WG or even a Pod for every new internal product might not be the optimum solution.

However, we should keep in sight that this proposal covers an initial period of 3 months, not (deliberately exaggerating) 15 years… We might as well see this as the 1st opportunity to iterate on some kind of accelerator for internal products such as iRobot, SODA or YHI ?

It’s worth noting that the funding structure proposed by @overanalyser for YHI is similar to iRobot’s, with the Coop retaining the methodologist bounty and methodologists being compensated via working group rewards !

3 Likes
#15

I think the product should be internal or external. A hybrid only complicates it, makes it messy for no apparent gain.

What do you think Index Coop does differently to support internal versus external products ?

Is there some part of the methodologist role that the methodologist does not have capacity to support ? The methodologist is being paid to perform the role via the streaming fee and incentivises.

I suggest we move the fee split to reflect the relationship better. If internal, then internal everything. If external, then we go with a fee split that reflects the value add of the methodologist.

I think the existing rewards structure captures everything just fine and no new working group is needed. I read this general concept as a methodologist supplementing there role with coop resources. If MVI was external from the start, it would have been way more cheaper for Index Coop.

If the methodologist contributes to the community outside the product, they should be paid. That is a very simple and easy to implement model. DATA is a good example of this.

Is there something wrong with how Index Coop supports DPI? I don’t understand the benefits of having a fee split and then Index Coop paying resources to do perform the methodologist role.

This hybrid scenario is messy, it adds extra complication without adding any benefits IMHO. The only way it adds benefit is if either party is not performing there role as per the fee split. If this is an internal product there is no fee split, a person is paid as a contributor to coop each month for the value they bring.

1 Like
#16

@Matthew_Graham, @jdcook @sixtykeys - thanks for sharing your thoughts, and I agree with many of the sentiments expressed here - especially around the complexity created by introducing a new model.

That being said, I am all for the experimentation, and as @Monportefeuille put it:

Open to challenge, but my stance would be let’s see how this product WG model functions with a clear understanding that this is a 3-month trial.

Things will change, our approach will improve and hopefully, this is another step down the road for us to develop a more robust strategy for launching products internally.

3 Likes
#17

Going to try and respond to feedback from @Monportefeuille @Matthew_Graham & @Pepperoni_Joe while keeping this coherent…

I totally agree with these statements. I acknowledge that we are in experimentation mode here - which is awesome. And props to @Monportefeuille for pushing us here. We need to figure out empowerment and incentives for in-house products - MVI, DATA, iROBOT, PAY (early days), YHI, etc all have come from community members. We have the talent in house to design great products.

I do think that for an experiment, $60k for 3 months + redirection of the fee split is starting pretty high, and I think it is much harder to bring budgets down than to raise them up.

My understanding is that @Monportefeuille will work to keep models and testing up to date and continuously being preparing for re-balancing. I think that is all that is required of a methodologist - it has been articulated many times that the role of a methodologists is a data provider. The Coop has growth, analytics, product, eng, people, etc working groups for a reason - methodologists lean on the Coop for the rest. So a full-blown WG with objectives that overlap with current working groups just doesn’t make sense to me.

I think there are a lot of un-answered questions around this topic that aren’t going to get resolved by the time iRobot launches. So, I think the “experiment” here is simply to give @Monportefeuille the leader stipend requested (below) underneath PWG or the Simple Indices Pod, as well as the fee split (as a 3-month experiment).

It feels to me like this allows @Monportefeuille to have the steady funding needed to do the work required of a methodologist, and gives us more flexibility and ability to learn how we should be empowering and incentivizing internal products.

For what it is worth, my early thinking around “internal” products is a stipend-position (like proposed above) to cover the work done to maintain the product (from a re-balance perspective) plus a much lower fee-split that just goes directly to the internal methodologist (like 5%). If at any point the “internal methodologist” wanted to “retire”, that position/stipend could be off-boarded to the Coop / someone else. If it isn’t too late to go in that direction with iROBOT, I think that would be solid.

3 Likes
#18

This is a very interesting approach and something worth considering but personally, I do not believe this is the right approach. I agree with @sixtykeys @jdcook. This structure works more if there is a suite of products similar to FLI as the resources are more efficiently used across a wide range of products. Having a dedicated working group for one product is not an effective use of contributors’ skills and protocol resources. I also believe a potential problem arises when we develop capabilities specific to iRobot, that those resources, skills, insights cannot be easily transferred to other products because of the uniqueness of this product. In traditional organizations resources are spread across product lines or suites, not just one product even amongst the biggest corporations in the world departments are not set up for a single product.

1 Like
#19

The book on how we interface with and best empower our community methodologists is definitely not yet written, and I would argue we should welcome experimentation - as much to find out what DOESN’T work as to find what does.

That said I share many of the various concerns expressed by other community members in this thread. $60k for three months does feel steep and I think JD’s solution (or some version in-between) the leader stipend + the fee split for three months could be a good place to start.

1 Like
#20

Brief Table setting

  • I’m putting on my “Funding Council” hat to pose questions (See Q4 Working Group Guidance to learn more about Working Group proposals)
  • My intent is to ask the questions that ping in my mind with the hope that they help the entire Coop better understand the proposal and thinking behind it.
  • Questions are pretty much posed in the order the topic appears in the post
  • If a question doesn’t make sense or is entirely off-base, do call it out :slightly_smiling_face:

Noting that some version of the question, “why is the Working Group structure the right one for bootstrapping growth of a new product?” has already been posed and that respectful discussion is ongoing,

Instead, the question I’ll add to (hopefully) help sharpen the discussion is

→ Let’s assume that the RIWG doesn’t get approved, how would impact iRobot (should it pass DG2)?

Just clarifying questions! So if my understanding is right

  • $6000 per month for 1 leader
  • If iRobot hits the following thresholds during Q4…
    • $5m AUM → $1K bonus
    • $10m AUM → $1K bonus
    • $15m AUM → $1K bonus
    • $20m AUM → $1k bonus
    • Capped - $10K cap hit (6K stipend + 4K bonus)

Am I getting that right?

On this section as a whole…

How do you envision the RIWG complementing the relevant WG’s that are also focused on marketing/growth/product development/data analysis?

5 Likes
#21

Hey @jdcook, thanks a lot for the time and effort you’ve spent to “digest” this long conversation, and for your constructive approach to what a compromise could look like.

I can hear your thinking, and see that this proposal has raised quite a lot of questions which is good and will eventually help us moving forward.

With the latest developments on the technical side for iRobot, I don’t think we should aim to rush into a last minute hybrid solution, and I would like to use this opportunity to at least propose a temperature check in the community to see how opinions crystallize around this discussion. Thanks again !

2 Likes
#22

Hey @gregdocter, thanks a lot for your questions and your constructive approach ! Please find some feedback below :

This wouldn’t impact iRobot’s growth, I think mainly for 2 reasons :

  • A lot of work has gone and is still going into the project, which I support mostly on my own in parallel with my current occupation. I have personally never felt more committed to making it a success once this long incubation phase is finished. I also feel no particular lack of capacity to support all parts of the methodologist role, for a methodology I have spent so much time developing.
  • The ability of the Coop to support any kind of product in the best possible way has never been questioned either, and I’m properly stoked by the energy that this proposal has gathered in the community already.

Yes, that is the correct interpretation of the proposed system.

The more this discussion progresses, the more I see the RIWG as the 1st opportunity to iterate on some kind of accelerator for internal products.

We could draw a parallel with the Work Team’s analogy of iRobot to an early self-driving car (kudos to @Metfanmike :blush:): I believe a Working Group or Pod structure could help making iRobot’s transition towards a flagship self-driving limousine smoother and quicker, by rolling out the strategies / tools developed by the established WG’s and shaping them around this particular concept.

There might be additional options to avoid extended overlap with the relevant WG’s, or creating a new WG for the incubation of each new internal project : for example, after 1 or 2 iterations, a new community methodologist could take over the hot seat, and the WG be structured around a new product.

2 Likes
#23

Dear owls, as mentioned last week and following the IIP-85 guidelines, I just added a Temperature Check poll to understand how opinions crystallize in the community around this discussion. Thanks in advance for your participation !

5 Likes