Community Introduction
Introduction
This post is a continuation of the previous Product Working Group discussion. Since that last post, one of the key developments is the sunsetting of Upstream. With this consolidation of our products, many of the core problems that were outlined in the original post may no longer be a problem since our code collaboration products are under the same roof.
That said, and after various discussions with members of our core product teams, we believe there are still significant benefits to be gained by assembling a cross-functional team focused on supporting our core product teams.
In this post, I will details what I believe this group’s core responsibilities are in supporting our core product teams and various example activities we will take to accomplish these responsibilities.
Responsibilities
User research
This will be our core responsibility. Our team will work with core product teams to first identify user research needs. These can be both specific product research, such as usability testing or feature testing, or broad generative research to better understand various cohort’s needs.
We will help core teams formulate key hypotheses that needs to be tested for their product, identify and gather the required demographics, conduct the necessary user research, then synthesize and share those insights back to the core teams. The goal with this process is to enable teams to understand what their core user’s major pain points are, while allowing the core team members to focus on building the product.
Prioritization feedback and support
While our team will not dictate roadmap and feature prioritization for core product teams, we can be helpful in assisting product teams with prioritization advisement. In practice, this means the WG could help provide user needs and demographic insights to help teams make a decision, or help advise on an effective feature prioritization framework that’s suitable for the product vertical.
Following prioritization, we can also help provide feedback on product roadmaps. Roadmaps are often helpful not only for internal team members to understand when features should be focused on, but also for external team members (such as the Growth team) to understand when features will be available for our users. As with feature prioritization, ultimately roadmap creation should be created by the core product teams, but the Product WG could help advise on best practices of roadmap building.
Cross-functional user journey mapping
User journey mapping is an effective design exercise to understand the complete flow for users to accomplish various tasks across our tools. Not only does it excel at helping empathize with various pain points and weaknesses in our products, but it also helps identify potential opportunities for cross-product synergies. As with running user feedback sessions, it also requires a significant amount of user research and design sessions in order to comprehensively map out full flows. I believe there’s significant advantages to ensuring our products are interoperable and users can efficiently move from one product to another. We can use user journey mapping as a tool to effectively design these cross-product experiences.
Core Goals and Results
Provide actionable insights to the core product teams
This is our team’s primary goal. All our research and insights will produce various research artifacts that the core product teams can use. There are various forms these artifacts can take, including user personas, journey maps, feedback reports, etc. Each research project’s output should optimize for providing the greatest value to the core product teams.
Provide feedback for prioritization and roadmaps
As mentioned above, our team can help provide feedback for the core product team’s feature prioritization. Our team will have recurring syncs with core product team leads to provide additional context, feedback on roadmaps, or even support building a framework for product prioritization.
Support teams with cross-collaboration efforts
By utilizing cross-functional journey mapping, we can help support various teams by identifying key points in the user journey where a user may need to utilize multiple products to effectively do their job. By understanding these user needs and perceptions, we can design effective solutions to solve our user’s problems.
What we will not be responsible for
As mentioned before, this team will primarily be positioned as a support team for the other core product teams. As such, they will not be responsible for organization-wide strategy setting, including setting KPIs, North Star Metrics, or product strategy. Although these concepts are important, I believe our team should not be the ones responsible.
Further, I believe that there are inherent differences between user-facing product and protocol teams, such as the radicle-link team. Not only are there differing product goals (i.e protocol adoption vs user acquisition), but the employed strategies to achieve those goals will be greatly varied. The core responsibilities mentioned above provide much greater benefits to user-facing product teams than protocol teams. As such, I believe this team should be focused on providing support specifically for user-facing product teams, such as alt-clients, drips, and workstreams.
Team Topology
For the team to be successful at the core responsibilities outlined above, the main skills required will heavily lean towards UX and Product. In most instances, as we’re speaking to users and understanding their core needs, product and UX will typically create the framework and lead user research and user journey mapping exercises.
Currently, our members include:
@efstajas
@brandonhaslegs
@LukeF
With our small but capable team, we will start by running a research project within the OSS community to better understand their various cohorts and inclination to consider Radicle as a code collaboration platform.
Future
As the Radicle organization moves towards re-establishing itself as a DAO, there will very likely be structural changes to this team, both in topology and responsibilities. I have purposely
not touched on these aspects, as I believe we can re-evaluate once we’re ready for the transition to see which components have been the most useful for product teams, and how we can effectively integrate them into a decentralized team structure. For the time being, I believe there’s an immediate benefit that our teams can achieve by putting this Product WG in place for our core product teams as it’s structured today.
In closing, the above thoughts are initial ideas that we can try. At the core, the ultimate goal of this Product WG is to help support core product teams. The responsibilities and scope may change, and may very well differ between various teams, depending on their needs.