Scope and responsibilities#
Product describes the services and technology that 2i2c provides, the value they are meant to provide, and the stakeholders and user archetypes that are meant for.
This section is used to collect and share broad product-related information and strategy.
It is maintained by the Product Lead.
Background#
Since its formation, 2i2c has been successful in acquiring and maintaining a good number of client organizations that have benefited from its open, replicable cloud infrastructure services. 2i2c has maintained the ability to remain responsive to the needs of the communities it serves, but in doing so it has taken a somewhat reactive, ad-hoc approach to answering community partner or other customer requests.
As the organization is now more mature, and the breadth and complexity of its offerings and partnerships grow, it needs to shift to a more sustainable approach to the ongoing development of its products and services. This approach should allow it to make more effective use of its people and skills, and ensure that effort is always directed to the activities that are most valuable more closely aligned with its mission and value proposition.
Identifying a Value Proposition as our North Star#
A North Star is a core value, principle or goal that is used to help make decisions about what to do and when to do it. It starts with the organization’s mission, and is refined through a Value Proposition. Having a good understanding of what 2i2c’s North Star is will be key to ensuring that whatever we do is aligned with where we want the organization to be.
Becoming more intentional#
As 2i2c scales up to meet its strategic goals, the way we decide what to put our efforts into will have to shift from a partially reactive approach to product development to a more intentional, careful approach that will allow us to carve out the space for our team to research and deploy the right solutions for the most important problems our communities face.
This will necessarily affect the interaction between Partnerships, Product and Engineering, to ensure that our external conversations with communities, both current and prospective, are carefully considered against what would deliver the most value for the most communities, and be most closely aligned with our strategic objectives as an organization.
The product delivery flow outlined herein is meant to provide a framework whereby input from community stakeholders can be recorded, assessed, triaged and prioritized in alignment with what it is we want to achieve as an organization.
Principles of our Product function#
Here are some basic principles we need to keep in mind as we adopt a more intentional way of building product:
Not all feature requests are equally important.
Loud does not equate to urgent.
It’s OK to say no. We will make no promises until we’re sure we can deliver.
All non-critical feature requests will be triaged and prioritized according to the process.
We will ensure our resources are not overtaxed, and create space for our work to be proactive, rather than reactive.
We will limit the number of projects we run at any one time to ensure they can be adequately supported.
We need to balance competing interests. What’s best for science? What’s best for this community? What’s best for 2i2c? What’s best for the upstream open source projects we contribute to?
By collectively signing up to these principles, we have given ourselves permission to say no to projects that are not aligned with our long term goals or those of the communities we serve, and preserve our ability to intentionally move towards those goals.
The importance of a multi-stakeholder product flow#
2i2c faces three key challenges in the coming years: (1) expanding its community partner base, (2) achieving a pricing model that fosters sustainable growth, (3) lessen our dependence on external funding.
In order to achieve these, we need to adopt a process that lets us balance pro-active tasks (e.g. developing new features for our products and services in line with our Value Proposition) against reactive tasks (e.g. community support tickets).
It’s key that this process be agreed upon by all stakeholders within the organization, but specifically the Product Lead and Delivery Manager, with the Product Lead being responsible for defining the priority of major strategic initiatives, projects and milestones, and the Delivery Manager being responsible for how those projects are broken down into tasks for our Engineering team to work on, and how progress and team performance is tracked.