Role reversal

We started our research from shadowing users. All team members spent a whole day working with the people who are using our product – internal users – delivery drivers. It wasn’t training, we were actually helping the drivers deliver shopping to real customers.

We learnt a lot that day – about the users themselves, about the delivery process and how it is really handled by the system we provide, and a bit about the customers. We felt like experts for a while, even though it was very limited qualitative research.

We decided to put it into test however and invited an experienced user to a workshop with us. Our first task was to… reverse our roles (kind of).

So, this is your job:

We asked Mike-the-user to pretend that it’s his first day at this job, even though he’d spent the last 10 years doing it. All he was supposed to know is that the role involves delivering goods to customers.

Next, we asked the dev team to pretend they are his line managers and they need to explain the job to him – step by step. Mike was a curious student, so he was allowed as many detailed questions as possible.

It started well, but very soon we got corrected: nope, it’s not how it works…

We were missing details, got some procedures mixed up and couldn’t answer some of the questions, even about our own system! We also discovered how our system can be misleading if things go wrong.

We are not on the same page

giphy -shaking head

We now know that even by shadowing users, we can still misunderstand things. Especially if things go well during the day – we can’t see the whole range of issues our users face. Also, we are more likely to believe that problems that occurred during our experience are happening more often, when in fact, they might be statistically rare.

So we are not on the same page. And we will never be. But that’s ok – we are very different people and have different skill sets – that’s why we have different jobs. What we should do is to work towards minimising this gap by educating ourselves about the users, and also educating our users about our job when possible.

Key benefits

  • The meeting is more engaging for everyone.
  • We actively think about the process (as opposed to passively listening about their job).
  • Misunderstandings are spotted quickly.
  • We build a relationship with users.

Try it yourself – explain to your users what their job is. You will discover a lot of surprises.




Stand-up format

We used to follow the the daily scrum ‘recipe’, so every team member was answering the standard 3 questions:

  1. What did you do yesterday?
  2. What will you do today?
  3. Any blockers?

It worked well to some degree – we basically confirmed that everyone was busy. It wasn’t always clear how much we progressed with the actual work – sprint stories.

New format

We have changed the format to go story by story (as opposed to person by person). The questions are now addressed to the whole team:

  1. What did the team do yesterday for this story?
  2. What will the team do today for this story?
  3. Any blockers for this story?

Key benefits

  • Stand-ups are shorter.
  • There is more focus, as only things relevant to stories are mentioned.
  • It’s easier to spot neglected stories.
  • It’s easier to spot people busy with other work, as they do not add anything to this conversation.

We know that everyone is busy. There is no need to mention every meeting at stand-up time. It’s better to focus on the actual contributions.

Legacy product roadmap

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.

(Some) Screenshots


Task #1

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!

Task #2

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.

Roadmapping - legacy-01

Task #3

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.

Roadmapping - legacy-02

Killing features…

Task #4

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.

Roadmapping - legacy-03

Leave it, fix it or kill it!

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

Ready for part 2!

Task #1

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…

business value
S/L/M stickers

Roadmapping - legacy-04

Estimation in progress

Task #2

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).

Roadmapping - legacy-05

All estimated, grouped and prioritised!

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!



Great slides checklist

Great slides are not rocket science. There is a good selection of tools out there to help deliver an awesome slide pack and there are many great presentation examples and books available online for inspiration.

Selection of tools

To name but a few: Google Slides, Prezi, PowerPoint. And there are many more out there.

google-slides     prezi_horizontal     powerpoint-mac-logo

Google Slides will keep it simple and easy to share. Great for collaboration. Simple, yet powerful.

Prezi will wow your audience by slide transitions. Only basic slide formatting is allowed, so it’s impossible to mess up with the final effect.

PowerPoint – will do a lot more complex stuff, but it’s more difficult to share and formatting might be lost when displayed on different machine. It offers great help for the speaker while presenting.

Whichever you chose – just keep the slides simple (K.I.S.S.)!


Inspiration and great tips

Just a few great examples found online:

Even more great examples

Check out Damon Nofar’s portfolio and explore SlideShare website.


My slides checklist

Before I create a single slide, I am asking myself:

  • Who is the target audience? What they do and don’t know about the subject matter?
  • What exactly is the message I want to convey?
  • Technical details: is my presentation going to be displayed on a big screen or on a wall through a projector? What is recommended screen format – 16:9 or 4:3? What is going to be the source of my presentation (my laptop?) and how much control will I have over it (just a clicker?)?
  • Knowing all this – what is the best tool to use?

When my slides are ready, I go through this checklist:

  1. Is there only 1 message per slide?
  2. Can I cut down any more text?
  3. Is font type/size/colour/line space consistent on every slide?
  4. Will this font type be available on a random computer?
  5. Am I consistent with punctuation? (dots, colons, spaces etc.)
  6. How many colours are in use – do I stick to a palette of 3 or 4 main colours?
  7. Is the contrast good enough for a projector?
  8. Are elements sized and positioned consistently on each slide (no jumping)?
  9. Can I replace the charts with infographics?
  10. Are images high quality and do they match the style and colours on other slides?
  11. Are the animations or slide transitions really necessary?
  12. Is the order of slides following my speech?
  13. Am I sure I can talk through the presentation in planned time and still have some time for questions? (It always take longer to present in real life).

Once I am happy it’s time for a demo run. Ideally in front of a demo audience, which is a great opportunity for collecting some feedback. Sometimes presenting to a mirror will have to do.