Light refactor of product docs

product/deliveryflow.md

@@ -1,68 +1,53 @@
-# 2i2c's Product delivery flow
+# Product delivery flow
 
-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 we are a small organization with a relatively large proportion of engineering talent, we work with a lightweight product and delivery flow, with an emphasis on up-front macro-level prioritization that empowers the Engineering team with the flexibility to define how to problem solve, break down, and prioritize their work at the micro level.
 
-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.
-
-[Our Value Proposition is defined here](mission:value-proposition).
-
-## 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.
+:::{figure} images/delivery-flow.jpg
 
-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.
+Process diagram of 2i2c's [Product Delivery Flow](https://miro.com/app/board/uXjVNvlBa6E=/?share_link_id=253320305785).
+:::
 
-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. 
+This document outlines such a process, designed to be transparent to the organization about what’s been worked on at any time, and to provide clear communication and collaboration points between Product, Engineering and any stakeholders, internal or external, that have a vested interest in the outcome of a project.
 
-Here are some basic principles we need to keep in mind as we adopt a more intentional way of building product:
+:::{admonition} ProductBoard is where most Product conversation happens
 
-- 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?
+We use a tool called [ProductBoard](https://www.ProductBoard.com/) to provide us with a centralized place for storing, tagging and later mining ideas around our product roadmap.
+This gives our team the ability to fully consider, prioritize, and potentially action the most important ideas.
 
-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 ProductBoard team guide and primer](https://docs.google.com/document/d/1UkFcv2klEBOEnZ4CoB7PnVYS6MNOn5fCfM7unbco2lI/edit?usp=sharing) describes how anyone on our team can use ProductBoard.
+:::
 
-# Defining our product Delivery Flow
+## How most team members participate in this process
 
-2i2c faces three key challenges in the coming years: expanding its community partner base, achieving a pricing model that fosters sustainable growth, and lessen our dependence on external funding.
+All team members are encouraged to participate in the Product process by **providing, refining, and discussing Insights**.
+To learn how to do this, see [the ProductBoard team primer and guide](https://docs.google.com/document/d/1UkFcv2klEBOEnZ4CoB7PnVYS6MNOn5fCfM7unbco2lI/edit#bookmark=id.27fegmw16krg).
 
-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).
+## 0. Our product operations principles
 
-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.
+First off, read [](principles.md) to understand the high-level goals and principles that drive this work, and lead to the system below.
 
-As we are a small organization with a relatively large proportion of engineering talent, we will work wih a lightweight product and delivery flow, with an emphasis on up-front macro-level prioritization that empowers the Engineering team with the flexibility to define how to problem solve, break down and prioritize their work at the micro level.
+## 1. The insights board
 
-:::{figure} images/delivery-flow.jpg
+Insights are tracked in [our Insights Boards](https://2i2c.ProductBoard.com/folder/MTpOYXZpZ2F0aW9uRm9sZGVyOjQ0OTc5ZmRmLWU0MTYtNDNiMS1hYzg1LTllZjFkZmQ4N2Q1Zg==).
 
-Process diagram of 2i2c's [Product Delivery Flow](https://miro.com/app/board/uXjVNvlBa6E=/?share_link_id=253320305785).
+:::{admonition} How to add Insights to Product Board
+See the [Guide to adding Insights in ProductBoard](https://docs.google.com/document/d/1UkFcv2klEBOEnZ4CoB7PnVYS6MNOn5fCfM7unbco2lI/edit?usp=sharing).
 :::
 
-The next part of this document outlines such a process, designed to be transparent to the organization about what’s been worked on at any time, and to provide clear communication and collaboration points between Product, Engineering and any stakeholders, internal or external, that have a vested interest in the outcome of a project.
-
-## 1. The insights board
-
 Any good product delivery flow starts with establishing a centralized repository for insights, a place to collect our knowledge of the wants and needs of the community partners and other customers we serve, and to record conversations we’ve had with partners about specific product enhancements we may want to consider. 
 
-While insights will naturally trickle in from our partnership support and sales efforts, community building initiatives, conferences, and other organic means, the most actionable and valuable insights come from intentional, active and engaged customer and UX research.
+While insights naturally trickle in from our partnership support and sales efforts, community building initiatives, conferences, and other organic means, the most actionable and valuable insights come from intentional, active and engaged customer and UX research.
 
 Insights are not tasks. They are not the basis of a backlog. They are knowledge that may be leveraged into feature ideas, projects, initiatives, or whole new products… Or not. 
 
 At 2i2c, we should always ensure that we are dedicating our skills, people and resources to fully understanding, capturing and responding to our communities’ most pressing needs, separating the signal from the noise and ensuring our efforts are always aligned with the most value with the widest community impact.
 
 Formerly, insights relevant to product improvements were captured on GitHub as conversations around projects, on Slack as casual conversations, or as emails between community partners and Partnership leads. As queries and comments on FreshDesk. They could easily get lost. 
 
-While those tools are still very much in use at 2i2c, we have now adopted a tool called [Productboard](https://www.productboard.com/) to provide us with a centralized place for storing, tagging and later mining this type of knowledge, benefiting our ability to fully consider, prioritize, and potentially action the most important ideas. 
-
 ## 2. The Ideas board
 
+Ideas are tracked in [our Roadmaps boards](https://2i2c.ProductBoard.com/folder/MTpOYXZpZ2F0aW9uRm9sZGVyOjExNGJhMzQxLWQwN2EtNDhlNy05MjVlLWZiNTY4OWVmODBmYw==) as well as [our Feature boards](https://2i2c.ProductBoard.com/folder/MTpOYXZpZ2F0aW9uRm9sZGVyOmQ2YmY3ZTVkLTFhY2UtNGU4My1hMDJjLTRmMzhhOGUyZDkxMw==).
+
 ### What is an idea
 
 Any single insight, or collections of related insights, can give rise to an idea, which is an actionable and well formulated suggestion of a project we may want to look into. Ideas are the individual items in the Ideas board. 
@@ -104,6 +89,8 @@ Ideas should be classified as one of the following, each with its own ticket tem
 
 ## 3. Product Initiatives
 
+Initiatives are tracked in [our Roadmaps boards](https://2i2c.ProductBoard.com/folder/MTpOYXZpZ2F0aW9uRm9sZGVyOjExNGJhMzQxLWQwN2EtNDhlNy05MjVlLWZiNTY4OWVmODBmYw==) as well as [our Feature boards](https://2i2c.ProductBoard.com/folder/MTpOYXZpZ2F0aW9uRm9sZGVyOmQ2YmY3ZTVkLTFhY2UtNGU4My1hMDJjLTRmMzhhOGUyZDkxMw==).
+
 Product Initiatives are ideas that we have decided to take a deeper look at, with a view to implementing them to produce value for 2i2c or its communities. The Product Lead, in collaboration with any relevant stakeholders and 2i2c’s Leadership team, will normally determine when an idea is worth taking forward to the Initiative stage. 
 
 **Initiatives form the basis of the Product Backlog**, the list of tasks we are or soon expect to be working on. As such, unlike Ideas, Initiatives are deemed to be “on deck”, requiring stakeholder input to actively triage, scope, and potentially implement.
@@ -112,7 +99,7 @@ Product Initiatives are ideas that we have decided to take a deeper look at, wit
 
 **Initiatives need to be finite and have tangible deliverables.** Indefinite partnership commitments or policy efforts do not fit within the Delivery Flow, and will need to be prioritized and handled at the strategic level.
 
-## 4. Scoping
+## 4. Scoping initiatives
 
 ### Goals
 
@@ -183,20 +170,20 @@ By default, the Engineering Lead will be responsible for signing off the Initiat
 ## 7. Done
 Successful release of a Initiative effectively concludes a Initiative’s lifecycle. Any new bugs or issues found after the release will be treated as new Ideas.
 
-# Learning from what we have done
+## 8. Learn from what we have done
 After every delivery, the team should have the space to reflect on what was achieved, celebrate the milestone, and record any learnings that could lead to improvements in the process for the next deliverable. Alongside regular iteration retrospectives, major milestones should be capped by a Milestone Retrospective, a ceremony designed to provide a safe and open environment for the team to express what they liked, didn’t like, and would improve about the process of delivering that milestone.
 
-# Communicating what we have done
+## 9. Communicate what we have done
 
 While it’s important to have a process that takes a concept from idea to release, it is just as important to make sure that we actively communicate what’s been done to our community.
 
 The product delivery flow therefore must be extended to ensure action is taken to clearly communicate the release of major milestones to our communities, highlighting the value we have delivered and how it is aligned with their needs.
 
 We should ensure that we have a process in place to follow up major releases with relevant community announcements, above and beyond the regular updates provided by Chris. 
 
-These announcements should be broadcast on the 2i2c’s site as well as any relevant social media channels, to ensure we keep engaging our community with our progress, while giving new or prospective community partners or other customers an opportunity to learn more about the kinds of features and services we could provide them.
+These announcements should be broadcast on [the 2i2c.org blog](https://2i2c.org/blog) as well as any relevant social media channels, to ensure we keep engaging our community with our progress, while giving new or prospective community partners or other customers an opportunity to learn more about the kinds of features and services we could provide them.
 
-# Outcomes
+## Outcomes
 
 A scalable, sustainable product delivery flow helps to provide us with the tools we need to sift through ideas and community partner, customer or end user requests in a more intentional way.
 

product/index.md

@@ -5,9 +5,10 @@ They work alongside engineering teams to define ways in which we aim to improve
 
 ```{toctree}
 overview.md
+principles.md
 structure.md
 deliveryflow.md
 prioritization.md
-pricing/strategy
-pricing/cost-model
+pricing/strategy.md
+pricing/cost-model.md
 ```

product/overview.md

@@ -4,3 +4,35 @@ Product describes the services and technology that 2i2c provides, the value they
 
 This section is used to collect and share broad product-related information and strategy.
 It is maintained by the {role}`Product Lead <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.
+
+[Our Value Proposition is defined here](mission:value-proposition).
+
+## 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. 
+
+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.