Discussion: Strategic Directions for DAOhaus

[arentweall]

Hey all, during the last roadmap meeting, we had a fruitful discussion about DAOhaus future directions and strategy. I’ve worked with Spencer in distilling and summarising the main points here for discussion.

---

Context & Purpose

Gnosis’ launch of Zodiac
Gnosis’ launch of Zodiac represents a strong alternative to DAOhaus because of its feature parity with Moloch DAOs and DAO composibility. First, new Zodiac modules have started to achieve feature parity with Moloch’s offering (such as RageQuit via Exit, Grace Period via Delay). Additionally, Zodiac’s composability should kickstart a wave of use cases/ DAO legos built by the community (e.g. Seele module built by Tokenwalk to introduce different types of voting models).

Given the prominence of Gnosis Safes, feature-parity with Moloch and the composability of Zodiac modules, anyone starting out with a Gnosis Safe will likely have a Zodiac-based DAO solution on the top of mind. This is a good time to ask: why would a DAO summoner choose DAOhaus to summon their DAO?

Purpose
With the above context, our discussion was aimed at:

1. Understanding how Zodiac works & implications for the DAO ecosystem
2. Zooming into DAOhaus to discover our niche & community personas
3. Looking forward to align on DAOhaus’ strategic directions

1. Understanding Zodiac

How does Zodiac work?
Zodiac is Gnosis’ way to DAO, exhibiting their belief that every DAO starts with a Gnosis safe (i.e. the bank account). Here, DAO ‘summoners’ can add different DAO legos via Contract Address to install more functionalities. Currently, there are only 5 Modules (all built by Gnosis Guild).

How does DAOhaus work with Gnosis today?
There are 2 ways DAOhaus has ‘integrated’ with Gnosis:

1. Safe Minion: A Minion that uses Gnosis Safe as the vault
2. DAOhaus app on Gnosis Safe: DAOhaus is an app on Gnosis Safe, where users can click on the App to open an iFrame of DAOhaus

The Safe Minion helps us focus on what we do best (governance), while keeping our vaults to a high standard. The DAOhaus app on Gnosis enables interoperability and easy onboarding for Gnosis signers who want to evolve into a transparently-governed DAO.

What does Zodiac mean for DAOhaus?
When there are more Zodiac Modules, it is likely that Zodiac functionalities will exceed DAOhaus’. It should be hard to plug all these DAO legos together with good user experience, so We should observe how TokenWalk approaches this challenge.

As we started comparison between DAOhaus & Zodiac, the discussion shifted to look inwards at DAOhaus: who is our user? what do we want to be?

2. Zooming in: Community Personas & Our Niche

What are we solving for?
We want to empower communities to coordinate better together.

Who are we solving for?
First, we want to build for communities with a strong purpose that are actively involved - project, product or service DAOs. These DAOs are internet tribes that share a common goal, identity and vision. These members embody community as opposed to audience that can be seen in projects with many token-holders that do not really participate, collaborate or identify with the DAO.

Coincidentally, our permissioned shares-based voting is better for running purpose-driven communities. This is because they are more organised via mimicking Web2 organisations or creating their own processes, which our governance system can help run. A juxtaposition would be ‘fun’ sporadic communities without a clear purpose - these organisations have formless or non-existent governance, so an ERC-20-token governance system might be a better start.

We are not saying that we don’t want to serve current ERC-20 token-based communities. In fact, they are a big part of existing DAOs today. We will need to figure out ways to onboard them into DAOhaus such as getting sub-teams with a clear purpose (e.g. Product teams) to use DAOhaus for more focused collaboration. We should also explore increasing transferability and fluidity of voting power within our permissioned governance system.

What is the DAOhaus product?
DAOhaus’ ‘product’ is not just the DAOhaus user interface and features, but also the community around DAOhaus.

On a product front, DAOhaus’ main focus is in providing a human, fun and simple user interface to navigate technical concepts such as shares, governance, treasury. To provide upgrades to the core DAO experience, DAOhaus also has Boosts and Minions.

Beyond the UI and features, the community around DAOhaus is not just people on Discord or Snapshot, but collaborators who constantly create new initiatives for DAOs. These initiatives help onboard new DAOs, facilitate DAO-to-DAO interactions and create new DAO use cases (such as LP DAO and Meta-X-lerator) which can be productised in the future.

What makes us unique?
After discussion on our approach, the main value propositions of DAOhaus are:

	Our UVP	Why are we uniquely positioned to do it?
1	Heavy focus on governance & active collaboration for a purpose	Our product starts governance first (proposals, membership, voting, etc.) as compared to bank/treasury first
2	A user-friendly, human and fun way to navigating technical concepts	We design for cool & fun communities, rather than for IBMs
3	A wider community that creates new initiatives & services for DAOs (e.g. UberHaus / LPDAOs / Meta-X-lerator)	DAOhaus is owned, built and governed by DAOs - the entire community is DAOing together in a meta way
4	A social way to discover, manage and follow all DAOs in the ecosystem	We already have social aggregation features such as the Hub, Explore
5	An ecosystem of Boosts to expand DAOhaus functionality	We have an existing Boost marketplace

