Go Slow to Go Fast: Why Process Matters
Dispelling the myth that process means bureaucracy
Pick your favorite adage. Mine is “measure twice, cut once”. I am the daughter of a carpenter and a surgical nurse so it seems fitting. I have worked as an investor in and builder of technology for nearly 20 years. With every project completed, book read and year that passes — I learn. The key lesson that has repeated itself is that going slow during planning and communication is key to going fast (and in the right direction) during execution.
Below is the process I recommend for teams with cross functional dependencies, and the need to align stakeholders and accelerate decision making.
Monthly Business Review
The cadence of this review should adapt based on the maturity of the team and product and organization as a whole. It should also factor into account ways in which information is disseminated and feedback gathered between reviews. If your team, product and organization are mature, if communication between reviews is excellent, if feedback is fluid — opt for quarterly reviews. If not, start with monthly.
Format. This document will be used to facilitate a 60 minute meeting (silent reading/ commenting 30 minutes, demos 10 minutes, discussion 20 minutes). You can send it in advance, or share it right before the meeting. If you share in advance, assume the unofficial meeting starts the minute people start reading and commenting. If you share right before the meeting, you are putting an expectation on your audience that they can read and process information quickly. This document must be well written with strong curation and editing of the content.
Goals. Surface (and ideally resolve) conflict, provide clarity, and drive higher productivity with rapid decision making and organizational alignment.
Attendees. Determine who your “board of directors” are. From whom do you seek counsel, to whom are you accountable, and who are you trying to influence. Invite them. Be mindful of time zones and ensure the meeting facilitator seeks participation from all, especially key decision makers and influencers within the organization. This applies to remote or in-person meetings.
Content. Lean into conflict, strategic misalignment, and areas that need visibility or clarity. Focus on ideas and not people. The Top of Minds is the most important section. This is the template that I have iterated upon during my last two companies, learning much of this from my original manager at Square: Monthly Business Review Template.
These documents can require quite a bit of preparation but they are a great forcing function to make sure everyone on the team knows the lay of the land and holds themselves accountable in a highly (internal only) visible forum. It is also a way to recognize and celebrate the progress made and value delivered, and for stakeholders to be fully informed of our work and to have a forum to ask questions and provide feedback.
Roadmap planning is a way to facilitate discussions about our company’s priorities, projects to get there, and timelines, so everyone understands the what and the why. It helps us identify dependencies and misalignment (and ideally get aligned). Creating a roadmap forces us to plan and helps us execute towards our goals. Sharing the roadmap forces us to commit. Read On Writing Product Roadmaps by Gaurav Oberoi.
The way that teams typically plan starts broad and gets more granular the closer we get to execution (i.e. code written, QA tests run, features shipped and measured). The broadest is Annual Planning, in which strategic themes and Objectives and Key Results (OKRs) are solidified. The most granular is weekly sprints and daily triaging. Roadmap planning is essentially a team saying, “these are the tactics we’re going to employ in order to hit our OKRs”. I’m going to focus on Quarterly Planning milestones here.
Kick-off | 4 weeks before the end of quarter. Sub-teams start to pull together the roadmap for the upcoming quarter. This includes entering a list of projects being considered into the roadmap planning tool (more on that below). Ideally this is not recreating the wheel as all teams should have a great sense of their backlogs already and have been gathering stakeholder’s (especially end users/ customers) and industry feedback continuously.
At this step, the roadmap should be created and discussed with the Product Manager (PM), Engineering, Data, Design and any other immediate contributors. The PM is the directly responsible individual (DRI) for creating and curating the shared roadmap, and facilitating logistics of the meetings for the next few weeks.
First draft | 3 weeks before the end of the quarter. Sub-teams have their draft roadmap entered into the roadmap tool ranked by priority and include engineering, design and data effort estimates as well as a point of view on impact. It should also include an attempt at identifying dependencies. It is a refined list from the kick off and includes a point of view on what is “below the line” and which projects are scoping only vs expected to ship. 1-pagers, PRDs, Design files and Engineering specs should be in flight and ideally under review as appropriate. Exercise your best judgment.
Stakeholders (and dependencies) should be explicitly looped in now and should have had a chance to voice any feedback or concerns. Sub-teams will manage how to do this/ whether to coordinate across teams on their own.
Leads review | 2 weeks before the end of the quarter. Netflix calls this the Board Meeting for Product (take inspiration even if you don’t follow exactly). It is a moment for the team — the key team representative from Product, Engineering, Design and Data — to stand and deliver in front of each other and their leadership team. In this meeting, the rules of engagement are as follows (done by sub-team):
- Attendees: GM or VP, Product & Design Lead, Engineering Lead, 1–2 key stakeholders (only if appropriate), the sub-team DRIs across Product, Eng, Data & UX
- The team representatives present the roadmap — facilitated/ led by the Product Manager. This should NOT be a slide deck, it should be a line by line walk through of your roadmap
- Leadership asks open, candid questions about the plan — the what and the why (no side conversations, feedback delivered directly and with compassion)
- All action items are assigned to a specific person and a timeline committed for resolution
48-hours before the review, provide attendees with a 1-pager that summarizes the following:
- How is the team doing in the current quarter and is anything carrying over into your next quarter’s roadmap?
- How does the planned roadmap tie back to your charter and your overall Objectives & Key Results? What metrics will this move?
- Why are you prioritizing in the way that you are? What hard trade-offs are you making?
- What is your “investment allocation” in terms of % time spent on keeping the lights on (KTLO) vs. big bets, etc.? Read Managing Your Innovation Portfolio (HBR, 2012)
- What dependencies do you have? Have you secured commitment from the dependency and if not, what help do you need to correct any misalignment?
Depending upon the nature of your stakeholders, Leads from other teams may be invited to join. We aim to keep the audience small for robust conversations to be encouraged. If you need more than 2 stakeholders, please discuss with your Product Lead.
Finalize & share | Last week of the quarter. Iterate on the feedback from stakeholders and the Leads to finalize the roadmap for the upcoming quarter. This should have all final engineering, design and data estimates included as well as links to PRDs, Designs and Engineering specs where appropriate (i.e. if the roadmap line item is a spike to research some requirements, it is not expected to have a PRD — use your best judgment). You should now be in good shape to create your epics/ stories and hit the ground running when the new quarter begins. To complete this milestone, explicitly share your “final” roadmap with stakeholders.
Roadmap planning tool. Many products exist to automate the visualization, communication and maintenance of roadmaps. Atlassian (JIRA) has concise, actionable articles under Atlassian Agile Coach, a recent demo of Product Board was promising, and the content marketing from Coda demonstrates best practices from many tech teams. I have not yet personally tried Aha!, but a technical founder who I greatly admire uses this product. To date, I have been relatively old school in my use of Google Sheets for roadmap planning. I’m eager to learn what automated planning and communication tools make other teams more efficient and effective.
As you release products, make sure you announce them to your broader organization — using the communication tool that is most adopted in your organization (e.g. email, Asana, etc.). This lets people feel the momentum you have for delivering results and provides visibility for your team members — it also keeps you accountable to your stakeholders. The key is a standard format, wide distribution, and a regular cadence. An example is as follows.
Description: Today we released [awesome feature name]. It matters to [these end users] because it solves their struggles with [xyz]. We expect it to impact [# or %] of users over the course of [time frame] with a benefit to our business of [$$, ##, other thing]. Below are screenshots of the product and you can use it yourself by following these steps [link to steps].
Product screenshots: Insert images that look good on mobile (most emails read on mobile)
Contributors: Big shout out to the following team members without whom this would not be possible! [insert names, remember key dependencies]
At one company, we had an Asana board that captured all releases by team and date. This provided a great source of truth for the progress being made by all teams, in an easy to digest format. This made writing sections of the Monthly Business Review a breeze.
Be mindful of how best to share your work while respecting your audience’s time and attention. If you’re doing a gradual roll out — consider an announcement after a meaningful milestone and/or learning as opposed to bombarding inboxes for 5% roll outs of A/B testing a micro-change.
The right process includes efficient, effective communication and leans into automation when possible (e.g. streamlined status updates) — with the ultimate goal of driving results with clarity on the trade-offs being made across the organization. It takes time, but the right process ultimately accelerates decision making and execution.
That said, you must balance your approach to process with the maturity of the organization. Don’t hide behind process because you don’t have a strong vision for the product — answering for whom are we building and why is paramount before any process can help you optimize and accelerate.
Out of scope for this document, but critically important: Discipline around stand-ups, backlog grooming, triaging, postmortems and the like. Those rituals are important, but I am less rigid in my approach. Why? I find that every program/ sub-team/ sprint team/ pod needs to find what works best — 1 week, 2 week or 6 weeks sprints, whether to hold premortems or only postmortems, who attends backlog grooming, etc. It is more important that the trifecta of engineering manager, product manager and design lead are in sync and that these rituals exist vs. exactly how they are done.