---
# System prepended metadata

title: DAOhaus Product Roadmap Notes
tags: [magesmiths, ' product', ' notes']

---

---
tags: magesmiths, product, notes
---

# DAOhaus Product Roadmap Notes
- Date: 2/25/2022
- Agenda: https://hackmd.io/0LYsx1FCTSKBvFn4hWhE9A
- Adrienne's notes: https://hackmd.io/XhylHe2UTsqY_iEWUyQIKA?view

Notes from Adrienne and jp

## Last 3 Months
- Review Last 3 Months - Product Roadmap 
    - We did it, Yeeter and raise 
    - We met our first and most important goal 
    - **Yeeter** - big success - help with our raise and several other - learned a lot about shamans and v2.5 
        - Super polished product running on it's own
        - 6-7 products that want to launch on this 
        - This came together well - tight focus worked really well - specialized apps is a win so far 
        - Good for morale 
## Roadmap Review
- V3 UX/UI + tech architecture 
    - defined stack
    - bunch of little rages - helped to understand the data side and stack choices 
    - Prototype was a good win on UX side / around 80% done, lot to do
    - Confusion: what is DH v3? lots of confusion in the room about the direction
    - A scope doc will be created from these meetings - simple and clear 
    - Dragon's Den Project Manager group has started 
- Maintanence 
    - Did okay here, a lot still in progress
    - Need to carry this into next 3 months 
    - Need to do triage workflow - currenly getting jammed on 
- Greater $HAUS visibility in app:
    - Get the features into the app as expected 
    - Keating integrated and will add more price charts/graphs for v3 to increase visibility further
- Boost docs & grants:
    - Got de-prioritized, work just started 
    - 7 items on the roadmap, and was hard to get to all of this with tight timeline and focus on the raise
    - 12 part tutorial series - 7 are complete, but will wait until there are grants 
    - How to build form, transaction, basics are ready to go
        - Publishing what we have is good, but we can wait until making sure these are used before doing more
    - How much effort are we putting into v2 boosts and how are they carrying over to v3? Will we need to contact devs to upgrade v2 boosts to v3?
        - Currently we don't have any boost devs, but we have some folks who are interested
    - Is it too early to orient folks to v3?
    - Can we do this *while* building v3?
- Deliver experiment formats & start Experiments:
    - Got de-prioritized, need to get reports down on paper 
    - Getting our learnings down and out to the community 
    - Haven't written much about the experiments, but there have been experiments (Yeeter, Daogroni) -- we can write up some docs if there is time
        - Can we do some retros on these?
        - Community visibility for learnings and could also help for selling Daogronis / Having interest in the Yeeter  
- Rage & Sage Teams
    - Accomplished goals! Even if not implemented exactly as intended, this allowed for additional focus (especially for Design team)

## Part 2: Reset on Product/Platform Vision
- What contract version do we target?
    - This will drive a lot of the project planning

### Contract Version (v2 or v3)
- What Moloch contract are we targeting? 
    - https://hackmd.io/JK2zSCSlSPG0pCQ9QPS9ww?view - reviewing datamodel + pros and cons 
    - Previous thought: we were going to reskin v2 and then quickly do v3 - a lot of confusion about this 
    - 
- Destination: Building *core libraries* (component library, data delivery library) that power **micro apps** starting with core DAOhaus UI
    - Enable and drive development for bolt-ons and extensions
- What is our deliverable? Should we keep supporting v2 as we move toward v3? To what degree?
    - How do we want to prioritize apps?
- Previous thought: we were going to reskin v2 and then quickly do v3 - a lot of confusion about this 
- Assumptions - does a reskinned v2 add a lot of value 
    - having this stuff easier to understand and user - there are a lot of pieces that we haven't been picking up 
- Assumption - v3 gets to market quicker 
    - compounds of new front end stack and unaudited contract - the confusion and chaos may delay things
- Supporting both versions adds lots of complexity up front and down the road
    - Hard for users to understand difference
- Is a reskinned v2 adding value for our DAOs?
    - Are people *ready* for v3 instead of a reskinned v2?
- Targeting v3 only gets to market faster for v3
    - v3 contracts address lots of current user issues, but there is more infrastructure to build and more unknowns