3. Moving Forward: Strategic Directions

Given the above UVPs, DAOhaus’ strategic direction remains being focused on community governance in a fun & human way. However, in order to adapt to the evolving DAO landscape, we should add the following focuses :

• Community initiatives and products
• Social Features
• Boosts

This way, community initiatives push the boundaries by testing emerging DAO-DAO interactions and meta-DAO use cases, while magesmiths can productise those that work well. Social features will also help DAOhaus users better navigate, explore and be active in different DAOs. These 2 features are possible only because of the community unique to DAOhaus, giving us a superpower that is not easy to replicate.

Finally, Boosts will help to continually upgrade the functionalities of a DAOhaus DAO.

Refer to Appendix for a diagram on how these strategic focuses can practically lead to the benefit of DAOhaus

Positioning in relation to Zodiac

When thinking about how we navigate the eventual overlaps with Zodiac (especially in DAO functionality & Boosts), the analogies of Android and Apple are useful to consider.

Zodiac Modules’ strength in composability and customisability is great for power-users to customise legos for advanced use cases. While this attracts power-users, it is not the best starting point for new communities first entering the DAO space. Hence, we thought the Android analogy represents Zodiac’s position in the space well.

With a user-friendly, simple and fun user interface, DAOhaus wants to embody the Apple approach, where we provide the easiest way for anyone to summon and participate in a DAO. This should be apparent in our core interfaces, features, copywriting and even best practices for Boosts. We do not need to be at the bleeding edge or have the most use cases, but we make sure that all DAOhaus use cases are intuitive, simple and work well. If more advanced DAOs need more functionality, we should have custom Boosts and Minions for them to DIY.

While we can learn from Apple in some areas, there are other areas we can innovate in our own way (i.e. don’t learn from Apple). For instance,

• Interoperability between all platforms, so that DAOhaus can benefit and work with other ecosystems and builders
• Openness and fairness in app curation (perhaps borrowing from Mirror’s $WRITE Race mechanic)
• Positive sum game thinking

Another analogy would be WooCommerce vs Shopify

Ask

The focus here is to discuss and align on the strategic directions and focuses before we can look at the executional steps and priorities.

---

Appendix

Executionally, this is how the strategic direction may be mapped to existing or new initiatives

	Our UVP	Magesmiths’ initiatives
1	Heavy focus on governance & effective collaboration	Continue doing this & explore greater transferability of shares
2	A user-friendly, human and fun way to navigating technical concepts	Continue doing this
3	A wider community that creates new initiatives & services for DAOs (e.g. UberHaus / LPDAOs / Meta-X-lerator)	Continue incubating initiatives via community, while magesmiths productise those that work (e.g. LPDAO)
4	A social way to discover, manage and follow all DAOs in the ecosystem	Build more social features (e.g. profile pages, follow DAOs, favourites, messaging, etc.)
5	An ecosystem of Boosts to empower expansions to DAOhaus functionality	Reduce barriers to Boost creation & incentivise Boosts development via Grants

This is how the different initiatives may drive the growth of DAOhaus ecosystem

For other versions of notes, please refer to:

• Jeremy’s: https://hackmd.io/LIoTPQmfRl6NPQvi63D02g
• JP’s: https://hackmd.io/5d5FdKOnQPmD0Oehbw23jg
• A longer version of this post: https://hackmd.io/@daohaus/H1P1jd5NK

[spencer]

Thanks for such a fantastic summary, @arentweall!

I’ll add some thoughts and a complementary framing as well:

• The backdrop for this conversation is the emergence of a new crop of DAO tools built on a foundation of modularity (primarily enabled by Gnosis Zodiac).
• These new tools (exemplified by TokenWalk) have a theoretically advantageous position of being able to support a wide, flexible range of DAO structures as well as incorporate the open source innovations bound to be created by any developer building on the underlying modular framework.
• This creates two related important questions for DAOhaus:
  1. What, exactly, is DAOhaus?
  2. What is DAOhaus’ place in this growing and evolving DAO ecosystem?

1. What is DAOhaus?

• DAOhaus is a platform for community-centric DAOs

  • We build tools that help community-centric DAOs thrive
  • These tools make DAOs easier to create and use
  • DAOhaus is a human-facing operating system for DAOs
  • DAOhaus is a platform for DAO-focused developers to create tools for community-centric DAOs (boost marketplace)

• DAOhaus is a community-driven economy of community-centric DAOs

  • DAOhaus is an ecosystem of many communities
  • DAOhaus communities support, transact, and collaborate with one another
  • DAOhaus makes it easier for these communities to engage in these activities (services marketplace, CCOs, LP DAOs, etc)

