Roadmap process management

Assisted the CTO by taking on some Product Ownership tasks. Wrote, proposed and executed processes for managing R&D team roadmap and backlog with a customer-driven approach:

Data gathering via stakeholder workshops

• I planned, prepped and organized workshops with internal Product users (eg. developers, marketeers and project owners using our DXP) and people in direct contact with our customers (eg. Sales people, marketeers, …). The goal was to know the issues and features that were seen/experienced as most important but also why. This would enable the R&D team to propose a focussed, meaningful scope for the roadmap, to management. I chose to start with internal users and stakeholders, to quickly build up momentum. External users and clients were designated to a later phase.
• I built the workshops around information gathered from participants beforehand (survey), including input from product leads / R&D team lead. In each workshop, we created teams of 2 (mixed profiles) and asked them to rank their items on a 2-axis board. There was also a round for open suggestions as well as time for discussion.
• I processed and visualised the feedback, introducing scoring based on criteria such as repetition, use cases, projected usage, … as well as grading on difficulty.
• I followed up with our head of R&D where we used the info to set goals and focus points for the roadmap he could bring to the product board. The various stakeholders were sent summaries, an overview of our conclusions and how these were used for follow-up.

Roadmap management

As products evolve and a team grows, so does the backlog and technical debt. Especially when switching to a new ticket management system. Our team needed to achieve 3 things in order to get a handle on the issue queue and move forward:

• Better understand what the issues, change and feature requests we already had in our queue
• Track new input in a way that got people a faster response and was easier for the team to categorize
• Filter and prioritize

Backlog and Sprint planning

I approached our input and backlog queue in several phases to achieve this:

• Process for adding tickets and maintaining backlog: this included guidelines for labels, categories, descriptions, etc…, but also documenting the process for submitting and creating new tickets in the first place. When switching to Jira for ticket management & service desk, this informed various flows and automations.
• Cleanup of the backlog, to implement said system: recategorized tickets, adding context, tracing back issues and collecting information from the original reviewers, …
• Set-up of boards and workflows in Jira: getting Kanban boards, ticket status flows and documentation ready when we switched over.
• Categorized the Roadmap with high-level goals that were informed by user value.
• In the team, we tested out a combination of planned and asynchronous sessions, to score tickets, create milestones, estimate work… to better inform planning and get a handle on the Roadmap.
• Dashboard: before switching to Jira, I create filtered overviews using the system’s API’s, to be able to review type of product, type of work, maintenance vs. user input, … This informed much of what we later tried to achieve in Jira.