Revise project management roles and planning processes #4435
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Updated project management documentation to clarify roles and responsibilities, including the addition of the Design Engineer role and adjustments to the RACI framework. Revised planning processes and meeting schedules for improved clarity.
✅ Deploy Preview for flowforge-website ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
dimitrieh
requested changes
Jan 26, 2026
Contributor
dimitrieh
left a comment
dimitrieh
left a comment
There was a problem hiding this comment.
@allthedoll left a few comments! :)
| - **Product** is responsible for defining product strategy, setting priorities, and shaping the roadmap to achieve desired outcomes. | ||
| - The **CTO** determines technical feasibility, architectural direction, and long-term technical strategy. | ||
| - The **Engineering Manager** plans execution, assigns work, and is accountable for delivery. | ||
| - The **Design Engineer, Discovery & Initiatives** (referred to as **Design Engineer** below) operates upstream, partnering closely with Product to explore problem spaces, shape solutions, and reduce uncertainty through design and technical discovery. |
Contributor
There was a problem hiding this comment.
Suggested change
| - The **Design Engineer, Discovery & Initiatives** (referred to as **Design Engineer** below) operates upstream, partnering closely with Product to explore problem spaces, shape solutions, and reduce uncertainty through design and technical discovery. | |
| - The **Design Engineer, Discovery & Initiatives** (referred to as **Design Engineer** below) operates upstream, partnering closely with Product to explore product lanes, define problem spaces, shape solutions, and reduce uncertainty through research, design, and technical discovery. |
| In order to ensure that releases are able to deliver work according to the priorities laid out by the Product and Engineering teams, the four Product Planning meetings scheduled each release are organized as follows, with Week 1 being the first meeting that occurs just after a release has shipped. | ||
|
|
||
| Week 1: The team discusses ongoing work and opportunities for future development. | ||
| - **Problem discovery, solution shaping, and early design** |
Contributor
There was a problem hiding this comment.
Suggested change
| - **Problem discovery, solution shaping, and early design** | |
| - **Product lane exploration, problem discovery, solution shaping, and early design** |
|
|
||
| Beneath the areas, we then utilize the standard GitHub hierarchy of Epics, Stories, and Tasks. As such, the hierarchy is as follows: | ||
| - **Product** defines outcomes, prioritizes initiatives, and provides direction based on customer and business needs. | ||
| - The **Design Engineer** partners with Product to explore ideas, validate approaches, prototype solutions, and provide early technical and design context. |
Contributor
There was a problem hiding this comment.
Suggested change
| - The **Design Engineer** partners with Product to explore ideas, validate approaches, prototype solutions, and provide early technical and design context. | |
| - The **Design Engineer** partners with Product to explore product lanes, strategic ideas, validate approaches, prototype solutions, and provide early technical and design context. |
| ## Hierarchy | ||
|
|
||
| This process covers the standard planning and prioritization process; bugs or minimal improvements are not part of this description. It is important to stay flexible, so this fast-lane approach for the described issues is possible and necessary. | ||
| As defined in our [Product Strategy](../product/strategy.md), FlowFuse is organized into three pillars: |
Contributor
There was a problem hiding this comment.
I wonder if this needs updating...
Ideally, we do not limit our value proposition artificially to the potential boundaries of this initial structure.
This feels very much like defining the engine, while the real value is what is created after deployment, thus the vision should be more holistic.
FlowFuse with Node-RED is used for three things:
- Data ingestion/transfer/conversion
- Data storage (very limited right now)
- Data visualisation
I think we can even go beyond these with:
- Issue management - Something I've spoken with Drew about.
- Issue resolvement - AI opportunities here by offering tools to dynamically/autonomously act based on alerts/values
I think in the end the questions come down to, what do we want FlowFuse to be? Who are our target users? How are we catering to them and can we cater to them better/more?
I do think this is out of scope for this PR though 🙃.
cc: @lbeau
|
|
||
| #### Step 2 - Assignment to the To-Do section | ||
| Once an issue is refined, the PM continuously assigns issues to the [Development Board's](#development-board) `To-Do` Section. This is the first indication that this particular item is planned and will be the one of the next items for the `Up Next` section. It also signals the engineering and UX team to raise any open design or architectural clarifications if required. | ||
| - **Pillar** – One of the three product pillars |
Contributor
There was a problem hiding this comment.
I think we need "Product lanes" in here still, which are a different abstraction/organisation layer VS product areas, as they are more closely tied to currently relevant strategy.
| ##### Mark In Progress | ||
|
|
||
| - **Feature Requests**: suggestions or ideas submitted by users or stakeholders for new functionalities, enhancements, or improvements to the existing software or system. Feature requests should be evaluated, prioritized, and potentially incorporated into the product roadmap, often being transformed into Epics or Stories for implementation in future releases. | ||
| When starting work, engineers must move the **task** to `In Progress` and record the Started date. This signals ownership and enables progress tracking. |
Contributor
There was a problem hiding this comment.
Started data will be auto recorded by sprint assignment?
| ## Issues | ||
|
|
||
| We provide the ["Headlines" view](https://github.com/orgs/FlowFuse/projects/1/views/39) on our GitHub project boards to track these items on a release-by-release basis so that the customer team has a clearer view on what new content can be discussed in socials, etc. | ||
| Issues are the core planning unit. |
Contributor
There was a problem hiding this comment.
Agreed here. We can define here additionally, that we make use of hierarchy with parent/child relationships in issues. This way we can tie planning issues all the way to eng issues to task issues.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Updated project management documentation to clarify roles and responsibilities, including the addition of the Design Engineer role and adjustments to the RACI framework. Revised planning processes and meeting schedules for improved clarity.
Related Issue(s)
N/A
Checklist