2. What is DAOhaus’ place in the DAO ecosystem?

To me, this is the most important evolution (or really, re-affirmation) coming out of our conversation last week: While other DAO projects optimize for maximal modularity and flexibility, DAOhaus optimizes for UX that smoothly ties together a curated set of modular DAO components.

• A helpful analogy, building on the operating system notion above, is the comparison between Android and iPhone.
  • Where Android’s app store is open and flexible, iPhone’s is curated
  • Where the UI and UX of Android apps varies widely, the relatively similar design language across iPhone apps’ and iOS itself creates a cohesive, holistic, and intuitive UX
• To be clear, we should not follow this analogy entirely:
  • Unlike the iOS App Store, DAOhaus curation will be conducted in a bottoms-up, distributed manner by the stakeholders of the DAOhaus platform (including boost developers!) themselves.
  • Unlike the iOS App Store, DAOhaus will not extract a monopolist’s rent on economic activity within the DAOhaus ecosystem. Instead, DAOhaus itself will accrue value when communities using it succeed and primarily in the form of skin in the game within those communities. Communities using DAOhaus will share in ownership and governance over the DAOhaus platform.

Also important: even while we build for UX, we still remain positioned to benefit from and incorporate new innovations in DAO infrastructure and tooling emerging from the open source development on the modular framework.

[spencer]

@arentweall

Who are we solving for?
First, we want to build for communities with a strong purpose that are actively involved - project, product or service DAOs. These DAOs are internet tribes that share a common goal, identity and vision. These members embody community as opposed to audience that can be seen in projects with many token-holders that do not really participate, collaborate or identify with the DAO.

Coincidentally, our permissioned shares-based voting is better for running purpose-driven communities. This is because they are more organised via mimicking Web2 organisations or creating their own processes, which our governance system can help run. A juxtaposition would be ‘fun’ sporadic communities without a clear purpose - these organisations have formless or non-existent governance, so an ERC-20-token governance system might be a better start.

We are not saying that we don’t want to serve current ERC-20 token-based communities. In fact, they are a big part of existing DAOs today. We will need to figure out ways to onboard them into DAOhaus such as getting sub-teams with a clear purpose (e.g. Product teams) to use DAOhaus for more focused collaboration. We should also explore increasing transferability and fluidity of voting power within our permissioned governance system.

I absolutely LOVE this

[dekan.eth]

@arentweall

not just the DAOhaus user interface and features, but also the community around DAOhaus.

This is key, people in our community know this but we do not do a good job of broadcasting that. We have several years of experimentation with different coordination tools and mechanics, many successful communities benefiting from our experimentation but we should be sharing these (our successes and failures) to the greater web3 community better. Everyone wants to know now, we are no longer just a bunch a dao nerds on our floating island. Lets spread the good news.

the fact that other platforms are incorporating mechanics that we have been touting and loving on for years is only a great signal that we should keep doing what we do. And as it turns out we know a few things about said mechanics.

Also the us vs them is the wrong framing. There is no competition right now, only coordination/collaboration to bring about something new. That may sound naive but if we fall into the same trap of trad software development, then why are we even doing this? There will be teams that want to eat the whole pie, there will be sociopath VCs that want to turn us all into wedding planner apps. But that not us, we are community first, and will stay that way. This is how we continue to be successful.

The fact is we have built a extremely flexible framework for many different coordination tools. Evident that we were able to implement zodiac in a week. The awesome work Gnosis is doing is only a win for us, we are no longer just an interface to Moloch contracts we are also an interface to Gnosis contracts, this addition and that combo really boosts our power level (vegeta meme )

But I love this whole post, love the humility and honesty. I’m all for us adding some of this to our manifesto and roadmap, great direction and focus. thanks you!

[spencer]

@dekan.eth

Also the us vs them is the wrong framing. There is no competition right now, only coordination/collaboration to bring about something new. That may sound naive but if we fall into the same trap of trad software development, then why are we even doing this?

There is a way to frame all this in a competitive context, but I agree that’s absolutely the wrong way to think about it. The other, better, way to frame it – which we discussed in the roadmap meeting last week – is as new information about the DAO landscape and where DAOhaus doesn’t need to (should not?) focus its efforts.

The actions we’d take as a result of both framings would probably be similar (at least in the short run), but the manner in which we approach them in the latter framing is much healthier for everybody.

[arentweall]

@dekan.eth

Also the us vs them is the wrong framing. There is no competition right now, only coordination/collaboration to bring about something new. That may sound naive but if we fall into the same trap of trad software development, then why are we even doing this? There will be teams that want to eat the whole pie, there will be sociopath VCs that want to turn us all into wedding planner apps. But that not us, we are community first, and will stay that way. This is how we continue to be successful.

100% agree with this. During the call, a conscious choice we made was to reframe the conversation away from zero-sum games of ‘us vs them’ & ‘competitors’. We want to collaborate & play this game together, instead of competing, monopolising and winning the pot for ourselves.

