DAOs will need cohesive product strategy and flawless delivery to thrive and compete with Web 2.0 behemoths — here’s how they can do it (and decentralize product management on the way).

The following article is a collaboration between myself and Antoine Sakho (sakho.eth). It expresses the authors' ideas and should not be understood as an official communication of any kind representing any entity other than themselves.

Decentralizing activities and organizations is a hot topic nowadays with the rise of DAOs (Decentralized Autonomous Organizations). Communities like Sushiswap or BanklessDAO have gathered around ideas — and successfully turned those ideas turning into full-fledged products without compromising on their transparent and distributed community nature.

But decentralization seems to work best with clearly defined goals to be achieved, as well as autonomy for small teams and the people that contribute to these outcomes. For example, imagine a community/DAO that wants to increase the reach of a specific blog post: every member can easily use their own social networks to push that article and increase awareness about it.

But what happens when you have more complex goals? Or, when you have more questions than answers? How can we decentralize complex problem-solving disciplines in an organized, efficient, and engaging way?

Why centralize at all?

Product management has evolved a lot in the last decade, shifting companies from a feature factory approach to small, autonomous, outcome-driven teams - aka, squads or product teams (as extensively preached by Marty Cagan).

A key reason why these product teams have taken over traditional, functional silos (i.e. separate engineering, design, and strategy teams) as the standard structure within both software startups and giants is speed. Because these teams are empowered (they own the domain they are in charge of) and self-sufficient (they have all the skills needed to ship the product), they can make decisions much faster and win the markets they’re going after.

But to do this efficiently, it is crucial that someone (1) defines a cohesive product vision based on deep customer understanding, (2) aligns team members to this vision, and (3) helps coordinate their activities to ship a successful product. Enter Product Management, whose raison d’être is to

“shepherd [the team] from problem identification through to product launch, ensuring that each node in the network is aware of the progression of the others, and that users increasingly want what is being developed. [...] In a world where speed is king and the world is changing exponentially, having time to develop consensus before action is often a luxury. Teams need critical decisions made on a daily basis in order to maintain speed, and those decisions have major trade offs and/or conflicting interests among stakeholders. Driving those decisions is no one else’s job but the product manager’s. [...] Finally, organizational scale brings with it multiple teams. And an effective product development system coordinates and focuses those teams towards the company’s vision. [...] Product managers support company wide efficiency by ensuring no duplication of effort, and sharing infrastructure to enable other teams to go faster.”

(excerpt from the exceptional Black Box of Product Management by Brandon Chu).

So, one way to look at product management is as a function for centralizing information and decision-making, one that enables speed and scale in a world moving at exponential speed. And that function, with all the efficiencies it unlocked, was instrumental in scaling the Web 2.0 products we all use every day.

The challenge of decentralized Product Management (dPM)

Maybe because web3 values decentralization so much, product management as a function seems to be absent from most DAOs. This creates, we believe, massive issues in alignment and coordination. Decision paralysis, design by committee, endless consensus-seeking… we are already seeing many inefficiencies in the way teams build products within DAOs. Go lurk in a few DAO’s Discord servers for a little bit and you’ll see for yourself. These issues, in turn, are reflected in the poor UX (user experience) that is plaguing so many web3 products today, severely limiting adoption to the brave and patient few.

Whenever DAOs will start having several teams working on the same product — usually what happens when a product scales — these issues will be magnified.

Consider these scenarios:

• Two teams within a DAO decide at the same time to work on improving a sign-up rate on a product. The first team decides to move the sign-up button to the center of the landing page with a large CTA, all above the fold. The second team thinks that social proof is the problem, and wants to change the above-the-fold section for a big carousel of happy customer quotes. Of course both changes cannot happen at the same time, and if there is no entity to facilitate the coordination of initiatives and allocation of resources, a lot of time will be wasted, which might lead to losing important time to market, or worse, no actual improvement being shipped.
• Teams want to improve a given product, and they create proposals for the whole community to vote on (this is not about surveying a community and discussing potential ideas, but actually asking members to decide which one should be implemented). Most voters likely won't have any expertise in product development, which can lead to voting for an idea that might actually harm the product or might not even be feasible to begin with. Imagine surveying a whole country to choose between two types of experimental vaccines for a disease. How many of those votes will have any scientific background to select the best proposal? That’s why well-functioning democracies rely on experts to make (or at least recommend) technical decisions. If DAOs have a tech committee to approve code changes, why not adopt the same approach towards product development?

Or, how about the following:

