The Power of Prioritization
How Zymergen’s Technology team uses quarterly planning and storytelling to keep everyone focused in a target-rich environment
The Zymergen platform is an “engine” combining molecular biology, genetics, automation, and data science to reliably improve organisms for industrial applications. Building and continuously improving the platform is core to our business success. The thesis of the Zymergen platform is that we make discoveries through high throughput design, experimentation, and analysis, all of which are enabled by the Technology stack.
Product Management is the non-technical team in Zymergen Technology. Our role ranges from strategic thinking at the year-plus level to coordination of the details of feature delivery and adoption. As a team dedicated to synthesizing information into concrete requirements, we sit at the intersection of three stakeholder groups internally at Zymergen: leadership, users, and engineering, who provide feedback on needs of the business, pain points with our hardware and software, and feasibility and cost to deliver, respectively.
Why Prioritization Matters
In Technology, we need to decide what to work on, when. Prioritization and planning are critical to our success because the list of important needs is always bigger than the people and time available. Also, over time the dependency graph of features and user workflows has become more complex, requiring careful consideration of sequencing and unintended consequences. We invest in planning because we believe that engineering teams are most productive, and user interactions most helpful, when we have shared understanding and focus.
The quarterly plan¹ is how product managers translate strategy to drive execution. When we develop quarterly plans, we must meet three, somewhat competing, objectives:
- Make the best possible Technology investments, given our current knowledge and strategy.
- Leave room for flexibility in the face of uncertain priorities.
- Provide clarity to all stakeholders about what Technology will do and not do, and why.
Complicating Factors that Affect How We Plan
Our quarterly planning process follows a timeline and approach similar to this one. Over time, it has evolved to address challenges, both Zymergen-specific and universal, posed by our stakeholder mix and business needs:
- The Technology team is simultaneously ‘building the future vision’ and ‘addressing barriers to delivery today,’ a long term vs. short term tradeoff not neatly captured in ROI (return on investment) analysis.
- Our user base spans business, operations, and R&D. All are important, and there is no agreed translation between impact levers like “operational cost savings” and “enabling revenue in new markets” — each dollar saved or earned matters more to some users than others.
- Our users are our co-workers and collaborators. Transparency is key, because user participation in planning makes them our supporters and evangelists, which is important when Technology’s value contribution comes from changes we enable in how other parts of the business function.
How We Run Quarterly Planning
Each quarter, over ~4 weeks, we plan in three phases: understand, evaluate, and prioritize, described in the flow chart below.
We are in the understand phase, in the background, most of the time. We talk to people, listen to inbound feedback, monitor support channels, and review other data. This helps us build a reasonably complete list of possible projects spanning tech debt and technology experiments, user pain points, and increments towards more complex deliverables serving company strategy and product vision. When we begin planning, we collate the list in a spreadsheet, where we write a terse description of each project, e.g., “Update HPLC data parser to work with new use case X.” We also write down who cares about the project, and what strategic or user objectives it serves. For quarterly planning, a project is typically 4–12 weeks of effort for 1–2 full-time engineers. The spreadsheet is published to stakeholders: leadership (managers at this level of granularity), users, and engineering.
The evaluate phase is pretty iterative. The deliverable is a requirements description for each project in the spreadsheet. We first write paragraph-level descriptions of “what needs to be delivered for users to start using the feature,” and publish them to users and engineering teams. We then add “impact ratings” and high level engineering estimates based on their feedback. Finally, we collaborate on a ‘first round de-prioritization’ of projects that are “too expensive” or “not important enough.” Many projects de-prioritized at this point remain as paragraph descriptions for future quarters.
We develop the remaining short list into 1–2 page requirements documents. We write them using a moderately customized, JIRA-integrated version of Confluence’s out-of-the-box template (see Figure 3, below). Each document breaks down requirements into deliverable increments, and adds tiered levels of importance for each increment. We get more granular effort estimates, accounting for both time and uncertainty. Finally, we add more quantitative impact assessment. Rather than time-intensive full-fledged business cases, we analyze key drivers such as revenue enablement or cost savings to translate the “impact rating” into a quantitative impact range. Impact for us is not only how much a project can “move the needle,” but also whether it will allow the needle to be better measured, or set us up to move the needle in the future.
The prioritize phase is where we make and communicate decisions. Decision-making is the product managers’ responsibility, but stakeholder buy-in, if not always consensus, is key to delivering impact for the business. For reasons given earlier, a simple stack rank and “CEO of the product” decision-making approach don’t lead to correct or convincing results. Instead, we put together a story that organizes thematically-linked projects into groups, and presents and prioritizes them as choices to decide between. To be digestible by a diverse audience, we make the story “plain speaking,” removing product management, project management, or engineering jargon. The story typically follows this narrative arc:
- Describe where we are, and what lessons we’ve learned about effort, urgency, and importance.
- Outline choices about where to go next. Each choice is organized around some theme. Themes have recurring patterns, which most product managers would recognize, made specific to our context. For example: “faster and more effective data analysis in onboarding,” “more automated data capture and organization in manufacturing,” “tools to enable testing of step change innovations.”
- Formalize the business case for each choice. At this more macro level, we use formal business cases to assess impact. We describe the work we could do, and then size overall effort and impact for the focus area. To make this easier and more internally consistent, we’ve accumulated a set of common assumptions about cost and value in a “core model.”
- Reflect input from stakeholders about the themes (and choices) they care most about. We have recently formalized and quantified this step, inspired by decision-making frameworks like this one. Stakeholder group “votes” for themes tend to sharpen the point about competing priorities to trade off.
- Recommend how to apply resources to the possible choices. The product manager recommends an allocation decision, based on what is possible with the engineers we have, and the impact, urgency and stakeholder priorities we see. Whether the audience is leadership (executives and management), user groups, or engineering teams, our goal is to explain the thought process and get to understanding and agreement. We are consensus-builders first, and tie-breakers if needed.
What We Like About Our Process
Our quarterly planning approach contributes to team success, and the company’s ability to deliver. While there’s always room for reviewing and improving what we do, we like what we have for the following reasons:
- Time and resource bound. Takes ~4 weeks, with the bulk of the workload on PM’s and engineering manager counterparts.
- Adaptable and flexible. Works for adjusting milestones in more waterfall-like hardware / infrastructure plans and prioritizing epics in Agile software feature development. Revisiting our plans regularly ensures we stay focused on what matters.
- Fit to current scale / maturity level. The process has evolved to match our staffing level and stakeholder landscape. The Zymergen Tech team has grown 10x, and user base has grown 7x, in the last 3 years, so the change is significant.²
- Inclusive / gets buy in. Engages user groups at Zymergen at multiple stages of the process. Makes sure that stakeholders are aware of sometimes painful decisions, and understand that there was a rigorous process to make them.
- Rational. Uses the available evidence, though incomplete, to make logical choices.
- Decisive. Results in choices about “do” and “not do,” within a deadline and reflecting an envelope of engineering time available. “Squeezing more in” or “doing one more round of analysis” are not possible outcomes.
The Technology team invests in understanding our options, evaluating them carefully, and setting clear priorities, so that we deliver as much useful product as possible. In order to build a culture of effective collaboration, our leadership, users, and engineering teams need to be engaged and to understand why we focus where we do. We are excited by what we’ve achieved so far, and are constantly re-evaluating our process to balance flexibility with consistency of purpose, analytical rigor with bias-to-action, and incremental enhancements today with step-change improvements tomorrow, as the company grows.
Prasad Ganesan is Vice President, Product Management at Zymergen.
¹ As our products mature and future increments become clearer, we’re experimenting with plans extending over 6 months. But I’m going to use “quarterly” to describe this level of planning for the remainder of this post.
² Fun historical fact: In 2015, with a 12-person Tech department, “prioritization” was three people sitting in a room for half a day voting “yes” and “no” as we went down a list.