Empowering human coordination is an age-old, complex and global problem, much like an infinitely vast jigsaw puzzle. The way to ‘win’ is to do it together, as I’m sure every community, product and human has their unique & important piece to contribute.

With this in mind, what then should DAOhaus focus on to completing this puzzle of human coordination? Given who, why and how we are, what are we best positioned to do?

Echoing Spencer’s thoughts here

@spencer

he other, better, way to frame it – which we discussed in the roadmap meeting last week – is as new information about the DAO landscape and where DAOhaus doesn’t need to (should not?) focus its efforts.

All in all, I liked how the discussion extracted & synergised a common ideology/philsophy in which we can stand behind (so far). Looking forward, this should eventually guide more practical things such as our focus areas & ways we want to achieve them.

On this topic, does anyone have any thoughts on the 2 original + 3 updated Pillars mentioned?

@arentweall

[samkuhlmann.eth]

Amazing work @arentweall and @spencer . I’m super excited for the next few months.

@arentweall

On this topic, does anyone have any thoughts on the 2 original + 3 updated Pillars mentioned?

I really like this and think this is where we should be. The appendix with outr uvp -> initiatives is a good explanation and step towards planning tactical implementation.

My only concern, as always, is being able to properly deliver on a 5 pillar approach. Not saying we should change these, just that blended focus will be a challenge.

• We’ll need to make some hard decisions on priority
• Get creative with how we organize the teams, using boost foundry, new contributors, developer grants, while understand that just throwing more resources at a project isn’t a great solution. “Adding manpower to a late software project makes it later” (Brook’s Law).
• Figure out ways to maintain a high level of quality (and i’d say improve our level as it is now) while working on so much at once.

But these are all details we can think about as we move forward. I think this does start to give us the strategic vision we’ve been lacking.

[spencer]

@samkuhlmann.eth

My only concern, as always, is being able to properly deliver on a 5 pillar approach. Not saying we should change these, just that blended focus will be a challenge.

Here’s a crack at consolidating / simplifying:

Broader Context

The DAOhaus mission is to “Unlock the next tier in community collaboration” (from our work with YAP DAO).

The DAOhaus vision is “A diverse, open economy built on transparent cooperation” (also from our work with YAP DAO).

DAOhaus Ecosystem Goals

To bring this vision to fruition, the DAOhaus ecosystem has the following goals:

1. Be the best platform communities can use to coordinate on achieving their shared goals and live their shared values
2. Foster an ecosystem of composable tools that DAOs can use to boost their coordination
3. Foster an ecosystem/economy of DAO-based value generation
4. Drive innovation in decentralized community governance by experimenting with new formulations, constructs, and initiatives

UberHaus Focus Areas

In alignment with these goals, UberHaus (+ the broader DAOhaus ecosystem) should focus on:

1. Community engagement and other social initiatives
2. Providing capital (via grants or investment) for developers to build boosts
3. Providing a market and potentially capital (via grants or investment) for service DAOs to be summoned on and use DAOhaus
4. Providing capital (via grants or investment) and “first customers” for developers and communities to experiment with new governance formulations and constructs

Warcamp / Magesmiths Product Focus Areas

In alignment with the above goals, Warcamp and Magesmiths should focus on:

1. Building DAOhaus as a user-friendly, human-centric operating system for DAOs: the glue that holds everything a DAO is doing together in a holistic, intuitive way
2. Creating infrastructure to enable other developers to permissionless create boosts (eg Boost Marketplace)
3. Creating infrastructure and basic tools for service DAOs (eg Services Marketplace)
4. Productizing new governance formulations as part of the DAOhaus platform / operating system

What do you all think? Is this helpful?

[arentweall]

@samkuhlmann.eth

• We’ll need to make some hard decisions on priority
• Get creative with how we organize the teams, using boost foundry, new contributors, developer grants, while understand that just throwing more resources at a project isn’t a great solution. “Adding manpower to a late software project makes it later” (Brook’s Law).
• Figure out ways to maintain a high level of quality (and i’d say improve our level as it is now) while working on so much at once.

+1

@spencer

What do you all think? Is this helpful?

Yes, these are very helpful directions. I tried to put it in a table form to better visualise and discuss below.

Borrowin your points with some paraphrasing, we have 4 main strategic directions / focus areas for DAOhaus as an ecosystem.

This diagram should give an overview of:

1. Strategic Directions / Focus Areas: Sorts by level of urgency and abstraction (left as most urgent & concrete, right as more forward-looking & experimental)
2. Product / Ecosystem: Differentiates between those that require dev work vs more community/ecosystem-based ones
3. Success Metrics: Measures & ensures that we are making progress (SMART goals ideally)
4. High-level scope: Lists what we are actually going to do to achieve these success metrics

As time passes & on different timeframes (e.g. sprint/monthly/quarterly/yearly), the diagram should look different within each cell.