• Teams decide to build features independently, and without coordination end up creating a Frankenstein of a product (i.e. confusing and complicated). Such products struggle to gain large adoption and scale due to their lack of focus. This article demonstrates how for instance Sushiswap has been growing without coordination and guidance, harming its ability to gain market share, or even putting it at risk of being disrupted. “Sure, Uniswap may not have Sushi’s range, but it has something arguably more important: direction. There’s an irony that a project named Sushi feels spiritually closer to a paella. [...] If Sushi wants to win over the doubters, and become more than just crypto’s most compelling case study, it will need to chart a clearer path forward”.

Such scenarios exemplify how lack of coordination can lead to a destructive tug of war that won't add value to the organization. So, how can we make dPM (Decentralized Product Management) happen and avoid wasting precious time and resources?

Towards Sub-DAOs & Product Committees

The most common pattern for traditional companies is to be organized hierarchically. Strategic decisions are often made by the top of the org. chart and are then trickled-down to teams who execute them. This approach may initially seem to be the only way to actually enable large companies to work and move towards a common goal - but at the cost of leaving employees feeling mostly disempowered and unhappy, as the decline in job satisfaction over the last two decades and the current ‘Great Resignation’ seem to show.

But what if we could bring only the best of both worlds to DAOs? On the one hand, the strategic direction and rapid execution common in traditional organizations, and on the other, the ownership and empowerment of the decentralized web? Meet sub-DAOs.

Sub-DAOs are a pattern that we see emerging in many DAOs. They might be called by different names (for instance, they go by the name of guilds within BanklessDAO), but a sub-DAO is nothing more than a subset of individuals contributing to a DAO, with strong domain expertise (i.e. design, finance, engineering), a narrow set of responsibilities, goals, and (optionally) a budget. The Aragon Network DAO is an example of this approach, where three sub-DAOs have been created so far, electing individuals to make compliance, executive, and tech decisions faster.

Those sub-DAOs can always be changed, dissolved, or have their decisions vetoed by the parent DAO, enabling both fast decision-making for day-to-day topics, as well as fully decentralized decision making for high-level ones. And of course, elections are held with community participation and vote.

Product teams are the crown jewel of Web 2.0 businesses (generating high impact and value for companies like Facebook, Amazon, Google, etc.), but, interestingly, we are not seeing many Product sub-DAOs in the web3 space. Leveraging the design of sub-DAOs with specific responsibilities and an elected committee, we propose the creation of "Product Committee" sub-DAOS, to bring the impact and value-creation we see in Web 2.0 to the decentralized world.

Teresa Torres (famous product person, author of Continuous Discovery Habits) recently wrote an article where she outlines how product leaders should lead their product teams with outcomes. A similar (not to say the exact same) approach is what we envision.

The upcoming sections will use the Aragon Network DAO as an example but could be adapted to any similar DAO, accounting for their unique circumstances.

The responsibilities

The Product Committee would be responsible for:

• Checking regularly with the Aragon Network strategy and goals;
• Converting goals into problems (or opportunities) that need to be solved, e.g., Aragon Network has a goal of increasing active DAOs in a given period. The Product committee converts this into two problems - for instance “Creating a DAO is too complex” (an acquisition problem) and “Not enough DAO members engage in governance” (an activation/retention problem)
• Defining the budget required for a cycle (i.e, a semester) and submitting it for approval;
• Creating the bounties/grants for specific problems that need to be solved in Aragon products (within the approved budget);
• Reviewing/Evaluating bounties/grants submissions and selecting winner(s);
• Hiring community members or teams for specific projects (within the approved budget), e.g., The Product Committee wants to perform competitor analysis and doesn't have the manpower to do it. It can hire someone for this specific project.
• Providing product metrics for community members with public (or gated) dashboards;
• Providing a roadmap of current and potential future initiatives;
• Evolving design systems and ensuring their proper application within Aragon products;

Even though the Product Committee is responsible for all the above, it doesn't mean it should make decisions without ever consulting the community. The sub-DAO design does not imply getting rid of community participation, it just enables more focused conversations and fast decision making.

The Product Committee should constantly poll interested community members on its decisions (problem and opportunities definition, prioritization, etc), as well as communicate them in a clear and transparent manner.

And under certain conditions and with clearly defined rules, the community should be able to remove committee members were they not acting in the best interest of the organization.

The roles

The minimal configuration of a Product Committee should be:

• Product lead - ensures products are delivering value to customers as well as to Aragon. The product lead is responsible for tracking metrics and finding potential gaps in the user experience that can be improved to reach the organization's goals.
• Product design lead - ensures products have great usability, and users can easily get the value they came for. The product design lead is also responsible for ensuring the evolution of the design system, keeping up with the latest UI/UX trends.
• Tech lead - ensures products are running as free of bugs as possible and identifies potential improvements/fixes that need to be done. The tech lead is also responsible for ensuring the grants created by the committee are feasible from a tech standpoint.

This triad should be in constant alignment, just as if it were a regular product team.

Of course, extra roles/positions might be necessary, especially depending on the size of the organization and/or amount of products.

