---
title: Roadmap Meeting 15/11
tags: roadmap
---
# Roadmap Meeting 15/11

We started the roadmap meeting by taking stock of everything that our app does today. Following that, we asked ourselves "Which features are most crucial to helping DAOhaus achieve its strategic goals?" That will help identify the core vs peripheral features in DAOhaus.

## Taking stock of our features
When looking at what is core or periphery, there are 2 levels of importance:
1. This feature is important for the app to work
2. This feature is important for DAOhaus to achieve our vision (i.e. empowering purpose-driven communities)

We aligned that both 1 & 2 are important in deciding what is core and periphery, ending up with this diagram below. If features fulfil 1


| S/N | Feature Group | Remarks |
| --- | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| 1 | <li>User/Members</li><li>Proposals</li><li>Treasury (NFTs too)</li> | These are **core** features to making DAOhaus work |
| 2 | <li>Hub-General</li><li>DAO config</li><li>DAO metadata</li> | While DAOhaus can still operate without these features, these features' inclusion help us achieve our vision. These features are **core**. |
| 3 | <li>Boost Marketplace</li><li>Bots & 3rd party integrations</li><li>Playlists</li> | These are upgrades to DAOhaus functionality & designed to be decentralised in mind. These features seem to be **periphery** |
| 4 | <li>DAO Summoning</li><li>Explore / Discovery</li><li>Allies</li> | If DAOhaus wants to be the social layer of DAOs, then these should be core features too. These features seem to be **core** |

> Side point: Currently, most of the features in 1 & 2 are more focused on Moloch DAOs. In the future, we could make it work with other DAO frameworks, so DAOhaus becomes a DAO-hub instead of just a MolochDAO Hub.

## **Core vs Periphery: Which experiences need to be customised?**

| Type of Feature | Needs to exist | Needs to exist in 1 particular way |
| ------------------- | -------------- | ---------------------------------- |
| Core Features | Yes | Yes |
| Peripheral Features | Yes | No |

For the first category of features, they apply to every user and more importantly beginner users. There are benefits in having an opinionated and 'best-in-class' user experience, so we should be more opinionated in these features.

For the second category of features, they are essential but there could be many different ways to do it. Warcamp should build the Primitives for these features, so that other developers can customise and build different approaches. Summoning a DAO is a good example here - it's crucial but there are many ways to summon a DAO

> Note: There could be some features that start out as 'core' and standardised, but eventually become 'periphery' and customisable, such as summoning a DAO.

:::warning
There seems to be consensus on this definition, but we need to go more granular into specific features. This is because different feature sets in 1 group have different roles & needs to be standardised/customisable.
:::

## **How do we build the different parts?**

Instead of having Warcamp build everything, we could have the 4 feature groups as decentralised core apps built by different teams, but integrated together seamlessly. After some discussion, we aligned that having a cohesive and smooth user experience should be prioritised as the most important

To achieve the above, we need to have some standards in our implementation, such as:
1. Clear ways for different feature groups to integrate & talk to each other
2. Common navigation & user experience (i.e. having clear data & UX scopes for DAOs vs individuals)

Adrienne shared the following diagram which seem to accurately represent the team's understanding. This discussion can be a good starting point for further discussion


Also, we need to balance decentralisation with feasibility and timellines, avoiding the scenario where we diminish executional efficiency and product quality for decentralisation.

:::info
The team seems aligned on decentralising while preserving a cohesive experience. Next steps are more executional - looking into design & planning
:::

## Next Steps

Some of these discussions (e.g. designing architecture & user experience) may be better ironed out in Sprints, but we've scheduled another followup roadmap planning session on Thursday to run through this.

A key focus of the discussion is to prioritise what we want to work on, given our limited resources, as well as define how we will approach design & building