Objective
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.
Versions
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.
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 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.
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
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).
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.
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:
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
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:
delivery team getting better at estimating
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.
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?
