Content & User Experience - Season 3 Sentiment and Priorities

[0xNSHuman]

As we get closer to Season 3 Proposals deadline, Content Gateway and Mobile App projects are compiling the results of all the discussions and polls to gauge community consensus, identify priorities, manage risks and ultimately figure out where the hell are we heading to.

These results aren’t just to serve our projects, but hopefully to suggest ideas for other teams and their roadmaps. Both of our upcoming proposals rely on this research, so I came to conclusion that I should post this common part here, and then refer to it further in all the future documents.

Roadmap Voting

In our most recent post we asked the community what features should be introduced in our new user-facing product — Mobile App.

Since Content Gateway is a fairly technical thing that’s proven to be unintuitive to most people outside the Dev Guild, we had to employ the trick where we collected opinions through the prism of mobile user experience.

In order to do this, we crowdsourced the Mobile App roadmap, letting everyone vote for the shortlisted features, telling us how urgent they feel each of them is.

Click here to see the full voting results.

Quantifying Sentiment

After collecting the votes, we assigned a score to each of the poll options and applied a simple formula to rank all the items, placing the most wanted at the top.

This gave us a nice list of priorities to work with, but we still can’t possibly get them all addressed in one season. Plus, some of the features require more coordination with other actors in the DAO than other, which makes them riskier to take on.

To manage that, we applied another metric that we called Complexity Level, which helped us pick the top items up to the maximum allowed complexity total that we treat as an acceptable workload to include in our roadmap discussions.

The items we picked are highlighted with green colour, and the possible replacement items with higher assumed risk are highlighted with yellow colour.

Identifying Dependencies & Risks

Finally, in order to map the user experience features to Mobile App and Content Gateway scopes, we’ve built a graph of architectural dependencies where we analyzed what components should be implemented in Content Gateway in order for the front end applications to build the target features on top of.

While at it, we also figured which of the features can be ported to the website as well, so that we can make friendly suggestions for the Website project roadmap and offer our help with Content Gateway integration.

Here’s the resulting diagram, where green arrows represent the relationships between expected user experience, Mobile App functionality and Content Gateway capabilities that we are able to implement with relatively low risk. The yellow arrows represent opportunities that we are still exploring, but have identified as relatively risky in terms of integration and coordination.

BIG-ASS DIAGRAM ALERT
Click here to open the full-screen interactive version to scroll around. Or just open the image in a separate tab.

The diagram will be updated as we get more clarity around coordination with the other projects.

Factoring Research In

On the diagram above you can also see items that go into our Research scope. These are longer-term priorities that have enough teams and individuals interested in to dedicate some time to tackling them. These include:

• Development and adoption of a cross-project entity relationships standard, to make it possible, for example, to link all the independent data sources to a certain DAO member.
• Introduction and prototyping of the authorized & gated content concept, to enable optional control for the content producers over who can access the data.
• Researching monetization and decentralization models that would let independent content producers monetize their work, and figuring out how can we distribute the storage and maintenance to make it more decentralized.
• Prototyping Web3 wallet connection in the mobile app, to unlock a whole new dimension of features and experienced connected directly to the blockchain.
• Exploring monetization strategies for the Mobile App, which we already began doing and are possibly implementing solutions in Season 3.
• Brainstorming and testing waters in the direction of making the app a platform for other DAOs.

Defining The Scope

Even though we now identified the best opportunities to pursue, not everything shown on the diagram will go into our Season 3 scopes. The reasons for that go beyond this research and involve project management topics and concerns around contributor onboarding, housekeeping, coordination risks and mental health of the team members.

The complete list of priorities will be posted in Content Gateway and Mobile App proposals.

[jameswmontgomery.eth]

Thanks for putting this together! Seems like enough to get into S3, but I wonder how we can improve sentiment analysis in the future since Discourse votes would be highly biased toward core contributors

[0xNSHuman]

Agreed! And I wouldn’t say that this “research” reflects all the possible options either — we basically made people choose from what we pre-selected ourselves (based on soft consensus though!) . It can be improved a lot, we just did what we had enough time for this time.

I think it’s still a move forward for the DAO to have projects start exposing themselves during strategic decision-making, and treat this as a chance to explain the reasoning behind certain choices to stakeholders. It raises the bar for our budget approval process that we’re looking to improve in Season 3 .

[Tetranome]

Thanks for sharing your process. The idea of quantifying sentiment seems very key to getting a read on the diversity of a DAO environment, and they way in which you have translated that information into actionable goals and performed risk assessment therein has been a useful read.

I want to question you on a somewhat related topic:
How do you see your project handling general coordination & async workflows as you move forward?
Do you have any thoughts on how to avoid the project becoming overwhelmed by unproductive meeting time, whilst still keeping everyone plugged into the mission?
Will you continue to have such documentation as the above play any part in this?

[0xNSHuman]

Thanks for reading it!

How do you see your project handling general coordination & async workflows as you move forward?

This is a million BANK question quite literally. If I had a good answer to it, we wouldn’t be cutting our budget in half. I have experience coordinating remote teams across up to 17 timezones and 4 languages since before the pandemic or DAOs existed, but not in a permissionless environment like ours without formal duties and skills screening, and I actually think there is plenty of room for us to fail.

We’re going to work on creating a methodology in January, and one thing that will certainly go in there is our roadmap dependency management approach.

In a few words, no team member should ever be blocked by another team member if it’s possible to avoid by good roadmap planning and task assignments.

• The designs are not created yet? Not a reason to hold the development.

• Backend will be ready in 3 months? You can complete 98% of the frontend by that time if you know what you’re doing.

• Content release cycle is longer than anticipated? You should’ve created the right tools earlier.

The problem is that this kind of roadmap management takes a mix of both project management and technical skills to spot the dependencies properly, which is a rare occurrence even in Web2 world.

Do you have any thoughts on how to avoid the project becoming overwhelmed by unproductive meeting time, whilst still keeping everyone plugged into the mission?

Mission is supposed to be non-volatile, so anyone should be able to plug in by reading a Notion doc.

As for the progress synchronization, I believe no one actually takes anything useful away from calls alone, especially if there are more than 2-3 participants. And no, no one is going to read the call notes either. People will only read the stuff that their work will be validated based on, such as their list of tasks prioritized based on how critical they are for the timely milestone deliveries.

If 19 people spent an hour to learn that they are blocked by 1 dude — the project is still screwed after the call. They could instead open a Gantt chart or a Kanban board to see what independent components of the system they can work on in the meantime.

Ideally, the work of each of the team members would depend on 1-2 other at most, and these are the people they can do on-demand calls with when they feel the need for it. And this need better be obvious to them every time they open the project channel in the morning.

Will you continue to have such documentation as the above play any part in this?

I sure hope so. These documents aren’t something extra that I spend my spare time on because it’s fun. They are the foundation of building a roadmap that I wouldn’t be afraid to rely on.

[Tetranome]

Appreciate the reply. We’re currently rethinking the structure of the Academy project and this is good food for thought. Interested to see where your project goes.

[Sprinklesforwinners]

gm @0xNSHuman This is the first I am seeing this, it looks pretty amazing. What ever happened here?