At A New Organization Prioritization Is the First Step
10 May, 2019

VP Product at Scribd
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.
Discover Plato
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Related stories
24 May
Jord Sips, Senior Product Manager at Mews, shares his expertise on a common challenge for product managers – finding root causes and solutions.

Jord Sips
Senior Product Manager at Mews
16 May
Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Snehal Shaha
Senior EPM/TPM at Apple Inc.
9 May
Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.

Pavel Safarik
Head of Product at ROI Hunter
4 May
Kamal Qadri, Senior Manager at FICO, drives the importance of setting expectations when optimizing large-scale requirements.

Kamal Qadri
Head of Software Quality Assurance at FICO
25 April
Matias Pizarro, CTO and VP of Residents at ComunidadFeliz, recalls a time in his early career when he took a technology risk that had wide-ranging benefits to his product's user experience.

Matias Pizarro
CTO and VP of Residents at ComunidadFeliz
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.