The flows

The following image shows the main flows that allow the Product Committee to ensure a coherent product vision is maintained in a decentralized scenario. Worth saying that other sub-flows or variations can (and will) exist depending on each case.

1. Assigning responsibilities

The main DAO assigns the roles and responsibilities that are now under the Product Committee.

2. Application + Election

Community members can apply to fill open roles during the election period, and the community votes to elect members. Elections could happen every year, so the team has time to deliver results. In the first semesters of the existence of the DAO, the roles might be (fully or partially) filled by direct nomination of some core team in the main DAO, so the process of decentralizing product management happens in a progressive way.

3. Definition

Given that the main DAO has defined objectives and goals for a given period of time (for example, a semester), the Product Committee converts them into problems that have to be solved.

As an example, imagine that the main DAO sets the goal of increasing the number of Guardians in Aragon Court (Aragon Court is a dispute resolution system for web3, and relies on human guardians to rule upon disputes that were created). The Product Committee should dig deeper into the problem, interview people, run user tests, and come up with the hypotheses that need validation:

• Do enough people know about Aragon Court?
• Are there enough incentives to be a Guardian?
• Are gas costs too high to make Guardian interactions viable?

(In)validating hypotheses can be done by the Product Committee, or by the community through the use of grants for user research. Let's assume the problems have been identified. At this point, the Product Committee defines grants and/or bounty programs for each problem that should be tackled, and where applicable, links them to a measurable KPI target that will help assess the impact of the work produced.

4. Proposal submission

Once the team delivers, the Product Committee reviews delivery to ensure quality and adherence to Aragon's standards (this can include a range of topics, like, UI components, code standards, brand tone of voice, etc). The committee should ask for guidance or validation from other sub-DAOs as needed (for example, as the tech committee if the code should be audited for example).

5. Proposal selection

The Product Committee can consult the community to help select the proposal — there could be more than one— they think will bring more value. The final decision will be made by the committee, assigning a specific reward for the given proposal(s). The reward will be paid with an Escrow contract, with one or more milestones — ensuring the squad knows upfront that funds exist to pay its work, and will be released upon delivery.

6. Delivery

The team that submitted the selected proposal starts working on the delivery. This could range from a user research study to actual code ready to be deployed.

7. Review

Once the team delivers, the Product Committee reviews delivery to ensure quality and adherence to Aragon's standards (this can include a range of topics, like, UI components, code standards, brand tone of voice, etc). The committee should ask for any guidance or validation from any other sub-DAO if needed (for example, as the tech committee if the code should be audited for example).

If delivery satisfies the original request, whether it is code shipped, a KPI target that was hit, or a mix of both, the Product Committee releases payment for the milestone. Otherwise, it can request additional changes, and iterate until delivery meets the standards initially specified.

The Product Committee then keeps track of metrics (and makes them publicly available for ANT holders) after delivery so the community can be informed of the progress in solving the problems/opportunities that were defined. We could also envision here the use of UMA KPI options to automatically release funds upon hitting the KPI targets.

Community involvement in Product Committee decisions

One might say that this design gives too much power to a few individuals, which would be just centralized decisions all over again — but in contrast to traditional organizations, the very concept of sub-DAOs invites community members to participate in key decision-making, albeit in a curated and efficient way. In addition to the fact that sub-DAOs can involve the community in their decisions, mechanisms for the community itself to dissolve the sub-DAO, veto its decisions or intervene makes the sub-DAO design even less at risk of overcentralizing.

In order to create stronger incentives for optimal decision-making within the Product Committee and get its members to put skin in the game, we could even envision a system whereby elected members of the Product Committee could “back” a decentralized team's proposal by staking some of their own DAO governance tokens — taking a profit (from the reward given to the team whose proposal they had backed) in case of success or losing their stake in case of failure.

Final thoughts

DAOs are in an early stage of their maturity cycle, which brings opportunities but also challenges. One challenge we see is that the colossal volume of capital pouring into the space may be creating a false sense of security, leading DAOs to disregard product adoption and evolution. Such behavior would quickly kill DAO's Web 2.0 counterparts.

As the DAO model scales up, more organizations will rise, and we believe that the need for decentralized product management will only become more obvious. DAOs that won't address this will be left behind.

Web3 is bringing serious disruption to traditional business and ownership models, empowering communities and individuals to take part in shaping the products and services of tomorrow. We can speed up this disruption if we are able to allocate the right resources to the right opportunities and, just like product management allowed Web 2.0 companies to become giants, dPM (decentralized product management) will allow DAOs to take on these Goliaths.

Thanks to those who were kind enough to review and provide feedback on this post: nettra.eth, robelkin.eth, and the Aragon team (Andrea, Priscille, sio.eth, Ben and Daniel)