MIP39c2-SP21: Adding MakerLabs Core Unit

MIP39c2-SP21: Adding MakerLabs Core Unit

Preamble

MIP39c2-SP#: 21
Author(s): @colrad, @urbanisierung, Tim Schuppener (@ultraschuppi)
Contributors: -
Tags: core-unit, cu-skunk-001, mandate
Status: RFC
Date Applied: 2021-07-19
Date Ratified: <yyyy-mm-dd>

Sentence Summary

MIP39c2-SP21 adds MakerLabs Core Unit for building and validating MVPs.

Specification

Motivation

Good, new products usually emerge from high-risk endeavours. In the world of traditional software engineering, building a Minimum Viable Product either validates or invalidates your product idea. However, real validation is gained from the market when the MVP is released to the public. Real validation is not the promise to use the product but only the product usage itself.

While the current setup of the Maker DAO allows for incremental and low-risk improvement of the existing product, the current framework is not set up for pursuing revolutionary product ideas.

Therefore we propose a new MakerLabs Core Unit that implements new product ideas spanning across the full stack of decentralized technologies.

Having full technological responsibility inside a single Core Unit would give MakerLabs the autonomy to move fast and ultimately test and validate new ideas early.

Responsibilities

The MakerLabs Core Unit Team responsibilities essentially revolve around the rapid implementation of new product ideas grounded in solid full-stack engineering practices, including iterative product improvements to find Product Market Fit.

  1. Picking up a new product idea and a fast implementation of an MVP. A wide collection of diverse ideas already exists that can advance the Maker Ecosystem at different levels. The selection for the implementation of the next product lies with the Core Unit in discussion with the Maker Community.
  2. Make the product available and ensure easy entry. Implementing the MVP is only the first step. A product can only be used if it is accessible to a broad user base. This applies to both technical prerequisites and user experience. Technical barriers for users have to be low, and the product needs to be designed for usage without reading long documentation.
  3. Validation and quick iterations based on user feedback and metrics. The most important tool to validate a product is measuring and processing feedback. This involves the use of various channels of direct and indirect user interaction to obtain all the necessary information. The result of validation is binary: Product Market Fit achieved or not.

Team

The MakerLabs Core Unit will have a flat management structure led by the facilitator who answers to the community of MKR holders. This Core Unit is being proposed as a single team.

Our team has already bootstrapped a couple of products and teams and brought them to market. After solving all the hard problems, we moved over to the next mission.

This experience and familiarity with Maker will allow us to be effective from Day 1, with little lead time, no need to recruit heavily and bring an established working process.

Core Unit ID

SKUNK-001

Core Unit Name

MakerLabs

Core Unit Mandate

Product Implementation

Quickly develop new product ideas into usable MVPs.

  • Products are focused on increasing the Maker Ecosystems value and usability to end users.
  • The scope of the products would be strictly separated from the Maker Protocol. We want to build products upon the Maker Ecosystem, not modify or change but instead leverage what other Core Units e.g. Protocol Engineering or Oracles are building.

Deployment

MVPs end up being deployed to test and production environments.

Move fast and break things is usually not something you would want to hear in the Maker Ecosystem. We will apply it on test environments but will switch to risk-capped innovation measures on production environments:

  • Risk to MKR value will be limited to whatever MKR holders find appropriate
  • Risk borne by early adopters will be limited to whatever MKR holders find appropriate

Full Stack Engineering

MakerLabs Core Unit will build all aspects of a product.

  • Smart Contracts
  • User Frontends
  • Metrics

Validation

  • User Feedback
  • Measure, measure, measure
  • Quick, small iterations to improve the product based on new insights
  • If a product idea is successfully validated, MakerLabs Core Unit will propose plans for the next steps

The first product we’d like to tackle is eurDai. From deploying the eurDai Contracts, to building a eurDai wallet to metrics measuring its success or failure.

20 Likes

I like this. What is the initial thought about transitioning successful products out of this CU? Or will successful products stay within this CU?

The primary purpose is about prototyping new product ideas and the very last step on the happy path is to propose a plan how to move forward. Maybe naive, but I guess that if something works pretty good there will always be someone interested in picking it up. But let’s cross that bridge when we get there :wink:

1 Like

Hi @ultraschuppi - exciting proposal you have here!

thumbs up for taking on eurDai right away

I have some questions, forgive me if some of them are not so smart:

  1. When you say Minimum Viable Product (MVP) do you mean testnet viable, or mainnet viable?
  2. Is this a sort of a “Space-x method”? Crash and burn is certain, but you iterate really fast towards something that works?
  3. If you add a frontend to a MVP (as you plan), are you not quite close to the real thing?
  4. When you complete the MVP, who will take over and do the rest? Why not do the rest of the job while you are on it? What is lacking here - will or patience?