After mapping strategic directions & how success looks like, we can proceed to the next step. Executionally, who should do what? (given the different groups we can tap on as mentioned by @samkuhlmann.eth and @spencer )

In this diagram, the first half is the same, detailing our strategic directions & success metrics. In the bottom half, I zoomed in on the high-level scope and mapped out the different initiatives under:

• UberHaus: Ecosystem-wide initiatives (typically involving DAO2DAO, grants, collaborations, etc.)
• Magesmiths: Product & development-focused initiatives
• Rangers: Community & marketing-focused initiatives arising from product developments OR ecosystem initiatives
• Other folks we can tap on at the bottom of each focus area (e.g. New contributors, Boost Foundary, DAOstillery, UberHaus DAOs)

Hopefully, this framework takes the strategic directions we’ve aligned on & cascade it down to clear goals, practical scopes and adequate resourcing for us to achieve them.

Let me know if this is helpful and if you’ve any thoughts!

[spencer]

Wonderfully visualized @arentweall!

Would it be possible to share the files / links that generated these visuals so we can iterate collectively?

Maybe we can spend our next roadmap session brainstorming / discussing initiatives and activity that each group (warcamp circles, uberhaus, etc.) would engage in for each strategic goal. What do you think?

A few other notes/comments:

1. I love that you’ve added Rangers in here too. I think its worth adding in Alchemists as well, especially since their work on $HAUS tokenomics and incentives is central to the goals of “foster an ecosystem of composable DAO tools” and “grow an economy of DAO-based value gen”.

2. I’d say Product / Magesmiths should have a Yes under “Grow an economy…”, with Service Marketplace (and other Service DAO tools) being the primary activity / success state.

[arentweall]

Thanks, good to know that it’s helpful! I think you have a Figma set up in the DAOhaus workspace, so I’m happy to move it over there once I get access

@spencer

Maybe we can spend our next roadmap session brainstorming / discussing initiatives and activity that each group (warcamp circles, uberhaus, etc.) would engage in for each strategic goal. What do you think?

Yes, we should probably go by initiatives first and then how each function (product, community/marketing, tokenomics, UberHaus) can support it. This should ensure that the functions are aligned to the 4 initiatives, and 4 initiatives are well-supported by the functions.

@spencer

I love that you’ve added Rangers in here too. I think its worth adding in Alchemists as well

+1

@spencer

I’d say Product / Magesmiths should have a Yes under “Grow an economy…”, with Service Marketplace (and other Service DAO tools) being the primary activity / success state.

Agree! For Product/Magesmiths, we should differentiate between the urgency of the “Yes”-es (e.g. “Yes Now”/“Yes Later”). This is because we’ll need to prioritise our efforts & time. Also, it’s good to test & validate no/low-code proof of concepts before we put dev hours to build.

---

Looking Forward
With only 1 hour this Wednesday, it feels like we should aim to:

1. Align on the 4 strategic focuses
2. Align on what success looks like (i.e. success metrics) if we achieved the 4 strategic focuses

We should perhaps also time-box this into a ‘sprint’ (like the compensation reboot), so we can re-assess our progress later on.

If there is extra time, we can discuss the initiatives of each function to achieve success. This is not something we have to rush through this week as having 1 week to ruminate on new ideas/thoughts/initiatives can be fruitful for discussion next week.

Next Wednesday, we can discuss & prioritise each function’s initiatives, arriving at a list of initiatives and resoucing required.

This way, by the end of next week (end October), we can hopefully have:

1. XX strategic goals for Warcamp / Magesmiths
2. XX metrics to ensure we’re on track
3. A set of XX initiatives for each function to hit our metrics

Let me know how this sounds! Really excited as to where we’re going with this

[spencer]

@arentweall

Align on what success looks like (i.e. success metrics) if we achieved the 4 strategic focuses

Might I suggest that at this juncture we define success less as specific metrics and more as general concepts? There is still a lot for us to figure out and I’d rather we not over-optimize on measurability too quickly. And perhaps more importantly, setting the wrong success metrics – especially if we really start to galvanize around them as is often the case with KPIs – would be really bad.

As an example, I’d prefer that in these initial stages we strive to define success for “Be the best platform…” more as something like DAO success and world class UX than bounce rates.

How does that sound?

[arentweall]

@spencer

Might I suggest that at this juncture we define success less as specific metrics and more as general concepts?

On second thought, I think you are right. Initially, I wanted to have some measurability/framework to guide us towards success, but it might be too premature. This is especially when the focuses & initiatives are still in flux, risking misaligned KPIs or a sub-optimal discussion on what we actually want to do. Let’s set it up this way then for Wednesday.

1. Align on the 4 strategic focuses
2. Align on initiatives in each function to support the 4 strategic focuses (i.e. what do we want to do / drop)

After the meeting, I can summarise some notes in a new forum post & give us a week to sit on the initiatives aligned.

