DAOhaus Product Roadmap 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?