A product roadmap is a plan of action for how a product or solution will evolve over time. Product owners use roadmaps to outline future product functionality and when new features will be released. When used in agile development, a roadmap provides crucial context for the team's everyday work and should be responsive to shifts in the competitive landscape.

The beginning of our product roadmap started in our backlog. We run two-week sprints in our team and after each sprint we hold a retrospective to see what went wrong, what went well, what % of tasks were successful and talk about any major feature releases. It’s an internal meeting with only the Interfaces team attending it. Mid-sprint we also hold a backlog-pruning session- where we purge all the tasks that have been on the board too long without someone checking in about them. We also see if our backlog for next sprint makes sense and whether we will have any spillovers from the current one - and anything that can’t accommodate gets moved to the next+1 sprint. These meeting happen like clockwork, every two weeks, thanks to our amazing Program Manager. So you could say that at any given point, we had a pretty good idea of what to build- for the next few years (Yes that’s how big our backlog is!) . But the issue was if we let our backlog guide us we would always be stuck in the past. These requirements were the result of goals set several quarters earlier that had either been achieved or discarded. It was around that time the Engineering team and the Product team started a discussion that how our team was become more requirements led - where business team would give us requirements and we would fulfil them - than product led. We had had similar discussions with the Group PM and we decided it was high time to set some vision and goals.

Usually there are two ways to arrive at your vision - you start at the top and think broadly what you want for the product. The product team comes up with their own ideas for the vision and the final outcome is an amalgamation of everyone’s take. This vision is informed by the team’s experience building the product, their subjective understanding of what they are trying to solve, where the product is in its life cycle and what they’ve heard from their customers/stakeholders. If a product team has been working together for a long time and on the same product- this is a great way of creating a vision. The idea is not to get bogged down the details of individual items or stakeholders and take stock of the big picture. We didn’t do that.

We make interfaces for all of Media.net’s Programatic products and we simply had too many products, too many stakeholders and too many items on our list to make a cohesive vision that would magically apply to all of them. What we did was- start from our understanding of the different requests we had received and the product concepts we were working on ourselves. We took a blank spreadsheet and listed the items we felt were the most impactful. We didn’t refer to the backlog. If an item was important -either we remembered it because we were having discussions about it or the stakeholder was checking in about continuously. This was out starting point. At this stage we had around 20 or so items. Once we had them, we went through the list a few times and a pattern began to emerge. As the Interfaces team - most of the items were either about making things more efficient, powering new use cases or making things more accessible. Hence, those three things became our goals. Our vision then naturally became to empower the other teams in Media.net to achieve their goals (for internal interfaces) and make our interface a Kew differentiator (for external - customer facing interfaces)

Once we had our vision, goals and the top 20 or so items the product team was going to work on for 2022, the aim was to ensure that our roadmap was comprehensive and we had buy-ins from all our important stakeholders - people who use our products and people who help us build our products. We did a quick check against the backlog to see if we had missed any critical items that we might need to build.

We sat down with the 5 teams we essentially build products for. We took them through our list, which, by this time had details about each items added to it along with the goal that item was trying to achieve. In the previous year we had shipped more features for some of the teams while others had been ignored because of constraints so we made sure that this was accounted for in our roadmap. The teams went into great depth about each item and also asked us to add some we had missed. Our aim was to resist as much as possible because the last thing we wanted was a bloated list which was never going to be achieved. Sometimes a little friction in the system ensures that only the necessary things get picked up. Product resists business, tech revisits product - this resistance works like natural selection.

Parallely we started discussions with the engineering team - we discussed bandwidth constraints, top-level implementation and if there were technical items for system improvements that were high priority and would need focus during the year. The engineering team had their own roadmap of items that they would work on -whenever we had spare bandwidth - but some things required special focus and specific time assigned to them. At the same time, the product roadmap had things which, although product ideas, would be purely dev-centric in implementation. So we made sure that both product and engineering were aligned.

At this stage, around last week December, I was pretty happy. I felt we had cracked it and this was it. The next year was going to be just implementing this clean and clear cut set of items that were mapped to clean and clear cut goals.

Whenever you’re trying to build something in the context of a suite of products and services, your roadmap can’t be a standalone object - separate from the rest of the company. We knew that. We had talked to all the business teams we work with. We had talked with engineering. Who had not talked to- were other product teams. It wasn’t an unplanned omission. Our understanding was that if the business team was having similar meetings with other product teams, they would tell us the items that required Interface support. And for the most part - they did. But where we fell short was not realising that other teams might have prioritised things on a completely different schedule and they can’t ship without an interface. Also- there were product concepts that they were working on which were not business requests that would also require Interface support. There are 4 product teams within Programatic Advertising in Meida.net. So we had to align product items with three other roadmaps- which involved a collective prioritisation logic, removing some items from our roadmap, and adding new items to support what others were building. To be honest, this is how the process would have happened anyway. But maybe my newness meant this step caught me by surprise. We did the necessary changes- which was a difficult and complex process- and all the product teams were finally aligned.

The final step of the process was to present our roadmap to the director of our technology group. The presentation required us to take our ugly mess of a spreadsheet and make it into a document that someone not familiar with writing it could understand. As we went about the task- one question stood out- how do we justify the distribution of tasks into a quarter-wise plan. A lot of these tasks were top level implementations with the rest of details yet to be figured out. Plus the nature of ad-tech is you can get requests from a big client that you need to fulfil on an immediate basis- disrupting the entire plan. No amount of slack built into the system can account for that even of uncertainty. So we decided to move from a quarterly system to a phase-wise system. What this did is - it talked about the sequence of execution without tying us to a timeline we might not be able to justify. We also assigned sizes to each task (to the best of our understanding) to have and idea how long each task would take. This made the roadmap more realistic. The presentation went smoothly. Off to building stuff!