During the next session, we can discuss the initiatives again and re-prioritise if necessary. If we are generally clear here, then we can look at defining measurability.

How does this sound?

[arentweall]

Ever since the previous post, we have gone through 2 Roadmap planning sessions, aligning on the strategic directions, initiatives & respective workstreams. You can catch up on the notes for 20/10 session & 25/10 session respectively.

---

The rest of the forum post is dedicated to the 01-11 Roadmap Meeting, which surrounds the discussion on What is our approach to building DAOhaus as a product? Do we want to build a configurable & formless tool for admin/devs OR a curated & opinionated product for all end users?

Since this is a point that has been coming up repeatedly, having it here on the forum will help us have a reference for the future & place for long-form discussions.

1. What is our approach?

To answer the question, What is our approach to building DAOhaus as a product? , there are 2 ends of the spectrum worth considering. One end would be having maximum modularity & configurability , whereas the other end would be having maximum simplicity & reliability in the user experience.

2. Who are our user personas?

User personas came up as an important determinant in our approach as each user has different needs, wants and competencies. Among the team, here is a taxonomy of ways to look at user personas

• Human entities
  • Devs (Builder-type personas)
  • Users (User-type personas)
    • Power users: Someone that summons & configures the DAO continuously
    • New users: Users that just join the DAO
• Non-human entities
  • DAO entities
    • Service providers
    • Service recipients

3. Builder-type vs User-type Personas

After some discussion, we concluded that we need to decide between focusing on Devs (builder-type personas) OR Users (user-type personas) .

This is because they have vastly different competencies & needs, resulting in different ways they want to interact with DAOhaus. Defining our focus allows us to make best use of our finite resources to solve the problem. It will also enable us to make the right platform decisions.

	Builder Personas	User Personas
Competency	Dev background & DIY	Non-dev, perhaps even non-crypto
Needs	Maximal modularity & control with minimal opinionatedness from DAOhaus	Maximal simplicity & reliability with minimal overheads
Interface	SDKs, APIs, Dev Tools	GUI, Plug & play

We did discuss forking into 2 workstreams to work on different personas, but the upcoming upgrades (e.g. V3, Baal) and limited resources led us to the consensus that forking might not be practical right now.

Given the above, how do we choose which user persona to focus on? In the next section, we briefly run through the pros & cons on both sides.

4. Weighing the implications of each persona

	User-type Personas	Builder-type Personas
For	1. DAOhaus has always been known for simple & great UI 2. Building for users first help us figure out which primitives are essential. After this, we enable other developers to build on them. 3. With a simple UI, we can attract & retain an ecosystem of users that other Devs would want to tap on	1. We can let others experiement & build new things (e.g. bolt-ons & new interfaces) We can open up DAOhaus to enable new DAO personas (e.g. token unpermissioned DAOs)
“Against”	We may not have all the answers & should let others innovate with our backend	We might be going into Zodiac territory, which we might not be well-positioned to add value

During the discussion, we did not decide on 1 persona to focus on because:

1. The choice is not a dichotomy : Both users & devs are essential in our ecosystem (users attract devs, devs build use cases). We will most likely choose on a scale (e.g. 80/20)
2. The choice is time-dependent : As time passes, we will most likely re-assess and re-calibrate the focus to meet market demands.

Additionally, regardless of how we choose to dial our focus, we want to work in a Pareto-optimal way :

• Due to our finite resources, we want to solve 80% of the problems/utility/primitives and get the community builders to solve the remaining 20%. This is regardless how our focus looks like

A useful analogy discussed was Shopify. Today, Shopify has a solid core product (order, customer, inventory management), as well as a great developer ecosystem.

1. The choice is not a dichotomy : Both their core product & developer ecosystem are what makes Shopify a great product
2. The choice is time-dependent : Shopify started with a simple & reliable core product which attracted many merchants. With these merchants, they then had something valuable to offer (i.e. ‘customers’) and built Dev Tools & Relations to attract the developer ecosystem
3. We want to work in a Pareto-optimal way : Shopify focuses on the core experience (e.g. orders, inventory, payments) and their dev ecosystem works on specific use cases (e.g. email marketing, referrals, etc.)

To move forward, we decided that we needed to time-block our focus over a time horizon (e.g. 3 to 6 months) as the choice is not dichotomous & might change over time. Having a time horizon helps us move into action & focus on one persona, allowing us to build 80% of the utility and then re-assess our prioiritie again.

Next Steps

We had a good discussion on the different nuances & implications of both approaches & user personas, but it is not actionable enough. Next, we want to go divergent & crowd-source roadmap ideas from the team, so all magesmiths are required to:

1. Create their own ‘wishlist’ roadmap (6 months or longer) on how they’d allocate resources/focus on the different builder/user initiatives
2. Put it somewhere others can read eg hackmd or on the ‘Strategic Directions’ Figjam
3. Present it during our next Monday meeting