- Reskinning v2 adds value for current users, and could potentially bring in new users who may have given up otherwise whereas v3 caters to folks *already in the industry*
    - Some of our feedback about the value of v3 is skewed by folks who want more complexity, and there could be value for making things less complex
    - New stack and unknowns for v3 may decrease speed to market, so may not go to market faster
- Many folks not using DAOhaus since the v2 contract doesn't let them use in the way they need (lacks flexibility that comes with v3)
- How do we get to the learnings of v3 usecases as fast as possible?
    - This is the intent behind Team Rage
- What is included in "DAO Core UI"?
    - Either way we produce the component library and data kit/SDK
    - Core UI is *not* feature parity with current v2 UI
        - So much of the value of the modularity is creating space for community developers to add boosts and bolt-ons
    - Long term challenge for DH is building the *network effect* where userbase is big enough to attract devs to build ontop of DH
    - Important to start this process as soon as possible, and this could be more important than v3
    - Do we get here faster by just focusing on v2?
        - Are we doing a disservice by not focusing on the more composable v3 contract?
        - Move it in -> build composable infrastruture on top of this could be more valuable foundation
- Always have some friction with community devs needing to go through our workflow and learn about the legos
    - Can we make a more open API with Ceramic or Poster? Can we locate the state somewhere else to reduce time to start and move toward a flywheel faster?
- What happens if we spend months building v2 infra and then have to redo it when moving to Baal?
    - Baal app and Moloch app are identical but separate apps
    - Want cohorent UX in a single app, but this is balanced with composability
        - Concern with having both versions in the app -- hard to maintain, could be complex for users, etc.
    - Can we split out into smaller apps that can be composed and interact with other protocols?
    - How would we manage 10 apps? How would we manage this many workstreams?
- If we continue to focus on v2 will we then be *too late* when we move to Baal?
    - Risk of other teams may be building on Baal before we do
        - Could feel like we're building a legacy product out and not keeping up with the climate
- How long would a v2 app stay relevant on our platform? We'd likely expect folks to upgrade and migrate within 1-3 months when Baal is available
    - This has been the past experience. Can spin up an *upgrader tool*
- Won't be starting from a blank slate to focus on Baal if going straight there -- there is a lot of knowledge we'll bring with us
    - We have the talent to be able to do this and create tools that ensure that folks are able to create communities for their needs
        -  We need to be as composable as possible to interact with other approaches
-  We could also maintain v2 and v3 as separate projects with separate teams and backlogs
-  What if summoning/upgrade app has its own team? Marketplace/Hub? All of these can become more composable and have their own teams
    -  Breaking up our product development process into more modular approach and project specific workflows could be beneficial
        -  A risk is that we build lots of things and only have a few maintainers
        -  Top of funnel (1000 of ideas) -> implementation team -> only a few maintainers and customer support
            -  Need to figure out how to scale this process without adding too much stress and fragmentation
            -  May not be significantly more overhead on our end -- if all of these features are pushed into a single app it could be just as much to maintain
                -  Monorepo structure alleviates some of this
    
### Rev Gen, Raises, and Baal
- Focusing on Baal only has possibility to give UberHaus a fraction of shares from every DAO built on our platform
    - Could make this opt-in, and best way to do this is to have a *clean distinction* between staying on v2 (free forever) and v3 (potential value accrual to UH from this upgrade path)
        - This is still up for discussion, but having a clean distinction would allow for a path toward this
    - What would the community vibes be around this?
        - Much larger conversation, but Rev Gen topics are relevant to this conversation
    - If we think Baal is better for Rev Gen options, we'd likely want to move to that as soon as possible
-  Focusing on Rev Gen would allow us to focus more on the product instead of necessity of future raises
    - We might need to dedicate a team to the next raise 
        - Next level would be partnerships with bigger projects 
    - Any reason we can't be self-sustaining? 
        - We shouldn't be doing this if we didn't think so
        - Need to look at the space - not the time to be charging people 
        - Look at gnosis - they did growth and expansion to be a required bit of infra - did not do this by charging people 
