Magesmiths Roadmap Meeting 01-11

--- title: Magesmiths Roadmap Meeting 01-11 tags: magesmiths, roadmap --- The 01-11 Roadmap Meeting was a discussion around - **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? --- ## 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 | <li>DAOhaus has always been known for simple & great UI</li><li>Building for users first help us figure out which primitives are essential. After this, we enable other developers to build on them. </li><li>With a simple UI, we can attract & retain an ecosystem of users that other Devs would want to tap on</li> | <li>We can let others experiement & build new things (e.g. bolt-ons & new interfaces) </li><li>We can open up DAOhaus to enable new DAO personas (e.g. token unpermissioned DAOs) </li> | | "Against" | <li>We may not have all the answers & should let others innovate with our backend</li> | <li>We might be going into Zodiac territory, which we might not be well-positioned to add value</li> | 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](https://www.figma.com/file/nUYTYBvb2ARZUvrnSMP4KG/Strategic-Directions) 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