This aims to allow everyone to have a voice in this conversation, and bring us closer to a short-term focus & roadmap.

---

Appendix & Other Discussion Points

During the conversation, we had a section where we talked more in-depth on the different DevRel initiatives.

• Our current state of Dev Tools is decentralised enough that community folks can build off DAOhaus (e.g. Building a DAO interface using scaffold-eth, our Subgraphs, etc.)
• We should build our product with good code, open-source things & get community developers to work on builder-facing products
• Allowing other devs to tap on our backend can be beneficial in having more bolt-ons & interfaces (e.g. what if a DAO can have 1 view for community users, another view for core team?)
• How helpful do we want to be in building dev resources? e.g. We provide SDKs vs bring your own SDKs
• Building create-haus vs scaffold eth: If we want to attract non-DAOhaus devs, we should plug into scaffold-eth. If we want DAOhaus folks to build more quickly, we should continue on create-haus

[arentweall]

Magesmiths Roadmap Meeting 08-11

In this roadmap session, we discussed the roadmap ‘wishlists’ from various Magesmiths, identifying similarities and differences in how we look at objectives, tradeoffs and prioritisation.

1. Magesmiths’ Wishlists (A divergent exercise)

1.1 Sam’s diverge:

For DAOhaus V2, Proposal Cards should be the last major upgrade. We should use v2 as-is and all new ‘features’ should be done via Boosts, Skunkwerks Initiatives & community development. That said, there will be customer service & maintenance work for V2.

Once Proposal Cards has been completed, we should start planning for DAOhaus V3 as well as Moloch V3. Ideally we want to launch DAOhaus V3 that supports Moloch V3 upgrades.

Bill: Full support of this direction for DAOhaus to be the most human DAO platform out there

1.2 Amos’ diverge:

From now, we focus on improving our current product for our current user segment (via product stability, Safe features (GUI Dapp interaction & cross-chain safes), social features) & fostering more Boost building. Workstreams such as CCO & Boost community development should be done when fundraising & general developer interest is at ATH

In 6 months, when Moloch V3 is ready, we build new features (powered by Baal) to attract new user segments. Also, based on our learnings from Boost community development, we can iterate on our shortfalls (e.g. docs, grants, dev tools, curation, marketplace). This is a good time to also explore sustainability & revenue for DAOhaus

In 9 months, we should have a good foundation as a frictionless tool for DAO users. Here we can start more aggressive unbundling & modularity for greater experimentation among developers.

• Ven: 3,6,9 months is a good view & there are overlaps with Sam’s plans
• Jord: Good to consider sustainability. DAOs typically do better in Bear ma* rket, so we don’t have to be so worried
• Spencer: What is the Boost Developer Program? Amos: It’s to get more community devs to build Boosts (i.e. less building + more docs, onboarding, grants, etc.)

1.3 Dekan’s diverge:

Dekan’s Diverge starts with a more zoomed out view. We’re currently at the Modern era, focusing on compensation revamp, community voice, LPDAO/CCO and HAUS Mainnet Launch. Moving forward, as we move into the Atomic era, our focus is on 3 fronts:

1. DAOhaus V3: We unbundle V2, build a new component library & use these components to dogfood/build v3. We only build core features to achieve V2 parity (e.g. Proposals, Voting & Membership).
2. Boost Market: This is the only new feature we’ll build. When building the Boost Market, we want to increase HAUS token value capture & work towards DAOhaus sustainability
3. Boost Development: Here, we foster decentralised dev teams, community Boosts developers & more Skunkwerks experiment

We should aim for more decentralisation & the only centralised point is the marketplace.

• Sam & Spencer: We’re pretty aligned, except degree of unbundling & what’s considered core.

1.4 Spencer’s diverge

We focus on the 3 strategic focuses that Magesmiths have greatest impact on:

1. Best platform for DAOs
2. Ecosystem of composable tools
3. Economy of DAO-created value

The approach here is think of DAOhaus as an operating system. We work on core components (i.e UX improvements) and new primitives (for others to build on). Then, we create dev interfaces for easy access to these primitives.

In the short run, we focus on core UX improvements (e.g. Summoning, Proposal Cards, Navigation & Content, Hub). Gradually, we work on discovering new primitives (e.g. Marketplace, DAO composability, Multi-chain, Custom-DAO content & Curation).

• Jord: New UI should allow for substitution of different UI or even a launcher that launches differen Boosts
• Bau: Adding docs & content boosts would be helpful

1.5 Ven’s diverge

Currently, we are working on social UI, Moloch V3 Design sprint with community personas. In December, we aspire to launch HAUS on mainnnet & prepare for V3

Looking forward to February (Eth Denver), we target a DAOhaus V3 Alpha launch with a small set of use cases. This is not a full product release, but something deployed and available for use elsewhere. The full V3 launch should come in March.

After launch in March, April-June shuld be focused on new use cases & emergent integrations, before constant iterations in July and August

