Product Discovery / Inception Pipe

Hello everyone,

@Erioldoesdesign & me have been working on a process to increase transparency and visibility of the product & design work and integrate the design pipe proposed in Discourse earlier in the overall product development process

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 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.


It is created in its own repo:
to adress some of the concerns raised earlier by @Rachel and others, to avoid “that devs starts to work on the issue while it’s still being incepted”, overcrowding the main repo…).

1. The Pipe: Columns & Labels


  • 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


    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 could 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.

    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.

Some things that yet need clarification


  • 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?
  • Where to involve instance managers and other interested folks in discussions, feedback around design etc?
    - Can Github be the “single source of truth” (Pro: have all information in one common place)? Or can? discussions still happen in Discourse, but decisions then be documented in the Epics/Stories in Github
1 Like

Also, working on a template that describes what a feature request needs to be "Ready for Design"

Here is our draft

(Mandatory)What areas of the product or experience are 'touched' by this work/feature?
    The back office product list and inventory
    The shopper experience product ist
    How much 'new' UI/UX do we want to introduce? Do the current 'building blocks' serve are need?

(Mandatory) Who are the personas/stakeholders to consider?
    Is it a super admin type user?
    New shopper?

(Nice to have) How much time do we want design round 1 to take?
    2 weeks of 3 days? deadline is product curation meeting number 25 on the xth october
    When do we want it to go into dev?
    Design points/Tshirt size estimation

(Nice to have) Where can design look for research and/or examples?
    Exsiting functions/examples

(Nice to have) This feature require research/testing?
    Are the team 'internally' arguing about it?
    Can customer support/product support with gathering user testers or will
    Do we have time and budget?

This is an exciting goal to achieve - thanks so much for thoughts to this. I want to echo the question of how/where to support or instance managers feed in? Some thoughts on that (and I don’t have a strong opinion - just agreeing we need to feed in somewhere). Options could be:
1.- At the wishlist phase on discourse – this works now and support/instance folks know the process mostly. BUT its a big job to digest a wishlist item and get it ready to enter the inception pipe. This would imply a wishlist curator function of sorts - since often there are multiple related wishlists linked (I’m thinking of issues related to taxes for example)
2.- Each instance nominates a support person who joins the incepting group and follows issues through zenhub . This ensures support experience is integrated - but at a big cost in terms of support time - not sure its realistic
3. There is a checkpoint or ‘label’ required before an issue moves out of inception - that its been seen by the support circle and commented on.

My point isn’t to add complexity. But I know we’ve seen issues in the past where something gets through development before we realize that there are different use cases out there. Often we have features used in different ways in different instances, and support folks would catch this.

Final point - is that I wonder if we could do something that gives a timeline to an issue? From a support perspective - we are building relationships with users. The users have had a problem that led to the issue. Users often want to know where there issue is at? After all, they are trying to run businesses and their livelihoods depend on us addressing their issue (or not - in which case they need to find other solutions). So - as a support person, I’d like to be able to relay to the user that their issue has been prioritized now, and is expected in… months (or something). So - communication throughout the process with support and instances feels important (at least to me).

Other support folks - do you have thoughts? @lauriewayne1 @lbwright22 @EmilyRogers @JessC

1 Like

Thanks for your feedback @tschumilas!

I think the 3rd ooption you propose would be the best as it

  • keeps discussions in one place (GitHub), considering that one of the objective of this pipe is to streamline processes & discussions that are currently happening across multiple tools

  • can happen asnyc and only if needed, so minimizes the support time

-> Thinking of a label “Support Feedback needed”, that could also be used when Epics are in “In Inception” or “In Design” to ensure early involvement.

Or the other way round, if there is an issue that is of interest for support we could have a label “Ping Support” that people working in the inception process make sure to request feedback from support before an issue moves out of the pipe?

Regarding Timeline: I think that would be great, but is part of a broader discussion as being able to give a (better) estimation is not only of interest for the product discovery/inception process but also for the development process.

I’m not sure it is realistic either. It’s great to have support’s input in inception, but to me input of instance managers is equally as important if not more.

I understand the need to keep everything in one place, but apart from the delivery team, no one is used to github. And it’s also a point of vue: for the delivery team it keeps everything in one place, for the rest of the community it adds a new tool. Which is not super user friendly. I mean just the whole concept of the repository is hard to understand when you are not used to it I think.
Also, as always when you land in later on in the discussions, you have a lot of post to catch up and not all of them are interesting.

