Product Development Flow
Overview & philosophy
Bramble’s product mission is to consistently create products and experiences that users love and value. To deliver on this mission, it’s important to have a clearly defined and repeatable flow for turning an idea into something that offers customer value.
This page is an evolving description of how we expect our cross-functional development teams to work, and reflects the current workflow being leveraged. All required actions or outcomes in this page are denoted as follows:
Denotes a required aspect of the product development flow.
Feature development is expected to pass through all phases to achieve specified outcomes, while the rest of the workflow should be considered as a set of best practices, tools, and recommendations. We realize there are unique cases in which certain product improvements may not need to flow through all the phases. We trust product managers to use their best judgement with alignment from their design and engineering team. The goal of this page is to support teams in their workflows by highlighting the necessary outcomes to target in each phase as well as sharing strategies/tactics, activities, teams can employ to achieve these outcomes. Additionally, this page aims to clarify the minimal set of required actions, such as labels, needed across all phases to keep the the product system efficient in terms of tracking, searching and cross-functional collaboration. To maintain clarity and avoid confusion, we do not list optional actions on this page but teams may choose to employ additional actions, such as labels for planning, even if they are not mentioned on this page.
As teams leverage the product development flow, they may find that certain strategies/tactics are serving their teams well toward success. Therefore, we welcome MRs to this page, so we can create a robust playbook of options to build valuable features for customers. All team members are encouraged to follow the change process for this page to share their best practices.
But Wait, Isn’t This Waterfall?
No. Although the phases described on this page appear to be independent and linear, they are not. They’re presented in this way for simplicity and ease of navigation. At Bramble, we do not promote working in a linear manner. Phases in the product development lifecycle may overlap or occur in parallel.
We aim to achieve key outcomes in each phase in order to de-risk subsequent phases. However, we are not dictating the order we go through the phases, or the time spent in each. When teams have a high confidence in their direction, they should feel empowered to skip or shorten phases that won’t contribute to improved confidence.
Examples:
-
An engineering team conducts a technical review while other team members are performing Validation Phase activities. The team can then move to the Build phase rapidly with high confidence that their improvement is good for customers and technically feasible.
-
A bug is reported by a Bramble customer. The Product Manager tests the bug and confirms its existence (Problem Validation). The team is extremely confident in the solution , so Design and Solution Validation are not needed. The bug is moved immediately to Build.
Workflow Summary
We use workflow labels to efficiently communicate an issue’s state. Using these labels enables collaboration across teams and communicates an issue’s current state.
Issue descriptions as the SSOT
Issue descriptions shall always be maintained as the single source of truth.
It’s not efficient for contributors to need to read every comment in an issue to understand the current state.
- Issue description accuracy should be maintained by the DRIs throughout each phase. However all collaborators can and should contribute when they see discrepancies or needed updates.
Validation track
For new ideas where the customer problem and solution isn’t well understood, Product Managers (PMs) and the User Experience Team (UXers) should work together to validate new opportunities before moving to the Build track. The Validation track is an independent track from the always moving Build track. PMs and UXers should work together to get at least two months ahead, so that the Build track always has well-validated product opportunities ready to start. Milestone work should be prioritized with the understanding that some milestones may include more validation efforts than others. Validation cycles may not be necessary for things like bug fixes, well understood iterative improvements, minor design fixes, and technical debt.
Validation Goals & Outcomes
When: When our confidence about the proposed problem or solution isn’t high. For example, if we aren’t reasonably sure that the problem is important to a significant number of users, or that the solution is easy to understand and use.
Who: Product Manager, Product Designer, UX Researcher, Engineering Manager
What:
✅ Understand the user problem we are trying to solve.
✅ Identify business goals and key metrics to determine success.
✅ Generate hypotheses and research/experiment/user-test.
✅ Define MVC and potential future iterations.
✅ Minimize risks to value, usability, feasibility, and business viability with qualitative and quantitative analysis.
Outcome: We have confidence that a proposed solution will positively impact one or more Product KPIs. There may be reason for exceptions, so the team would need to be clear in that case, and be able to justify that it’s still important without mapping back to our KPIs.
If we don’t have confidence in the MVC or what success looks like, we should continue validation cycles before we move to the Build track.
Validation phase 1: Validation backlog
Label: workflow::validation backlog
Key Participants
| Role | Function |
|---|---|
| DRI | Product Manager |
| Collaborators | Product Designer Engineering Manager |
| Informed | Customers Technical Account Manager Product Marketing Manager Other stakeholders as appropriate |
Description
The growth of a world class product is built from a well maintained backlog. Product Managers are responsible for refining a group’s backlog to ensure validation opportunities are scoped and prioritized in line with category direction, stage, and/or section level strategy. The backlog is also the single source of truth for stakeholders to understand and engage with your group. An issue position in the backlog, along with the description, discussion, and metadata on those issues are key pieces of data necessary to keep stakeholders up to date.
Outcomes and Activities
| Outcomes | Activities | DRI |
|---|---|---|
| Up to date issues and epics: At Bramble, issues are the single source of truth for any change to the product. Keeping these up to date increases efficiency and transparency by allowing all team members to understand the planned work. | - Create issues in response to a sensing mechanism. Consider using the Problem Validation issue template for new features. - Review issue discussions and update relevant info in the description. - Keep metadata (such as labels) up-to-date. - Actively respond to stakeholder comments. - Transfer discussion notes, and external information to the issue (as links or discussion/description details). |
Product Manager |
| Prioritized backlog: The issue and epic backlog is the primary signal stakeholders use to know what’s “up next” for a group. The backlog is also the queue for a group to work from, as features progress through the Product Development Flow phases. This queue is kept up to date with milestones and rank ordering on issue boards. | - Regular review of issue prioritization (such as issue board ordering and milestone assignment). - Align prioritized backlog to category direction and category maturity state. - Consider using the RICE formula to help make prioritization tradeoffs. |
Product Manager |
Validation phase 2: Problem validation
Label: workflow::problem validation
Key Participants
| Role | Function |
|---|---|
| DRI | Product Manager |
| Collaborators | UX Researcher |
| Informed | Product Designer Engineering team Other stakeholders as appropriate |
Description
To ensure the right solutions are delivered, the team must start their work with a validated problem. This can take many forms and be achieved through Product Manager and UX Researcher collaboration.
If the problem is small and well-understood, it may be possible to quickly move through this phase by documenting the known data about the user problem. Some examples of known data include User Requested Issues or pre-existing Actionable Insights from prior research.
If the problem is nuanced or not yet well understood, then it will likely take longer to validate with users properly. This phase’s primary outcome is a clear understanding of the problem, along with a simple and clear way to communicate the problem to various stakeholders. Although optional, it is recommended to use an Opportunity Canvas as a tool that helps individuals better understand a problem, and communicate it to various stakeholders. An Opportunity Canvas can also be used to recommend creation of a new category including asking for new resourcing.
Outcomes and Activities
| Outcomes | Activities | DRI |
|---|---|---|
| Thorough understanding of the problem: The team understands the problem, who it affects, when and why, and how solving the problem maps to business needs and product strategy. | - Create new issue using the Problem Validation Template. - Complete an Opportunity Canvas. - Schedule a review of the opportunity canvas for feedback. - Open a Problem Validation Research issue and work with UX Researcher to execute the research study. - Validate your problem with users using any of the proposed methods. |
Product Manager |
| Update issue/epic description: A well understood and clearly articulated customer problem is added to the issue, and will lead to successful and efficient design and development phases. | - Ensure your issue is up-to-date with the latest understanding of the problem. - Understand and document (in the issue) the goals that people want to accomplish using the Jobs to be Done (JTBD) framework. - Leverage your opportunity canvas to communicate the problem to your stable counterparts and group stakeholders. Consider scheduling a review to gather feedback and communicate the findings to Product and UX leadership. |
Product Manager |
Validation phase 3: Design
Labels: workflow::design
Key Participants
| Role | Function |
|---|---|
| DRI | Product Designer |
| Collaborators | Product Manager Engineering team UX Researcher QA |
| Informed | Application Security Engineer Other stakeholders as appropriate |
Description
After understanding and validating the problem, we can begin or continue to ideate potential solutions through a diverge/converge process. However, if the outcome from the problem validation phase confidently suggests an incremental modification to the existing solution, the aforementioned diverge/converge process could be skipped.
The Product Designer leads the team (Product Manager, Engineering team, UX Researcher and QA, as needed, depending on the item) in ideating potential solutions and exploring different approaches (diverge) before converging on a single solution. Product Managers and the Engineering team evaluate solutions by determining if they meet customer and business goals, and are technically feasible. The team is encouraged to engage with stakeholders to determine potential flaws, missed use cases, potential security risks, and if the solution has the intended customer impact. After the team converges on the proposed solution or identifies a small set of options to validate, the issue moves into the Solution Validation phase.
To start the Design phase, the Product Designer or Product Manager applies the workflow::design label to an existing issue or, if needed, creates a new issue with this label.
Outcomes and Activities
| Outcomes | Activities | DRI |
|---|---|---|
| Proposed solution(s) identified and documented: The Product Designer works with the Product Manager and Engineering team to explore solutions and identifies the approach(es) that strike the best balance of user experience, customer value, business value, and development cost. | Diverge: explore multiple different approaches as a team. Example activities: - Think Big session. Internal interviews. - Creating user flows or journey maps. Converge: identify a small set of options to validate. Example activities: - Think Small session with the team. - Design reviews with team - Low fidelity design ideas. - Update issue/epic description with proposed solution. Add Figma design file link or attach design to Bramble’s Design Management to communicate the solution idea. Read to understand what tool to use. - Validate approach with help from stakeholders. Run user validation using any of the proposed methods and appropriate Gitlab issue. - Draw inspiration from competitive and adjacent offerings. |
Product Designer |
| Shared understanding in the team of the proposed solution: The Product Designer leads the broader team through a review of the proposed solution(s). | - Review the proposed solution as a team so that everyone has a chance to contribute, ask questions, raise concerns, and suggest alternatives. - Review the proposed solution with leadership. |
Product Designer |
| Confidence in the technical feasibility: It’s important that Engineering understands the technical feasibility of the solution(s) to avoid rework or significant changes when we start the build phase. | - Discuss the technical implications with Engineering to ensure that what is being proposed is possible within the desired timeframe. When sharing design work, use both Figma’s collaboration tools and Bramble’s design management features. Read to understand what tool to use. - Engage engineering peers early and often through Slack messages, pins on issues or by scheduling sessions to discuss the proposal. |
Product Designer |
| Updated issues/epic descriptions: The Product Manager and Product Designer ensure issues and epics are up-to-date. | - Ensure issues and epics are up-to-date, so we can continue our work efficiently and asynchronously. - Experiment definition. |
Product Manager |
Build track
The build track is where we plan, develop, and deliver value to our users by building MVCs, fixing defects, patching security vulnerabilities, enhancing user experience, and improving performance. DRIs across engineering disciplines involving Design, Dev and QA work closely together to implement MVCs while in close collaboration with the Product Manager. Decisions are made quickly if challenges arise.
Build Goals & Outcomes
When: As we build MVCs according to our product development timeline
Who: Product Manager, Product Designer, Engineering team, QA team
What:
✅ Release to a subset or full set of customers as appropriate.
✅ Assess UX, functional, technical performance, and customer impact.
✅ Collect data to measure MVC against success metrics to inform the next iteration.
✅ Iterate until success metrics are achieved and the product experience is optimal.
Outcome: Deliver performant MVCs that improve one or more of our Product KPIs and/or Engineering KPIs. If it fails to do so, honor our Efficiency value (that includes a low level of shame), abandon it, and restart the validation cycle to identify the right solution.
Build phase 1: Plan
Required Labels
| Label | Usage |
|---|---|
workflow::ready for development |
Issue has been broken down and prioritized by PM for development. Issue also has a milestone assigned at this point. |
Key Participants
| Role | Function |
|---|---|
| DRI | Product Manager |
| Collaborators | CTO Product Designer QA Engineering team |
| Informed | Marketing |
Description
This phase prepares features so they are ready to be built by engineering. Bugs, technical debt, and other similar changes that are not features may enter the process in this phase (or may benefit from entering in earlier phases based on the cost of doing the work requiring the full problem to be validated to ensure it makes sense to do the work).
Outcomes and Activities
| Outcomes | Activities | DRI |
|---|---|---|
| Well-scoped MVC issues - Issues are the SSOT for all feature development. | - Refine issues into something that can be delivered within a single milestone - Open follow on issues to track work that is de-prioritized - Promote existing issues to Epics and open implementation issues for the upcoming milestone - Review feature issues with contributors - Consider scheduling a POC or engineering investigation issue - Make scope tradeoffs to reach for a right-sized MVC - Request an issue review to ensure communication is clear and have proposed the right iteration plan to execute on the solution. |
- Product Manager |
| Prioritized Milestone - The team should understand what issues should be delivered during the next milestone | - Product Manager sets workflow::ready for development and a milestone signaling intent to prioritize - Engineering Manager applies Deliverable label signaling acceptance of issue in the next milestone - Product Manager creates a planning issue |
- Product Manager and Engineering Manager |
| Implementation Issue Refinement - Some teams have found it useful to treat issue refinement as a separate, iterative task from planning breakdown. This separation allows them to focus backlog refinement on the aspects of the original feature that will be delivered first. | - Further refine implementation issues identified in the workflow::planning breakdown step by additionally applying workflow::refinement. |
- Engineering Manager |
Build phase 2: Develop & Test
Required Labels
| Labels | Usage |
|---|---|
workflow::in dev |
Applied by the engineer after work (including documentation) has begun on the issue. An MR is typically linked to the issue at this point. |
workflow::in review |
Applied by an engineer indicating that all MRs required to close an issue are in review. |
workflow::blocked |
Applied if at any time during development the issue is blocked. For example: technical issue, open question to PM or PD, cross-group dependency. |
workflow::verification |
After the MRs in the issue have been merged, this label is applied signaling the issue needs to be verified in staging or production. |
workflow::feature-flagged |
Applied while the issue is released/rolled-out to production users. |
Key Participants
| Role | Function |
|---|---|
| DRI | Assigned engineer |
| Collaborators | Product Manager Software Engineer in Test Product Designer Application Security Engineer |
| Informed | Product Marketing Engineering Manager Cross-stage PM Sales Customer Support |
Description
The develop and test phase is where we build the features, address bugs or technical debt and test the solutions before launching them. The PM is directly responsible for prioritizing what should be worked on; however, the engineering manager and software engineers are responsible for the implementation of the feature using the engineering workflow. Engineering owns the definition of done and issues are not moved into the next phase until those requirements are met. Keep in mind that many team members are likely to contribute to a single issue and collaboration is key.
This phase begins after work has been broken down, and prioritized in Phase 1. Work is completed in priority order as set at the beginning of the milestone. The Engineering Manager will assign an issue to an engineer who is responsible for building the feature. An engineer can also self-serve and pick up the next priority order issue from the workflow::ready for development queue on their team’s board. That engineer will update its workflow:: label to indicate where it’s position in the development process.
When an issue is in workflow::in review, the Application Security Engineer would help validate the risk mitigations through the non-blocking application security review process.
Documentation for the work will be developed by the engineer. Items discovered during a documentation review should not block issues moving into the next phase. This may drive the creation of follow-on improvement MRs for the documentation, after release.
Note: Work deemed out-of-scope or incomplete by engineering is taken back into the plan phase for refinement and rescheduling for completion.
Outcomes and Activities
| Outcomes | Activities | DRI |
|---|---|---|
| Feature is built | - Engineering manager checks that definition of done is met - Provide regular status updates to stakeholders - Provide asynchronous updates to avoid status check-ins and synchronous stand-ups - Engineers follow the engineering process to implement assigned issues. |
Engineer |
| Feature is tested | - Engineers test features they implement (see Definition of done). - Application Security Engineer validates the risk mitigations through the non-blocking application security review process. |
Engineer |
Build phase 3: Launch
Issue Status: Closed
Key Participants
| Role | Function |
|---|---|
| DRI | Development: Close issue after it’s available in production, and feature flags are removed. Product Manager: Initiate release post item creation if they decide it’s warranted. Product Manager: Consider alerting relevant stakeholders in appropriate Slack channels. |
| Collaborators | Development team, Quality counterpart, and Product Manager may verify the feature is working as expected in production. (Primary verification is, of course, performed prior to production whenever possible.) |
| Informed | Stakeholders for the change (including customers, open-source users, and Bramble team members) will be informed about the feature by the change in the status of the issue or the release post. Bramble team members may also be informed by posts in relevant Slack channels. |
Description
When the change becomes available in production, the issue is closed by the development team so stakeholders know work on it has been completed. Afterward, the Product Manager coordinates the release post and dogfooding when they apply.
Outcomes and Activities
| Outcomes | Activities | DRI |
|---|---|---|
| Feature is available to Brmbl.io customers: After it’s deployed to production (and any feature-flags for it are enabled), the feature is launched and available to Brmbl.io hosted customers. | - Code is deployed to production. - Feature flag(s) enabled. |
Development |
| Stakeholders of a feature will know it’s available in production | - After the feature is deployed to production and any needed verification in production is completed, the development team will close the issue. - Prior to the issue being closed, the development team may set the workflow label to workflow::verification or workflow::production for tracking purposes. - Product Manager may follow up with individual stakeholders to let them know the feature is available. |
Development |
| Customers will be informed about major changes: When appropriate for a change, a release post item will be written and merged by the Product Manager. | - Product Manager will provide the release post to the Customer Success team, who will then meet with their client contacts to formulate their respective communication plan. | Product Manager |
| Experiment results and follow-up issue is created | For experiments, create a follow-up issue that will be where results of the test and next-steps are tracked. | Product Manager |
Build phase 4: Improve
Label: n/a
Key Participants
| Role | Function |
|---|---|
| DRI | Product Manager |
| Collaborators | Product Designer Customer Success Sales Data Analysts UX Researcher Product Management Marketer |
| Informed | Engineering team Leadership Other stakeholders as appropriate |
Description
After launch, the Product Manager and Product Designer should pay close attention to product usage data. This starts by ensuring your AMAU is instrumented and reporting as you expect. From there consider how the feature has impacted GMAU and SMAU. At this point you should also solicit customer feedback to guide follow-on iterative improvements, until success metrics are achieved/exceeded and a decision can be made that the product experience is sufficient. To create a combined and ongoing quantitative and qualitative feedback loop, consideration of the outcomes and potential activities below are recommended.
Outcomes and Activities
| Outcomes | Activities | DRI |
|---|---|---|
| Understand Qualitative Feedback: To know how to improve something, it’s important to understand the qualitative feedback that we’re hearing from users and team members. | - Create a dedicated feedback issue (optional). - Review user feedback in issues. - Follow up with TAMs and SALs to gather feedback from interested customers. - Set up follow-up calls with customers to gather more specific feedback. - Consider running a survey for usability. |
Product Manager |
| Measure Quantitative Impact: Qualitative data is great, but coupling it with quantitative data can help to paint the full picture of what is going on. Set up dashboards and review the performance and engagement of your change. | - Update any applicable dashboards, if necessary work with the data team for more complex reporting. - Review AMAU, GMAU, and SMAU to understand if the new feature or improvement has impacted core metrics. |
Product Manager |
| Take action on Learnings: After you understand the qualitative and quantitative impact, you can take action on your learnings by creating new issues or updating existing open issues with more information. | - Open new issues or revise existing open issues for follow-on iterations and improvements. - Ensure you’ve captured feedback in issues or as updates to your direction pages. - If applicable, update your category maturity score and timeline. - Share learnings with your group and stage. - Consider sharing learnings with the broader team. - Coordinate with your PMM to understand if there are any relevant GTM motions you should consider updating. - Update experiment follow-up issue with results and specific next steps. - Potentially create issues or MRs for updates to the documentation site, to provide useful information in advance of potential product updates related to learnings. |
Product Manager |
Editing this page
All merge requests to this page require informing Product Manager prior to merging. To make updates such as grammatical fixes and typos, you can create an MR and tag the PM for reference, and then merge. There’s no need to wait for feedback on these types of updates prior to merging.
For updates that affect the overall phases by modifying core definitions, workflow labels or other cross-functionally utilized processes, you can create an issue or MR, add the current milestone and label product develpment flow, and assign it to the PM for review, collaboration and iteration.
The PM will ensure the MR gets included in product develoment flow release updates as well as ensuring alignment happens with stakeholders if needed.