Fostering The Bazaar: What Do We Build?

#1

CURRENTLY: We don’t exactly have any criteria around what we build in the DAO.

CHALLENGE: We’re not a startup with a singular goal, we don’t want to stifle innovation, autonomy, or contributions from minority viewpoints or outliers.

Developing a rubric or criteria around what we build will simply ossify existing limited/singular perspectives into sterile process, which feels like a step backwards.

DISCUSSION: Instead of coming at this problem from a front-end gatekeeping perspective (“should we build this or not?”), can we find a way to let nearly any project or hypothesis have a shot if there is a builder/team motivated enough to try?

If we are are open to nearly any project, how can we ensure we are growing, leveling up, contributing value, and creating a rich and vibrant builder culture within the DAO?

IDEA: Focus on the major inflection points of a project for key group discussions, and push project owners to define their own success, scope, accountability, etc. Define success as getting better and better and the product development lifecycle (including killing projects).

What are our goals?

  • Bake product development excellence into the DAO’s culture
  • Invite radicle and minority viewpoint ideas instead of squelching them
  • Push critical decisions to the edges, do not formalize a top-down rubric or centralized accountability
  • Ensure we can scale without running in to process or gatekeeping bottlenecks
  • Challenge traditional product development org memes and process
  • Celebrate all decisive inflection points (kicking off new project, delivering milestones, shuttering projects and moving on)

Would love to hear some thoughts from the DAO on this so intentionally keeping this brief / open ended!

2 Likes
#2
  • Push critical decisions to the edges, do not formalize a top-down rubric or centralized accountability

What does this look like? Allowing each group to have the ability to make their own decisions? Isn’t that essentially what we’re doing with each WG asking for funding and deciding how they spend that funding themselves?

If there isn’t a criteria, how do we collectively decide what to keep building and what should be cut off/ killed? Doing it based on how we feel seems a unfair. As a hypothetical: One month we may be feeling good so a new project can continue/ start, the next we may not and another similar project may not continue or even start. So I guess the key question is, how do we make fair and somewhat consistent decisions?

I’m all for experimenting and trying new things, but I just want to be mindful that we’re only able to think very freely right now as we have access to a large treasury. It’s not bottomless so at some point there will be tradeoffs (e.g. Should we work on Project A or B as we have limited budget for the project; how do you decide which project is more important?)

  • Ensure we can scale without running in to process or gatekeeping bottlenecks

This may just be me, but that kinda seems contradictory to me and I guess that’s part of what you’re challenging and where you’re asking us to expand our thinking. To me scaling requires process: You take what’s working well and apply to other areas. The learnings you have in one area end up becoming a process that another area uses to speed up/ improve their work.

General thoughts:
My take is that we start by “doing things that don’t scale” (going in line with your thinking about allowing any project to get started) but still keep in the back of our minds that we should eventualy make those things a bit more sustainable. I love this line of thinking, and am excited to hear how others think some of these things can be possible. I will admit, I am somewhat stuck in my old consulting ways and have a hard time thinking this big, so would love pushback to help me expand my thinking :slight_smile:

4 Likes
#3

There is a lot here already @bvalosek @sarmad_greydient - thank you for the very interesting ideas.

My impression is that there are two important questions or goals:

  1. Experimentation
  2. Revenue

It seems like there may be a general consensus that revenue can be a product of experimentation but should not be the metric that dictates experimentation.

If this is true I’d personally like to have a better idea of how to prioritize revenue vs experiment. If our existence is predicated on funding (is it?) it seems that at some point this comes down to a cashflow calculation. I don’t necessary mean this as a definite calculation but as a conversation about how our existence as an org relates to the treasury.

That being said, I’m very open to the idea that the more we experiment and persist as contrarians the more we have to gain - gains being revenue generating products, builders, and public works.

1 Like
#4

I agree with this, ultimately, we need to :slight_smile:

Ezra and I chatted a couple weeks ago on the kinds of value we are looking to generate. The categories were roughly 1) financial, 2) social / reputation, 3) utility (will it help us be more effective). Generally all of these are “experiments” - a startup is also an experiment if you want to think about it that way, but hopefully we get really good at differentiating GOOD experiments from bad ones.

Personally, I think 1, 2, and 3 are all extremely valuable, but the only one which might be necessary for sustainability is 1, so I prioritize it. I also think we should focus on the NFT space lol - it does help to have a focus.

#5

Here’s my current model of how to evaluate what’s valuable to the DAO (you’ll notice it’s missing something…):

1. Does it help our mission, ~* INSERT MISSION HERE *~?

