In order to define and streamline the company’s product development process, we (myself and 1 other product designer) initiated and facilitated a cross-functional workshop series to allow representatives from each part of the business to collaborate on a process that meets each department’s needs.
Goals
- Define a cross-functional product development process for RTR
- Define stakeholders’ roles and responsibilities in the product development process
- Roll out and continue to iterate and improve upon this resulting process
Background
- A group of representatives from each function (Commercial, Product Management, Product Design, Engineering, Verification, Validation) met bi-weekly to improve product development processes.
- The group first identified inputs needed from each function, outputs generated by each function, as well as any handoffs between functions.
- The group then combined best practices with current practices to create a holistic process for turning a requested feature into a released feature.
- Tools used in this effort include: Miro, Jira, Confluence, Google Slides
Scope
- Generate a Standard Operating Procedure (SOP) for each function contributing to product development.
- Implement the SOPs in Jira by standardizing issue types, transitions, and statuses.
- Identify where automation could be used to make Jira implementation easier and more sustainable.
Workshop 1: Identifying Inputs, Outputs and Stakeholders
In the first workshop of the series, we focused on identifying all of the inputs each function requires and the outputs each function generates as part of developing product features. Each function’s representative added items to the miro board to represent the inputs/outputs their function typically worked with.
Workshop 2: Function Process Mapping
The second workshop of this series focused on allowing each function’s representative(s) to have a breakout session to create a flowchart to capture how their function typically interacts with the previously identified inputs and outputs. At this point of the process, the focus was more on just getting each representative’s thoughts down and less on a consistent format.
The result was a somewhat varied set of flowcharts:
Using these flowcharts, we drilled down into each function’s needs. For example, we identified that in order to create a test plan (the first step in Verification’s process), the verification team needed the following inputs from other functions:
- System Requirement
- Business Requirement
- Product Requirement
- Engineering Design Doc
- System Architecture
- Release Definition
Workshop 2 follow-up: Clean Up Function Process Maps
Now that we had rough maps of each function’s individual processes, it was time to spend some time cleaning up the formatting of these flows. In collaboration with the other product designer who I was leading these workshops with, we divided and conquered applying consistent wording, coloring, shapes, and connections to each function’s flows.
Workshop 3: Connecting the Cross-functional Flows
Now that the flows all had fairly consistent formatting, we reconvened the group of representatives in a 3rd workshop to identify where there were connections between different functions’ process flows.
The way we did this was by having representatives draw connections between inputs and/or outputs shared between their function and other functions.
For example: At RTR, Stories are an output typically generated by Product Management. Stories are also an input typically used by Product Design, Engineering, Verification, and Validation. In some cases, Product Design may make updates to the Story as well based on new information discovered during requirement identification.
Admittedly, the result of this workshop was a bit…. confusing:
Workshop 3 Follow-up: Clean up Flowchart Spaghetti
To try and make sense of the somewhat chaotic results of Workshop #3, I then took a step back to identify where I could make improvements to the formatting to increase readability and comprehension.
I started out by creating rough swim lanes for each function, and then positioning each function’s chart in an order that made more sense from a timeline perspective. Since validation couldn’t validate the implemented feature start until after engineering had actually completed implementing it, it made sense to place validation closer to the bottom right of this mega-flowchart.
Also, to help bring some more order to the chaos, I opted to replace the majority of curved connectors with straight ones. This allowed me to better space them out and make the whole thing look less like a pasta dish.
Then, in collaboration with the other product designer leading this effort, we continued to iterate upon the mega-flowchart by:
- Identifying which items could be combined or removed altogether
- Continuing to improve formatting, positioning, and alignment
- Using Miro’s Link functionality to reduce the amount of connector lines on the board while still preserving the ability to connect inputs from one function with the outputs of another.
Continuing to collaborate with the other product designer leading this effort, we chose to use Miro’s linking functionality in lieu of all of connectors between swim lanes and visually condensed the chart to make it cleaner and more understandable at a glance:
Workshop 4: Create Standard Operating Procedures (SOPs) for Each Function
Now that the Product Development Process committee has agreed upon a cross-functional workflow (and reviewed it with relevant stakeholders such as the Executives), it was time to divide back up into breakout groups to create SOPs for each function.
Each function representative group received a pre-formatted confluence page that they were to populate with their SOP’s info. These template pages included things like Step Number, Description, Owner/Reviewer/Approver, etc.
Here is an example of one of the resulting SOPs that was completed:
Result
Once the SOPs were created and approved, each department’s manager rolled them out among their team in a coordinated effort to make sure no department was left out or fell behind.
In order to avoid trapping ourselves in too rigid of a process, a core facet of implementing this process was that each function had the ability to identify when certain steps within their function’s SOP may be skipped or altered (on a case-by-case basis)… basically “Learn the rules before you break them.”
These SOPs have since proven invaluable both in aligning the company with what is expected of whom at different parts of the product development process, provided clarity with how to effectively use Jira and Confluence across functions, and have become a crucial resource for new hires to refer to during onboarding.
Additionally, these SOPs have been helpful in providing a jumping off point for employees moving between different departments as can be common in startups. In situations where a Customer Success employee may move into a Product Owner role, this gives them some structure right out of the gate for what to expect.