<aside> 💡 The product discovery pipe manages the product & design work that happens prior to a feature entering the delivery pipe. Its goal is to streamline the processes that currently happen across different tools and increase the transparency and visibility of this work to the community. It´s collaborative work between product, design & tech

</aside>

It shall allow everyone to follow and comment the progress of features (requests) while being in inception without the need to keep up with slack conversations across multiple channels.

V1: The Inception Pipe covers the inception process from AFTER features/problems/needs have been prioritised in product curation.

V2: In the long run, the product discovery pipe is going to include the entire process from "Discovery Phase 1" until ready for the delivery pipe, i.e. is going to be a place where all feature candidates (problem or opportunity, that will turn into a feature with "Potential for Inception" - design projects, wishlist items etc. - will be collected, categorised and prioritised.

TBD: is it an Inception Pipe or Product Discovery Pipe?

Product Inception Pipe in Github

https://github.com/openfoodfoundation/inception-pipe/issues

1. The Pipe: Columns & Labels

COLUMNS

• Needs Inception | Newly Added, Discovery Phase 1

  Where inception requests are parked that are not yet prioritized in product curation → Things (identified problems/feature candidates) can come from Product Circle, Product Curation, Research Insights, Papercuts, "All the things", Wishlist Items, Feature Requests...

• Ready for Inception

  Upcoming feature candidates (=problems or opportunities, that will turn into a feature) that have been prioritised from product curation. They can come from wishlist, papercuts, user research, instances, grant funding etc.

• In Inception

  Issues for which the inception process has been kicked-off. Additional clarification / research is still needed. Discussions with Tech and Design happen here already if needed.

• Ready for Design

  Where design input is needed post product inception. Issues have most information required for design work to be kicked off.

• In Design

  This is actively being designed and has all or most design requirements. A designer is assigned. This can mean UX research, design thinking or 'visual' design.

• Review

  Issues open to the team for review. If approved, Issue goes into the Dev Pipe, otherwise back to "In Inception" or "In Design"

• Done / Ready for Dev

  Issues that are reviewed and approved. They go at the same time into the Dev Pipe ("Dev Ready") → using the Zen Hub Feature to connect workspaces

  LABELS

  Issues / Inception Requests that are newly created could require input from Design, Product, Tech and might be parked until further inception is prioritized

  • Needs Design Work
  • Needs Product Work
  • Needs Tech Work
  • Parked

  Issues that cannot move forward in the pipe, until they get input from Design, Tech or Product

  • Blocked: Design Input needed
  • Blocked: Tech Input needed
  • Blocked: Product Input Needed

  Labels about where the issue/epic is coming from

  • Wishlist
  • Papercut
  • Feature request
  • User Research
  • etc.

  2. Process: Inception Pipe → Delivery Pipe

  The Inception Pipe shall be connected with the Delivery Pipe so that features/issues that are ready incepted move automatically into the Delivery Pipe and allow the entire product development process to be synced and managed in one common place.

  <aside> 💡 ZenHub Workflows allows teams to sync the pipeline state of an Issue in multiple Workspaces. By setting up a Workflow, you can automate the movement of Issues between different Workspaces. This ensures Boards are always up to date reflecting the most current picture of progress in every teams Workspace.

  </aside>

  

  Prioritization → How do we decide what goes into the Inception Pipe?

  • Prioritization of "Needs Inception" Column to move into "Ready for Inception

  Workstream in here

  Inception Pipe Prioritization

  +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

  FEEDBACK/ Questions on this

  • Process: After an epic has been ready incepted (Status "Done/Ready for Dev"), shall they then move to the Delivery Pipe with all the information / discussions collected during the inception process or a "cleaner" version only?
  • How to involve instance managers in these discussions?
    • On Github? Or Discourse?

  REVIEW

  Review of the Product Discovery Pipe Process, based on feedback collected and experience with the Unit Price Comparison Epic as an Test Case.

  • The "Ready for Inception" column should mirror the "Next Up Section" in the Product Curation Discourse Post → Tasks copied, prioritized from top to bottom. This also helps so see better which of those topics are already in progress and where they are at
  • Product Curation Meetings use the board to discuss and (re)prioritise

  Questions that came up during the process + proposed solutions

  Where do things go that are not prioritized on the product curation list?

  • New Column: Needs Inception, where things are parked that are not yet prioritized in product curation → Things (identified problems/feature candidates) can come from Product Circle, Product Curation, Research Insights, Papercuts, "All the things", Wishlist Items, Feature Requests...

  How to ensure that everyone can add their issues but at the same time reduce the overhead for product circle and avoid this column to become overcrowded? Who can create issues? Could this replace the wishlist?

  • → Grooming of this column in Product Curation Meeting (possibly better every 2nd?)
  • If Issues added by community, put Label "Product Check"

  How to involve Community Feedback?

  Tools: Discourse is for discussions & feedback within wider community , GitHub is for documenting the outcomes and managing workflows

  Proposed Workflow

  • If an issue is approved to be ready by product, design & tech (it is in Review /QA) → Discourse Post with request for feedback/approval + "deadline" for feedback
  • Sign-Off: Creating groups of people that should be pinged for feedback and/or sign-off (1 nominee per instance?)
  • After community feedback has been collected, async synthesis of the feedback and summary goes as a comment into the epic in Github.
  • Session with product, design & tech leads of respective issue to decide which aspects of the feedback should/can be implemented, which might be a V2 etc → This is documented in GitHub and also in Discourse
  • Discourse is going to be closed after a certain time duration (like 2 weeks)
  • → Epic then goes into Ready for Dev

  Other open questions & notes

  • 'What is the role of our community?', raised by Frank in our product circle on the 4th of Nov This will help the community better manage their time in responding to 'needs community feedback' processes and why, how, when and what we need for them and limit expectations
  • How can we make this process more efficient in both time and cost? (trade-off between getting as many relevant people's feedback as possible vs. being respectful of time & ressources)
  • Where/how to involve user feedback to ensure we build the product for actual users?
    • Community feedback/approval is NOT user research, Instance managers do not represent all users we build for.
  • Many projects all at once "needing" feedback how to handle?
  • How do we encourage feedback from quieter voices and compassionately 'contain' those from vocal members?

  Eriol copy-pasting some notes from the (now deleted) page they wrote in:

  Community feedback, approval is NOT user research and not good practice.

  Instance managers do not represent all users we build for.

  Question: Many projects all at once "needing" feedback how to handle?

  Question: How well does async work verse synced meeting times for feedback? are we meeting multiple methods of feedback that community members prefer?

  Question: How do we encourage feedback from quieter voices and compassionately 'contain' those from vocal members?

  Question: How can we make this process more efficient in both time and cost?

  Eriol also suggested a goal to move towards around time logging is that cost of paid staff time can then be attached to the inception, discovery, product, design and community feedback process and budgeting, fundraising etc. can benefit from this.