I think communities come together around ideas bigger than just “make our community successful.” Helping Rarible Protocol succeed is just another version of saying “make our community successful”: we really need to be asking why we care about making Rarible protocol successful here. What’s the real reason you care about that? What inspires you?

Personally, I like something like the idea of making the world better for creators: making it so anyone can throw their ideas out there and be confident they will get fair credit, opportunities to collaborate, find community, no matter their prior circumstances.

I think the way we’ll find this is for everyone to just keep suggesting what they like best, as persuasively as possible. Eventually something will stick on its own, and that will be the de facto mission. But we should all be trying to suggest things, IMO.

2. Does it bring value to the DAO?

As Eric mentioned, I think we can roughly break this into 3 categories:

  1. Financial value – will it increase RARI price? will it bring in other new, valuable assets?
  2. Utility value – will it improve our operational power? will it make the DAO work better?
  3. Social value – will it make our community a better place? Will it inspire people to join our community? Will it improve our community’s reputation?

Generally, we should be shooting for things that both help the mission and provide value in some way, and choosing the projects that seem like they overall do the most.

Another topic I want to bring up here is what I’ve been calling the Web 2 and Web 3 approaches to building.

Web 2 approach

The Web 2 approach is classic startup stuff:

  • A single, focused product that elegantly solves a specific problem
  • First nail product-market-fit, then go into metric driven growth mode with stat tracking, sales, marketing videos, partnerships, etc.
  • Top down hierarchy
  • Emphasis on growth and productivity over fun
  • Strongly categorizes people as employees, founders, investors, customers

Web 3 approach

The Web 3 approach is what we’re seeing in many grass roots Web 3 communities:

  • Community through shared ideas, motivations, and practices instead of a single, clear product that solves a specific problem
  • Anarchy-style processes – people do whatever they want but come together to make collective decisions when needed
  • Emergent focus on interesting ideas as they bubble up
  • Emphasis on fun over growth and productivity
  • Rather than strong categories like employee vs. customer, people have an intangible reputation based mostly on: are you around and are you helping?

The Web 2 approach has obviously been proven an effective business strategy over the past 20 years, so I can’t blame anyone for wanting us to be more like that. My gut, and definitely my heart, is much more with the Web 3 approach, though: I think that given the choice, people want to be in Web 3-style spaces. In a world where all the core infrastructure is permissionless and open-source, community seems to be the strongest network effect, and so being the place people want to be might be the best thing we can possibly do to thrive.

For us, maximizing protocol growth is Web 2-y: it makes perfect financial sense, but I don’t think it’s the kind of shared purpose that we can really build a strong community around. The Web 3-y approach looks for ideas and purposes behind the protocol: things that maximizing the protocol supports, but that many other ideas could also potentially support. Things like changing the nature of creative work.

2 Likes
#6

solid comments yall thx for diving in and sharing your thoughts @sarmad_greydient @jacob @Rarible @m0zrat

I might’ve started this post a bit too general but the discussions are at least all orbiting around some really great common points. To clarify what I want to explore in this thread:

DISCUSSION OBJECTIVE: Arrive at a framework that can be used to guide what projects are launched(/continued/killed) by the Builders Group.

An example framework/strawman to get the convo going:

  • Set a high bar for Builders Group: builders capable of executing, shipping, getting things done
  • Builders’ stipends are renewed monthly (internal WG voting process, could be via optimistic governing)
  • Builders Group is funded by the Parent DAO quarterly
  • Once in Builders Group, anybody may propose a new project/protocol/dapp. Allow for group-wide discussion, collaboration, even dissension/disagreement
  • Project Owner has full autonomy to start their project whenever
  • Project Owner is responsible for all updates, reporting, kill criteria, continuation considerations
  • Project Owner must continually appeal to the WG on viability / feasibility of project
  • Builders Group peers continually provide feedback and opinions on projects
  • Other builders may join/contribute/leave projects whenever they want

Example Scenarios

Brandon wants to launch the UltraVIBES project. He articulates the plan, scope, timeline, and recruits additional project principals. Outside of the principals, everyone dissents (doesn’t agree that the project should start). He launches the project anyway as he has full autonomy to do so. After a month, the majority of the Builders Group thinks the project is not working out, and the consensus is he should kill the project. He refuses, and his next monthly stipend proposal fails when the majority vote NO. Brandon is removed from Builders Group.

Zak wants to launch a drum machine dapp based on the Rarible protocol. After discussing with the group, most are onboard. After a month of working on the project, everyone realizes they prefer to just use hardware drum machines instead. The project is killed, and anybody working on the project moves on to the next thing.