and now for the interface questions:

  1. Which groups are you going to interface with? I guess PE will be involved at some point or not? Could SKUNK do some of the tasks that PE would normally do as a sort of apprentice program?
  2. Will SKUNK be a good match with GROW? You could do proof of concept work? That is MVP anyway? Again - take some of the workload off PE?
  3. How about RWA? There are now 4 or 5 possible methods for getting into US Treasuries - is this something SKUNK could support?
  4. Is SKUNK willing to do collateral applications? Like the less painful ones to start?
4 Likes

Hi @Planet_X

Thank you for your great questions!

Even though I’m not as well versed with the Maker Community as @ultraschuppi, I hope I can clarify some of them.

If your friend says “It’s a great product!”, then that is certainly nice to hear but no real validation.

We think validation can only be proven when people commit to the product. Be it money, by paying for it. Or be it time, by using it.

Therefore we have to deploy the MVP to the mainnet. We believe validation can never happen on testnet.

I like this “Space-X” analogy but I think there is a major difference. Early Space-X and similar projects like ITER and Manhattan would have failed because the goal is technically not feasible or too expensive.

Software engineering has the great advantage that it’s pretty cheap. The greatest challenge in new software projects is to make something people want, or more precisely make something people want to pay for.

So a crash and burn for MakerLabs is not spending 12m on an exploding rocket. But in the end having a rocket that nobody wants to use.

Therefore we want to build rockets very fast/cheap and measure if people actually want to use the rocket.

If we can prove that people are actually paying for rockets, other teams can step in and build even greater and more efficient rockets.

I tend to disagree. Let’s look at something like Facebook. One could argue that the original thefacebook, marketed to College Students was a MVP. But the Facebook we have today is completely different to thefacebook of 2003.

The differentiation between MVP and the real thing is even more important for the financial products we are building.

  • Auditing and hardening the Smart Contract would slow us down. We want all our MVPs to be risk-capped.
  • Supporting the Product for millions of users would drain our small team of all resource
  • Marketing the Product is not something that lies within our expertise
  • Exploiting a market opportunity, going down the rabbit hole of optimization, would lead us away from what we do best. Building and validating unproven Products.

Transforming a MVP to the real thing, is usually an endeavour bigger than building the MVP.

This would include all the auditing/hardening work, removing the risk-caps, building an infrastructure for support and monitoring … and adding new features. Maybe even transforming the Product to adjust it to changing customers needs.

There are typically 2 types of strategies: exploration and exploitation.

We as a team draw the most satisfaction from exploration, this is something we excel at.

Other people and teams on the other hand are great at exploiting existing market opportunities.

There are a lot of exciting product ideas in the maker community that sound worth pursuing. We want to validate them and then come back to the community with either “Great Idea and it found adoption” or “Great Idea but nobody is really using it”

In both cases the community can then decide on how to move forward.

Even in the case of a successfully validated Product, the community could decide not to move forward (because it does not match the vision of Maker …)

Or the community could decide to grant a Budget for exploiting the opportunity more deeply.

In the case of an unsuccessful validation the community could propose adjustments for revalidation or decide to drop it for good.

We see MakerLabs as a tool for the Maker Community to explore and validate Product Ideas. As any tool we serve one specific purpose.

Like a skrewdriver we excel at driving screws but we are less efficient at driving nails.

We will interact with all interfaces that are necessary to implement the MVP. This also means that we have no limitations in the technology stack and may also implement smart contracts (for example).

However, in order to move forward as autonomously as possible, we would like to act independent of other Core Units and request as little support as possible from other Core Units.

We picked eurDai as the first product because:

  • We think we can implement it without changes to PEs domain

  • We probably don’t need to make profound adjustments to the smart contracts

  • We like the product idea and think it is worth pushing forward.

  • Some people in the Maker Community want eurDai but nobody has proven that it will be used

The inherent difference between PoC and MVP is that PoC usually proves the technical feasibility. MVP proves the market feasibility.

If there are topics that call for a MVP (user/market validation) and contain changes to the existing Maker Smart Contract then MakerLabs would be glad to create Pull Requests to the PE repository.

But I think before this can happen, MakerLabs has to prove itself to PE and the Maker Community, that we can write sound and safe Smart Contracts and that we would not be a burden to PE.

We haven’t thought so much about RWA topics so far (and eurDai will probably suck some time anyway) - I wouldn’t reject any topic without digging into it.

I don’t think we would add great value to collateral applications. At least for me, adding new collateral types seems like a proven process done by the Risk Team, Oracles and PE. It’s like adding a new Feature to an already great Product.

From my point of view this falls in the exploitation category and therefore would be outside of MakerLabs domain.

7 Likes

Oh Em Gee! :smiling_face_with_three_hearts:

A small comment with regards to:

Speaking from experience in the PE team, I have seen that engaging newer members into the collateral onboarding process has been one of the quickest ways to get them up to speed on system interactions, tests, and to build an awareness of various protocol dependencies - it’s not so much that they add value to the process - in cases it slows down the process, which is fine because the longer term value outweighs the short term.

