It’s great when you can create a new product from scratch, it’s a different story when you inherit an old and complex system. Especially when the whole development team is new and they don’t know much about the product yet.
Before deciding what should go on the roadmap, we spent some time getting to know our users (including creating personas), speaking to their managers and other stakeholders and analysing recent support issues. We concluded as follow:
- There are thousands of new users, who struggle with the system.
- There are thousands of experienced users, who got used to it and don’t want any changes.
- Stakeholders have been asking for new features for last few years.
- Promises were made to the users and not delivered.
- Legacy code and technical debt are rather scary.
- There are a lot of support issues.
- There is a lot to learn about how the system works (and no manual).
How did we tackle this?
We started from inviting our stakeholders to the meetings. Their input is critical for a successful and realistic roadmap.
Roadmapping part 1
Before the meeting we printed out all screenshots from the current system. We were all surprised how many there were (50+ screenshots!). Surely, the home delivery process can’t be that complicated? No wonder new users feel lost.
Everyone got a few post-it notes to write down what are the top 3 problems our users are facing. Some people wrote more than 3, so we asked them to prioritise and stick to the top problems only (that wasn’t that easy for some!). We ended up with 4 categories of problems. That’s a good start for legacy product roadmap!
We have identified 4 stages and 1 ‘other’ stage of home delivery process. Then we briefly discussed which stage would be most important to optimise and why. For example – improving an activity that happens 100 times a day is usually more beneficial than improving an activity that only happens once a day.
The task here was to assign all the printed screenshots to their stages. That sparked some good conversations and was definitely a good learning exercise.
When was the last time when you killed a feature? The usual pattern is that we keep adding new features to the product, but don’t spend any time on rethinking existing ones. I asked the team what our users do not need from the system any more (surprisingly there was a lot!). It was good to have our stakeholders at this point. They could explain the historical reasons for adding these features to the system and in most cases they agreed, that these are not needed any more.
The next task was to categorise remaining screenshots into two new sections: ‘Ain’t broken, don’t fix it’ and ‘Fix it!’. Here, we had to admit, even though the system is old, some parts of it are still pretty good and don’t need any attention.
That was a lot for one meeting. We decided to come back to it the next day. In the meantime people could have a closer look on their own at issues discussed in this meeting.
Roadmapping part 2
We started fresh – ‘Ain’t broken don’t fix it’ screenshots have been removed from the board.
This time we were going to focus on business value and development effort needed for each of the features from ‘Fix it!’ and ‘Kill it!’ categories
We used post-it notes and T-shirt sizes (S/M/L) to estimate work required and business value.
The task was to assign stickers to the screenshots. This triggered a good discussion between the stakeholders and the team. We do have different perspectives after all…
The next task was to group features depending on how beneficial they would be and prioritise the groups. The best feature would be small development effort (yellow S) and large business value (pink L). Features not worth considering any time soon would be large development effort (yellow L) and small business value (pink S).
At this point we reviewed the P1 feature group – are they going to solve the biggest problems for our users?
P2, P3, P4… groups are now parked. They will be reviewed again when we are done with P1 group. At this time we will know the system better.
One thing to note is, that this is a product roadmap tackling user perspective only. There is more to do of course – sorting out technical debt is a great example.
Our stakeholders played a big part in this meeting – we could go in a totally wrong direction without them. They are also very happy to celebrate with us by taking all of us out for lunch and drinks, when the top 5 features are delivered!