I would like to propose that when global community consent is needed we reach to discourse - gather feedback there - and go back to github to finalise the proposal. Again when the team is ready, coming back to discourse.

I start feeling that I’m proposing that each time consensus is needed globally, we use discourse. This is something I need to work on with my pals from global-tools to come up with a proposal outside of this discussion but I thought I would share it here.

We kinda touch this topic last Tuesday during the product meeting when we were picturing notifying the instance-circle that stuff needed their attention / consent. I feel a combo reaching to discourse + notifying instance managers during global hangout (if this is going to be the place for instance managers to gather) is maybe something to try out.

But I’m curious to hear other thoughts ping @Kirsten @lin_d_hop

Thoughts on information management

I get this is up to the tools team, but I also get the feeling that things are getting a little muddled between information intentions -> community visibility compared to actually managing workflows.

In general:

  • Discourse is the place for community visibility.
  • Github is a place in which we are managing workflows.

So, it makes sense to me if:

  • Workflows of the delivery team (dev, product, design) are managed in Github
  • Community discussions/links/notes/core information for sharing are managed in Discourse.

This would mean that:

  • Most of the community is not expected to navigate Github. That would be like us all watching each other’s TODO lists. Micromanaging and boring.
  • The delivery team has a responsibility to make everything visible on Discourse. Ideally following an agreed process and format to help busy people digest things quickly.

This is not dissimilar to what we have… we’re just adding a few more steps as the team grows.

A Tangent for Context

Some of the responses to this thread seem to hint at concerns about community input at stages that this thread is not talking about. So I wanted to clarify (and hopefully not add confusion)
At a high level I envisage the whole OFN process going something like:

  1. Discovery Phase One - Identifying the next target area. This might be ‘improving reports’, ‘improving order management’, ‘implementing split payments’… it will likely be broad and vague. Discovery Phase One will involve combining quant data from support and analytics, qual data from instances, and probably be a little directed by funds (controversial!!). It will involve Product work in bringing this data together.
    Discovery Phase One will end with a proposal to Discourse for community sign off

  2. Discovery Phase Two - THIS is the stage considered in this post. This takes that next priority, as agreed by the community, and begins a stronger inception phase.
    As Jana points out in the original post, we need a V2 for Discovery Phase One!

A few direct responses

To things said above…

Regarding sign off by instances (aka support flag or tick)
This is a good idea. Maybe the tick is just an affiliated instance tick - each instance signs off on each inception. Instances can nominate who might tick it off - instance manager or a support person - decided on an issue by issue basis. It would make sense to me if the sign off process was a Discourse process, a presentation and sign off as the result of the Discovery work.

Regarding timelines on issues and features
Always hard. There are two skills at play here:

  1. delivery team getting better at estimating
  2. Support teams getting better at managing relationships without timelines.

Both are important because, even if we are world-class at 1, we will still get it wrong often, and that’s why its important to be able to do 2.

Regarding curation of Wishlists
There is much work ongoing to map the OFN product.
This mapping will help tag issues to product areas. It will also help tag wishlist items to product areas. Since this work will happen before we get through the already prioritised work I think everyone can take a deep breath and not think too much about the existing wishlist for a while.

Sorry that this post is so long!

1 Like

Agree. I think originally we were more thinking about how to best include instance managers in the process. But it could be the same mechanism for both.

I agree that GitHub is a new tool, but if it is about commenting it is not that different.
My concern is more that dicussions can become very long and maybe it´s better to use GitHub more to document the outcomes of these discussions and not the entire back and forth.
So that Epics are kept “clean”.

@Erioldoesdesign and me reviewed the Product Discovery Pipe Process, based on feedback collected here and in discussions and the 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, promote use of problem statement template and put Label “Product Check”

How to involve Community Feedback?

Tools: as @lin_d_hop pointed out: 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 lead 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
  • → Epic then goes into Ready for Dev
  • Can Discourse post be closed after a certain time duration (tbd) when feature is shipped and no further feedback given?

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?
    • We have to be aware that community feedback/approval is NOT user research, instance managers do not represent all users we build for
  • How to handle many projects all at once “needing” feedback?
  • How do we encourage feedback from quieter voices and compassionately ‘contain’ those from vocal members?

Here is the link to the Notion page:

1 Like