I might have titled this post, “5 things our new Product team has learnt and is still trying to improve” but sometimes it’s good to reflect on the progress we have made and make peace with our iterative improvement process. Here’s an overview of the 5 lessons:

  1. Don’t confuse your Product Backlog with your Product Roadmap
  2. Get to know your customers
  3. Manage expectations continuously
  4. Don’t keep the development team in the dark
  5. Make time for strategic activities

What follows is an insight into the knowledge I’ve gained through my experience of product development at Mobenzi. 

1. Don’t confuse your Product Backlog with your Product Roadmap

Sometimes it feels as if requirements and new enhancement requests are coming from every direction, faster than we can prioritise them, nevermind develop them. Some are little tweaks and some are “epics”, and while our prioritised Product Backlog can show at a glance how far along a feature-set is in the pipeline, or what items are candidates for the next sprint, there’s little sense of timing – and how do we decide what takes priority anyway?

This is where our Product Roadmap comes into play. Our roadmap is not a task board, but a timeline that tells us what the vision is for the product over the coming months. Only “epic” features are included on our roadmap and each needs a simple business case to justify its place: Does a feature contribute to the company/product/team’s strategic goals? What is the expected customer value? What will the cost of implementation and operational support be? 

Our roadmap is not a task board, but a timeline that tells us what the vision is for the product over the coming months.

The majority of every sprint is dedicated to the roadmap focus, and everything else needs to be prioritised in light of that. Each epic feature on the roadmap generates many task-level cards on the backlog, so the timeline helps us create boundaries for scoping the details (forcing us to focus on what’s most important) and avoid becoming overwhelmed. In short, our backlog is our plan that we refer to and update daily, but that plan is informed by the strategy embodied in our roadmap.

2. Get to know your customers

We are not our customers, yet we need to know what problems they need to solve, how they interact with our software, what they get frustrated by, what features they can’t live without, and so much more. We have an ongoing exercise to define and refine our user personas (which will become a blog post of its own), but the crux of it is that we try to use every customer interaction as an opportunity to learn more about the people who use our software so that we can better prioritise requirements and design features, provide useful guidance, and generally make more informed decisions.

We are not our customers, yet we need to know what problems they need to solve, how they interact with our software, what they get frustrated by, (and) what features they can’t live without…

Customer interactions can include anything from sales meetings and conference calls to support tickets, in-app queries, and passing comments. Checking in frequently with our Sales, Onboarding, and Customer Support teams is essential to get this information. In order to validate our assumptions, we also need to interrogate our customer data and page analytics to discover trends in demographics and behaviour. Sifting through this data to identify what’s important is a challenge, but the gems we find help to validate our design personas, add weight to the business cases for our roadmap, and inform the prioritisation of our enhancements backlog.

3. Manage expectations continuously

It’s great to have a plan; to know exactly what will be done by when. Except for that one thing that took much longer than expected, and that unanticipated issue that derailed the day, and that incredible idea that would be a game changer if we could just squeeze it in sooner rather than later… In our agile world, we need to continually review our plans, adapt and update them, and most importantly, let all affected parties know as soon as possible. Nothing sours a sale like being promised a feature that doesn’t materialise, or rattles your support team like unexpectedly postponing (or pushing forward) a release.

In our agile world, we need to continually review our plans, adapt and update them, and most importantly, let all affected parties know as soon as possible.

Giving our other teams visibility into our product roadmap and backlog helps to clarify delivery expectations up front, but when plans change you can’t assume everyone is in the loop. When in doubt, a little extra communication can go a long way, especially when it pertains to scope revisions and updated timelines.

4. Don’t keep the development team in the dark

This ties into the point above, but with a more strategic emphasis. When expectations have been set or plans change, it’s essential that those involved in the actual delivery are informed of not only the what, but the why. It sounds obvious, but it’s easy to slide into a situation where developers are focusing solely on their isolated sprint tasks without realising the bigger-picture impact. If the whole team understands what the down-the-line impact of delaying a release date, or rolling tasks over to the next sprint is, then you can have productive conversations about priorities, delivery, and smarter processes. Understanding the impact of our own contributions is also key to our motivation!

When expectations have been set or plans change, it’s essential that those involved in the actual delivery are informed of not only the what, but the why.

5. Make time for strategic activities

This one is especially applicable if your Product team is small, or also has operational responsibilities. When time is tight, the “Urgent” (i.e. operational) tasks always seem to trump the “Important” (i.e. strategic) ones Our team tries to combat this by adding our strategic tasks to our product backlog, in amongst the feature development and enhancement requests. Both require our time to analyse or complete, so need to be prioritised against each other. 

Our strategic activities often include research, process improvements, or other internal initiatives that require some creative thinking or focus. These tasks are difficult to complete effectively if they’re squeezed into a half-hour here or there, so I find that scheduling time for them in my calendar, just like any important meeting, helps me find the focus I need. The happy result is learning new things, finding ways to work better, growing our team, and improving our product.