In saying this, I’m not suggesting that you become a collateral onboarding team, but just thought I’d share the value we have had in integrating people into this weekly (now fortnightly) ritual as a safe proving ground. Perhaps a similar process, even if you wanted to do it independently, may be of value.

5 Likes

I’m torn.

This proposal keeps me debating myself (not in a good way).

On the one hand… :muscle:t3::muscle:t3::muscle:t3:

  • I believe in the ability of @ultraschuppi (I’ve spent a lot of hours contributing with him and I can attest to his values, intelligence, and commitment.
  • I have spoken a couple of times with the rest of the team, and my general impression only improved.
  • We could not onboard these individuals faster: this team is already Maker.

But on the other… :anguished:

:hammer_and_wrench: Show me the mocks! (or a support team)

  • I would expect a team building MVPs to have:
    • UX Researchers
    • Designers
    • Prototypers
    • A product manager
    • and I’m probably forgetting more roles, but I haven’t prototyped in what feels like a lifetime.

PS, I get a similar feeling when the brilliant minds from @Protocol-Engineering work on a front end, a MIP, or a proposal. We need to enable the smarter ones to spend as much time as possible working on tough problems.

:dart: A clear purpose: scaling Maker

Is this a group of smart people telling us that they need direction (speculation)? Again: are we wasting brilliant minds playing with toys (or MVPs) instead of focusing on the next big problem? What are the areas that we need to focus on to scale Maker?

:toolbox: The drawer of old toys

I’m afraid (speculation again) that we are going to end up with a bunch of tools that people might like, but:

  • we don’t have the bandwidth to maintain them (taking this statement to the extreme, we might be creating a problem)
  • not a lot of people use it (niche tools)
  • are not a full product (yes, I know what MVP stands for, but still)

But decentralization… :man_shrugging:t2:

If the smartest doctor wants to focus on plastic surgery instead of longevity*, there’s not a lot we can do. We can only make sure that the incentives are in the right place.

As mentioned: if this team wants to work on creating 3D NFTs for Maker, we should probably let them, but… argh.

*) I reserve the right to change this bad analogy for a better one.

4 Likes

Not sure there is a need to speculate here.

  • MakerDAO wants eurDAI. In my view, there is a consensus that it is a big opportunity for MakerDAO but competition is coming.
  • MakerLabs will work on eurDAI. It will most likely take a long time just to get started.
  • @ultraschuppi has shown the willingness to do whatever it takes for the DAO. We need someone to write signal requests, he does the jobs (countless times). Figuring out the rates, guess who created the MakerDAO Open Market Committee (quite useful to understand what is needed for eurDAI). His entrepreneurial mindset is what we need for such a project.
  • The team is already productive with the delegates analytics UI.
  • Cost is under control.
10 Likes

While I agree that in the long run we may need dedicated people specializing in those functions, I absolutely disagree on the need to get them into the team right now. Sure you need the capabilities (up to a certain level) to start the show - but we already have them in the current team.

I would not hire a full time UX Researcher, Designer, Product Manager at the very beginning of this CU. Let’s start small and grow (if needed) by the time we realize it makes sense to get someone specialized on board.

Too many cooks spoil the broth.

I’d argue that an MVP is a valuable tool, not a Toy. (Else no Company in their right mind would build MVPs)
When you say Maker should fix the “big Problems” to “scale Maker”, then I agree.
But this is not the purpose of MakerLabs.
The purpose of MakerLabs is to find new Opportunities in a professional manner.

The question is: Does the Maker Community deem an opportunity exploring CU important or not.

The only difference between science and fucking around is writing it down - Mythbusters

That’s why we think defining a threshold that sets a level for “achieved Product Market Fit” beforehand is so important.
I’d like to think of it like a pop-up store. Let’s test Unicorn-poo flavoured Icecream, set up a Store for a limited amount of time and measure sales. If it’s beyond a predefined threshold then we open an even bigger, permanent store. If not we close for good … sorry to the 15 very satisfied customers that enjoyed our product but you are not enough to support our business case.

MVP’s are like pop-up stores. They should not live very long. Either they transform into a big beautiful Butterfly or they should be put down.

7 Likes

Again, and maybe my post wasn’t clear enough: this team is gold. We need them on board.

Speculation arises when things are not clear (or de-risked).

It’s called MakerLabs, not EURDai Core Unit. I would be much more inclined to vote for a Core Unit that has the latter name. I would even throw in some grant money to do previous research before working on this (SES might have offered this :wink: ).

I’m sure they can also write poetry for the DAO and be productive, but these guys are WAY smarter than that UI (the ones that can write smart contracts smart).


@ultraschuppi, you’re one of the smartest persons that I know. I know that you can do UIs (or research, or the long list of et ceteras that you’re proposing (you can probably become a successful TikTokker if you set your mind to it :wink: )).

I also know that you will do whatever you like doing best (and that’s perfectly fine). I also know that I will support you in your future endeavours.

TL;DR:

  • more focus (ideally on a big problem)
  • more focus (ideally doing what you do best)
  • I will support you regardless. <3
5 Likes