Stefan proposes that his project for the next 6 months is to shitpost on Twitter and share memes on Discord. Nobody engages with this project idea, it seems like a joke. Stefan starts his project, as he has full autonomy to do so. When his monthly stipend renewal comes up, everyone votes YES, as the vibes this project bring seem like a valid use of funds for the working group. His project continues.

The entire WG wants to launch a direct competitor to dot-com called “Rarible 2”. Consensus is reached and the project is started. The WG continues to approve each others monthly stipends since everyone is on board. When the WG funding proposal to the parent DAO goes up next quarter, it fails since the WG has gone rogue and is creating negative externalities for the broader Rarible ecosystem. Builders Group is disbanded

#7

I generally think overanalyzing young ideas is not as constructive as just building prototypes and getting user feedback. For that reason, I believe this format is both elegant and will have greater returns (monetary, community, and talent). I also love the focus on formalizing a process for killing projects. I’ve had my fair share of bad ideas that I had to kill and I think it’s healthy to begin a project with a set of expectations or a hypothesis.

I think the DAO might consider approaching this entire proposal in the same way - set up some expectations for this method, set a time frame, and then try it out.

3 Likes
#8

totally.

Trying something and realizing the hypothesis was incorrect, or realizing a project wasn’t as promising as you thought… is a totally valid outcome in a lab environment. Every time we start/kill a project, we get better at the SDLC as a group and hone our processes

Exploration / play / experimentation / discovery ← this is needed in a space as wide-open as NFTs and web3 atm.

Encouraging open-ended discovery while being pragmatic and critical about projects to avoid languishing initiatives feels like a good balance :rocket:

1 Like
#9

IMO scrutiny of a proposed project should be largely shifted from the idea itself to the way in which the project proposer articulates the idea and their track record:

  1. How well thought-out and comprehensively crafted is the product brief?
  2. Is the social, financial, and utility value this project can provide to the DAO clearly stated?
  3. Has this contributor/team built and delivered similar projects in the past?

If someone has an idea that they’re stoked about and goes through the effort to put together a thoughtful outline, we should err on the side of giving it a shot – when people are passionate about what they’re building, great things can happen. And when great things happen, more people show up.

Define success as getting better and better and the product development lifecycle (including killing projects).

100% agree – we need to normalize failure. In such a nascent space, there is boundless opportunity for exploration and experimentation, and to find great ideas means we must also find ones that aren’t fruitful. A killed project should be celebrated as much as a completed one; a project that falls flat with the community should be praised as much as one that pops off. Through exploration we learn, and failing is an essential and unavoidable part of that learning process.

The significant thing isn’t the failure itself, but what we do with it:

  1. How do we share our learnings and effectively propagate our building experience across the rest of the group and broader DAO?
  2. How can we improve the way in which we assess and build future projects?
  3. How can we make an impact on the community even without shipping a project?

Admittedly this all sounds a bit idealistic, and letting people build whatever they want sounds scary, but have we tried it yet? In such an explosively innovative space, do we want to err on the side of caution and take the safe path, or do we want to try something that might seem kinda wild and see if we can make it work?

A tragic scenario: Everyone showing up to the DAO is building crazy, experimental things they are passionate about, but most projects fail in their ability to provide utility or social and financial value to the DAO.

A more tragic scenario: Everyone at the DAO is limited to build things that strictly drive greater transaction volume to the Rarible protocol, and the vast and untapped innovation potential of the NFT space passes us by because we were too afraid to take a risk.

2 Likes
#10

love this :fire:

Post must be at least 20 characters

#11

In general, I feel like this works. We’ll have to decide exactly how to do it, but the chain of accountability is there, even though there’s a lot of freedom:
Builder starts project → has to appeal to rest of builders for approval as they go, since if they really go against what everyone else thinks is good enough work, they will get kicked → Builders group has to appeal to the whole DAO for funding periodically, keeping the group as a whole aligned with the DAO

The only thing I don’t like is

This smells like a ton of busy work (having to reapply to your job every month?). I agree with the idea that membership should be fairly liquid, but I want to make sure it’s done in a way that doesn’t incentivize people to spend too much timing “selling themselves” to the group, rather than just building.

I tend to think this should actually be done “optimistically” – a builder will keep their spot by default, and a member has to basically nominate them to get kicked, at which point a vote can happen – just for the sake of time.

If we want to add extra incentive to be productive, I like the idea of adding a Coordinape-type thing, so people going above and beyond can get extra comp.

2 Likes
#12

dig it – going with this approach

also hell yall on cordinape !

1 Like
#13

Attaching Building in the Bazaar, which is linked from our Funding Round 2 proposal (draft) to refill R Group’s multisig for Q1 2022: