This proposal is to discuss the creation of a Product Group within Radicle. The goal of this proposal is to ensure teams can effectively collaborate across Radicle.
The Radicle code collaboration ecosystem is currently designed for users to use both the CLI and Upstream in order to effectively collaborate on their development projects. Thus, it is essential for the features within both tools to be compatible as users will be experiencing the platform as a whole rather than distinct parts.
This has proved a challenge for our organization as we operate in a decentralized manner. A clear example of this problem is conflicting implementations of various features that solve similar, if not the same, user problems between Upstream, Radicle CLI, and Radicle Web App. While the current decentralized structure empowers teams to make their own decisions both from product and technical perspectives, it also presents friction for users using our platform.
In this proposal, I will outline what I believe should be our primary strategic goals, what I see as the core challenges we’re facing when developing the core Code Collaboration product flow, and what I think could be short-term and long-term organizational solutions to help solve these problems.
This section will outline a set of core goals that I believe we should strive for as an organization, and detail why I believe it’s important for us to align around these.
This is our top priority. In order for Radicle to be competitive in the marketplace, and successfully acquire users that currently rely on platforms like GitHub, we need to ensure that we are able to provide a seamless core code collaboration experience. This is especially important for our priority team persona (development-focused DAOs) as their teams rely on this workflow for their DAO’s success.
Although talented and capable, our team of core contributors is tiny relative to the teams that are building competing platforms. It’s unlikely we will ever achieve the number of resources to directly compete in terms of developer throughput. As such, it is vital that we prioritize our limited resources to provide the maximum amount of user value while minimizing overall development costs.
In addition to effectively utilizing our limited resources, we must optimize for agility. We all know how quickly our industry moves, which allows us the advantage of satisfying unmet market needs if we can quickly capture these opportunities. It’s likely we will soon see competing products that are also trying to meet the market. We should make the most of our first-mover advantage through quick innovation and value delivery. This will also allow us to effectively compete against large, sitting incumbents in our space.
In this section, I’ll outline a few core problems that I’ve seen, starting at the high level. I’ve also outlined an example of each problem which I believe are the symptoms of each of the core problems.
There seems to be misalignment between teams in multiple areas, including product vision, feature prioritization, and technical implementation. As mentioned before, our products rely on each other to establish a seamless experience for our users. Any misalignment ultimately results in a disjointed user experience for users and makes it much more difficult for teams to effectively use Radicle as their primary code collaboration platform.
Example: We have not been able to come to an agreement about how we should implement patches across Upstream and the CLI. Currently, this (same) feature is being developed using 2 different implementation methods, and will not be compatible across the tools.
There are instances of various teams trying to solve the same user problem. In itself, this is not a problem, but when combined with team misalignment above, ultimately adds to the risk of a confusing user experience. This will result in an increased risk of user churn, a low rate of user acquisition, and redundant development efforts.
Example: Both the Upstream and CLI teams are beginning to scope and develop user features around issue management and organization management. We have not been able to strictly align our efforts in order to create a holistic user journey across platforms.
Currently, when there are alignment conflicts that arise between teams, there is not a clear path to help resolve the issues. We rely on ad hoc coordination between the teams, which doesn’t always result in a clear consensus. This not only introduces friction between our teams but also results in slower development speed and value delivery.
Example: There have been multiple discussions around the feature scope of both Upstream and the CLI. Many times these scoping discussions result in conflicting ideas about what features belong on which platform. This ultimately leads to each team developing what they think is the right way to tackle the same user problem, resulting in end-user confusion.
In order to tackle the above-stated problems, I propose we create a Product Group. At a high level, this Product Group will be responsible for helping determine the overarching Radicle Product Vision for code collaboration and help facilitate team collaboration and alignment. The group could be formed with the following parameters:
This group could be a cross-functional team of 3-to 4 individuals representing the core aspects of Product, Design, and Technology.
This group could be responsible for working among themselves to determine various Radicle-wide strategies, including:
- Product Vision: This team could help determine the core product strategy and vision. They would be responsible for identifying and tracking market activity, competitor landscape, and core user needs in order to build informed product strategies for Radicle to remain competitive in the marketplace.
- Priority User Problems: This team could be responsible for gathering, synthesizing, and prioritizing user problems. By initially aligning on these issues, we can ensure teams are consistently delivering user value.
- User Research: This team could be responsible for running user research projects, understanding our core customers, and helping define our priority segment’s needs. The results of this work will help teams understand how best to solve various user problems within their platforms.
This group could also be responsible for helping teams effectively collaborate, assist in spinning up platform teams, and help arbitrage any potential conflicts that arise. This will obviously be on an ad-hoc basis, but could include:
- Defining Cross-Functional Work: This team could help define and prioritize work that will affect Radicle as a whole (e.g. general marketing/product documentation). This could include organizational work, such as general documentation and marketing.
- Conflict Resolution: This team could act as a neutral third party to help resolve any technical or product conflicts between teams. For instance, if teams were conflicted on two approaches in various tools to solve similar user problems, this team could help provide user research data to identify the optimal solution.
Evolving from the aforementioned Product Group, sub-DAOs can be created that sits between the “main” DAO and the various product teams. There could be various sub-DAOs including Product, Technology, Design, and other cross-organizational functions such as Legal. The primary goal for these sub-DAOs is to help facilitate coordination and alignment between the product teams. These sub-DAOs may be responsible for:
- Communication and alignment with the main DAO on budget and vision
- Aligning core product vision and features for product teams
- Determining priority demographics and organizational OKRs
- Aligning implementation details, such as data structure
- Align on product strategy
Basically, the core idea for sub-DAOs is to help decide on a direction for questions that will affect multiple products and users expect to work across the ecosystem.
We can strive to create common components that can be shared across all the tools in the Radicle ecosystem. These common components will help maintain a consistent style and ensure compatibility across tools. The goals are:
- Ensure consistent user experience across the ecosystem
- Ensure compatibility for cross-functional features across all tools
- Increase development throughput by providing extensible components
As an example, there could be a team that’s specifically focused on building the networking layer, whether it’s a p2p or a push/pull implementation. They would be responsible for testing which implementation would work best. Once finished, product teams would decide on a direction and implement the chosen networking solution into their products to ensure compatibility.
We can establish cross-functional teams that will own aspects of the product ecosystem that span across various teams. These teams would be responsible for ensuring that users have an understanding of Radicle as a whole. They could also be responsible for creating and maintaining documentation that spans multiple tools, helping user onboarding.
Currently, our teams are structured around separate products. When users are expected to use these various products in their complete workflow, it inevitably results in both technical and product dependencies between teams. One way we may be able to mitigate these dependencies are by structuring teams around full features, and giving them full control over how a feature is integrated, regardless of the application (distribution channel).
An example of this: Team A would own the entire commenting system. They would have full autonomy to build the foundational primitives to power comments.
Teams B and C would own the application layer, Upstream and Web App. Teams B and C would initially work with Team A to define where comments may be needed within their applications, helping shape the initial requirements.
After Team A is finished with the full implementation, Teams B and C would integrate comments into their application.