• Sam: In November, we might need a design (UI) sprint as well as a Dev Sprint
• Spencer: We should have a broader discussion on how it can guide other initiatives (outside of magesmiths)

1.6 Jord’s diverge

Jord’s diverge was a forum post on how we can build v3 from a software engineering point of view. Read more here

Bulk of the work is not in building UI/visual aspects but processing data on the backend. If we want somethign that’s safe, modular and scalable, we’ll need more time & planning to do it well. As a summary of the forum post, we’ll need to create the building blocks, shape of the app, routing, factories and then tie it all together.

On focus, we’ll most likely start with a 90% focus on building the core, and then doing a massive switch once we are ready to build utilities for communities. At this point, we want communities to build and ‘feed’ the DAOhaus monster to spawn new tools.

For more in-depth understanding, please read the forum post.

• Sam: It’s like a project plan, can help us work on it faster
• Jord: Launching some DAOs on v3 in a few months is manageable, but having a production-ready app is hard. We should really focus on testing, scaling and writing code for others. This is upfront investment that will pay off later (i.e. we don’t have to worry ‘is this going to break that?’)

2. Similarities in our Diverges

Similarities in executional focus

1. In the short run, we want to complete Proposal Cards upgrade for V2 & then focus on V3 after that
2. We want to launch an V3 Alpha product teaser by Eth Denver (Feb 2022)

Similarities in approach

1. We want to have a certain level of modularity & hooks for community developers to work on (the nuances in this ‘level’ is addressed in the next section)
2. We see Boost marketplace as a core way to scale DAOhaus functionality outside of Warcamp.
3. We see Boost developers as an important community group to nurture
4. We view DAOhaus sustainability & token value capture as important

3. Differences in our Diverges

3.1 What is the role of V2 in relation to V3?

We managed to achieve consensus on this - discussion is as follows.

We are not retiring v2, but treating it as a Petri dish where community development happens (e.g. starting new weird DAOs). This is valuable for us to discover new bolt-ons, boosts and even features that go into V3 development. We’ll need to babysit, maintenance and provide customer service for a while.

After some discussion, the V2 UI should work with V2 Moloch, instead of using our old code to support differnt contracts, enabling us to have more reliability & security.

Dekan shared that V3 should be built using component libraries. Hopefully our data has a similar shape to baal and we can implement core components (e.g. proposals, members, voting) and layer it on top of diferent frameworks/contracts (e.g. Zodiac)

3.2 How unbundled do we get with V3?

We have started to achieve some consensus on an approach, but will need to dive into details. This may be done during the Roadmap Meeting or the Dev Sprint in November.

First, we started with defining ‘unbundling’ and generally the team is on a spectrum between definition 1 & 2

Stance	Definition	Remarks
1. Most aggressive	The DAOhaus core is tiny & everything else is modular and accessible in different ways by different people	Proposed by Dekan
2. Moderate	The DAOhaus core is an operating system that exposes certain hooks/primitives which are built by other people	Proposed by Spencer
3. Least aggressive	Almost very little is modular & community developers need to talk to & integrate with DAOhaus to build new things	For illustration, no one is arguing for this

During the discussion, we leaned towards definition 1. More specifically, we are only building component libraries (for eventual community development) as well as a small UI that’s core to DAOhaus (i.e. Proposals, Members, Summoning).

The only other UIs we’ll build are Boost / DAO Marketplace & Explore pages (where we can help fulfil the role as connectors in the ecosystem). Explore could be a big opportunity for us. Like how Google indexes & help people discover web pages in the 90s, Explore can help people find communities (perhaps even non-MolochDAOs).

A key area of discussion is how the small core, together with the decentralised components and boosts can support a cohesive & good user experience.

4. Next Steps

From an execution point of view, Ven & Sam aligned that we’ll need a Design & Dev sprint in November to dive deeper on what goes into V3 Moloch & V3 DAOhaus.

• Dev Sprint: Dev exploration of Moloch V3, DAOhaus V3, ‘backward-compatibility’ with V2 (if any, e.g. Discover & Hub)
• Design Sprint: V3 UI & UX Exploration with community personas in mind

From a Roadmap point of view, these are the areas of discussion that can lead us back to planning a Roadmap

1. Key Question: Assess how the current approach can allow core features, boosts and all components to create a good & cohesive user experience. This should wrap up our alignment on how we want to approach DAOhaus as a platform.
2. Create a more defined list of ‘within-scopes’ and ‘out-of-scopes’ for the next 3/6/ months (perhaps 6 months for the v3 launch post-Denver). With the approach aligned, we can then work on more actionable items & ship!

Appendix

Another way of moving forward was brought up by Jord - We don’t actually have to start thinking about the split now. Like cells, we can start somewhere and continue building/growing the app, dividing only when we are ready to.

Similarly, in theory if everything is a component, then we can pick where the line is anywhere at any time. So maybe the right place to start is with everything as a component?