- If Baal allows for greater sustainability this is a big reason to consider Baal right away over v2
- Not necessarily the right time to go straight to Rev Gen -- look at Gnosis, which has become a huge piece of infrastruture it isn't because they focused on growth, revenue, and expansion
- We could charge for convenience in our more revenue generating apps
    - Having bolt-on apps such as the Yeeter keep piece of incoming funds to support funding and development
    - Able to charge for convenience and brand
    - Once finished with Yeeter you have the *entire DAOhaus platform* to use for your DAO
        - Huge network effect potential when building these bolt-ons
    - Speaks to "DAOhaus as the admin platform"
    - 80/20 relationship:
        - 80% of folks heard about DAOs, but only 20% care about the proposals and voting
        - on the 20%, we have another 80/20:
            - 20% care about the actual voting, 80% are devs and could be huge value to us if we can support correctly
        - Bolt-ons could serve the initial 80% who are interested in being in a DAO, not specifically the 20% (of the 20%) who are "DAO Ops" devs
    - Are we building for communities with this split or are we building for communities with interest in active participation?

## Looking Forward (3 Month Period)
**Final decision: We should move forward with baal on v3 platform.**
- Should we invest our next phase on the thesis: Investing time into building boosts and bolt-ons will increase our community and network effect
    - Do user tests to test this hypothesis
- Tactically, each direction starts at the same place: building core DAO UI and other kits to support development
    - Assumptions we're making can be tested, but the priority should be on creating composable infrastructure
        - This provides the foundation for us to begin doing serious implementation, but we need a long-term vision
- Treasury Layer and Application Layer
    - "DAOhaus Killer" platforms have these layers with everything built on Gnosis Safe
- Separation of concerns that is missing is the Governance Layer
    - We offer a solution for the rigid nature of governance in these platforms -- our nuanced governance focus can be integrated
- **Treasury Layer | Governance Layer | Application Layer**
    - We can be one of the options for the Governance Layer
    - With Baal we aren't specifically the Treasury Layer in the sense that folks have options to use Gnosis Safes
- From an architecture perspective it makes sense to think of things in these separations of concerns, but from a DAO value perspective it's concerning to separate members/token holders from Treasury
    - This is a common theme in current DAO narrative
    - Important discussion to realize that *Treasury Layer* holds funds whereas *Governance Layer* decides how they're utilized
- We're talking about v3.1 with the flexibility to allow for Gnosis Safe deployment as a starting point
    - Gnosis Safe -> add on Moloch DAO as a module -> use DAOhaus interface
- We can focus on what we're good at, and others can focus on what they're good at
- Phase/Layer 0, Phase/Layer 1, Phase/Layer 2, Phase/Layer 3
    - Document this and add thoughts about each phase and where we fit into each one, and then validate it
- If looking from an **Ecosystem Tooling Perspective**, focus on longer term features such as exploration -- are these prioritized now? If we an lock in our thoughts and plans for this, it'll help us down the road
    - What are core features? What are things that can move to outer layers?
    - Focus on the core and extend outward to the additional layers
    - Base DH app is a Layer 3 app
    - We can focus on the *core features* and get these correct, but this begins to get complex when we think about adding modules and extensions through Shamans and Minions
        - Deciding if something is "core enough" to Governance or if feature should be moved into own app
    - New core app may not have some things we're used to such as boosts -- difference between core and bolt-ons could be handled via curation process
- If next 3 months is focused on Baal, what is next? Boosts?
    - Opens up design space to other things -- could architecture allow boosts to work with other DAOs?
- Strengths of DAOhaus: UI around DAO mechanisms and access to bolt-ons and boosts
- We should have a 3 month milestone, but we'll work out the scope
    - Start with component library and data delivery library, at least enough to build out the Core UI

## Action Items
[] Determine focuses of Team Rage and Team Sage, and how the actions support each other and progress on v3
[] Create new version of the Product Roadmap table for the next 3 months
[] Have larger product vision documented and able to be discussed
[] v3 scope doc one-pager that will act as output and North Star for next 3 months
[] Establish workstream for discussing scope of the core app (how small can we make the core app?)

- What other things are needed *besides* v3 focus? Rev Gen? Support and maintainence? Yeeter?
    - Some portion of the core app utilizing Baal?
    - How small can we make the scope of the core app?
    - Do we want to rage on how we'd handle fungible shares in Baal?