How to Adapt the Roadmap Process to a Hyper-Growth Scaleup

Problem

Everyone talks about how growing and expanding a team is an exciting phase; hardly anyone talks about the unexpected problems that follow. The same happened to me when I first joined. Starting with about 5PMs, we rapidly grew to having 35 teams. That was massive in a period of two and half years. Although it was strong growth, the challenge revolved around involving everyone in the process of building a roadmap. Evidently, there was no actual alignment on the priorities that were causing frustration from the business. The problems grew like wildfire, just as the company was also increasing.

Actions taken

To begin with, we demanded that we should have the E-Team agree on 3 - 4 main themes for the semester. Although it might sound very simple, in reality, it was indeed challenging. They were not used to prioritizing goals the way they should have been done. Once the themes were set, the teams would define the OKRs linked to those themes. For instance, if one of the themes were mobile, the OKR would be to improve the conversion rate on mobile of X%.

Moving on, we implemented what we called “problem pitches.” Long story short, every 6 months, we would have an open meeting, where anyone theoretically could come and pitch a problem. We gave the liberty to everyone to discuss problems that were worthy of being solved by the product; then, they could have discussed that with us. The most significant barrier was that people were pretty much solution-oriented, but we wanted to prioritize problems rather than the solutions. We had a clear framework of how we could share the problem, which in my opinion, was very strong. We asked 3 questions:

• What is the problem the user is facing?
• How do you know it was a problem?
• How would you know that we have solved the problem?
  

After the pitches, we had a voting process to prioritize the problems. It was very successful in bringing the business into the process of building.

Finally, we created solution workshops. Once we had prioritized the problem pitches, we would the key stakeholders for each and lead dedicated sessions to explore the solutions. This was a way to make sure that we had the right people in the room defining the solution. Something great came out of the solution workshops, and that was it helped us collaborate. In the end, we were able to build the roadmap that we had initially started working on.

Lessons learned

• As a Product Manager, we are more leaned towards prioritizing our tasks, while the rest of the organization is more oriented towards ad-hoc projects. Sometimes they expect us to do all the work, and we have to fight for it. It is important to explain the process to get everyone on the same page.
• Prioritizing should be as much about what to do than what not to do. If it does not hurt, you probably haven’t prioritized enough. Sometimes you need to be a little frustrated to get the best out of your work.
• Although it may sound cliche, the product teams need to find their way into the organization. In that way, it would become easier to move forward in the near future.