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?
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.
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:
Or, how about the following:
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?
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 Product Committee would be responsible for:
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 minimal configuration of a Product Committee should be:
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 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.
The main DAO assigns the roles and responsibilities that are now under the Product Committee.
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.
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:
(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.
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).
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.
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.
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.
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.
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)