At A New Organization Prioritization Is the First Step

Problem

A problem I see over and over again is prioritization. In the end the Product team owns the roadmap, which says what we're doing when and how much of our valuable resources are being spent on the work we do. When there are multiple good ideas with positive outcomes, how do you know which to do now and which can wait? I recently joined a start-up that has more appetite for innovation than team to complete them. The management team was frustrated with not knowing what to expect or why some things were happening ahead of others.

Actions taken

• The first thing I had to do was to understand the goals of the company, both overall and on a team-by-team basis.
• Then I identified what the team(s) thought we should be doing. Most of the projects were proposed solutions, so the next step was to identify the expected outcome of the work, and then do an assessment of other ways that could achieve the same outcome. In many cases, just going through this process helped to separate high-impact product suggestions from more speculative ideas. Connecting the work to the outcome was critical in helping all of us think more creatively about how to hit the goals.
• Once we had a better understanding of the expected impact of the projects, we moved to scope assessments. Previously, scoping efforts had been based only on engineering "time to develop" - it didn't include design, stakeholder alignment, or operational impact. Adding these highlighted dependencies on scarce resources or on having other projects completed. We also broke out big conceptual ideas into smaller, deliverable projects.
• Finally, we created a single forced rank list of the projects and mapped out on a week-by-week basis what that would look like. This became our roadmap.

Lessons learned

• It was difficult to shift the discussion from "work to be done" to "outcomes to be achieved". At every meeting, I heard variations of "just tell me how quickly we can do it, I already know that we need to do it". Often, it was the most confident people who hadn't evaluated alternate ways to achieve that particular outcome. Getting them to reframe the request required continued investment in education and creative solutioning.
• Small, tactical requests we just did as quickly as possible without analysis. The rule we try to use is that if doing it will take less time than analyzing it and there is little risk, then just do it as quickly as possible.
• There were some who wanted to do an ROI analysis of every project so that prioritization would be based on a single metric of expected value. This was just a dead end and overly favored marketing projects where that analysis was easy over operational improvements that were more difficult to asses but were of potentially greater value in hitting our stated goals. Getting to an "apples to apples" comparison sounds good, but was impractical and wasted valuable analytics time.
• Instead of working with stakeholders separately and only discussing their projects, we went through the collective goals and roadmap with everyone. This helped ensure that all stakeholders understood the criteria and the tradeoffs. They had time to give feedback and question the goals. When everyone agreed to a change in order, scope, or timeline, we did it even if it was different than what we had determined in our analysis.
• In a new organization, you have to make the investment in understanding not only the work, but the people. It takes a lot of time and effort, up front, but pays off over time.
• It is important for people to feel a sense of ownership not only over their own work, but over the collective impact of the Prod/Dev team.
• The best moment was when the Growth VP started arguing for moving an Operations project up in priority (over some of their own requests) because they understood and agreed that it was the better overall outcome for the organization.