@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: https://app.zenhub.com/workspaces/inception-pipe-5f82e534db531f000f8c09ff/board?repos=302405655
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.
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.
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.
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
- Feature request
- User Research
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