I joined SendGrid in July 2013 as the company’s first Product Management (PM) leader. At that point, the company was four years old, with 150 employees and an impressive revenue growth rate. Installing and optimizing PM at a rapidly scaling company is hard, so I’d like to share some of our learnings as we tackled various challenges, in hopes that it benefits the broader PM and technology community.

This post is the third in a series and addresses the topic of how to mature your product planning process–the first post focused on growing the team and the second on prioritizing usability.

To Plan or Not to Plan? That is the Question.

When I joined SendGrid, we didn’t have a repeatable product planning approach, nor did we have a published roadmap. We used an Agile Scrum process typical of early stage startups. There was a nearly religious aversion to up front planning or anything that smacked of “waterfall” thinking. All product planning was done in the normal course of 2-week Agile sprints.

This lightweight approach to product planning has its advantages in very small, early-stage companies where everyone is in the same room and the entire team can turn on a dime, but SendGrid didn’t fit that profile anymore. By that point, we had 150 people in the company and 50+ people in Engineering, spread across 6 office locations and numerous scrum teams. Our teams were also not very “fungible,” in that the engineers in each area have an area of specialization, and their productivity drops dramatically when moved from one area of the product to another.

Since our teams were a) highly distributed and b) not fungible, we had heavy cross-team dependencies that were biting us late in development cycles. We determined that more rigor around up front cross-team product planning would help us better uncover dependencies and become more predictable in our ability to deliver software, and would be worth the planning overhead of the process.

Based on our before and after performance, I believe we made the right call. How much up front planning is appropriate for your organization?

Roadmap Development

The first step in guiding our up front planning was to build out a roadmap to communicate a clear vision for the product line. Our product roadmap contains the following elements:

  • Vision statement. One sentence describing where the product is headed.
  • Product principles. Three words that describe the essential properties of the product.
  • Customer value. A description of how customers get value from SendGrid, and how our roadmap ties into that customer value.
  • Quarterly deliverables. Roadmap plans are fine grained in the coming quarter and coarse grained in following three quarters.
  • Product investment charts. We “tag” planned epics by scrum team, product theme, and company strategic initiative, and produce charts illustrating our investment across those three categories, helping us ensure our investments are balanced and match company strategy.

Quarterly Product Planning

We have settled on a quarterly cadence for detailed product planning. Any more often than quarterly, and the overhead of the process becomes too great. Any less often than quarterly, and conditions on the ground change too much and the plan becomes obsolete. Each quarter we have a series of checkpoints to ensure teams are meeting deadline deliverables, resolving blockers and dependencies, and communicating across teams.

  • Checkpoint 1:  Opportunity backlog review
  • Checkpoint 2:  Problem validation (leveraging an Opportunity Canvas artifact)
  • Checkpoint 3:  Solution validation (leveraging Story Map + Design artifacts)
  • Checkpoint 4:  High level Engineering/Architecture plan
  • Checkpoint 5:  Epic sizing and cross-team dependency review
  • Checkpoint 6:  Quarterly plan review with stakeholders

Plan Execution

Quarterly planning is done at the “epic” level. Once the plan is locked down, now it’s time to execute! We build our products using an Agile development process, with 2-week sprints. Work planned for each epic is broken down to the “user story” level via an in-depth planning meeting we call an “inception.” Stories identified in inceptions are captured in a Jira backlog tied to the planned epic, and are pulled into subsequent sprints until the epic is completed.

It is admittedly very hard and error prone to plan a quarter in advance at the epic level without the benefit of all the lessons learned during detailed story breakdown work, so we expect some level of change and have a process to deal with changes to the plan as teams refine their sizing estimates as the quarter unfolds.

Communication Ceremonies

We have several forums for communication to enable execution of our quarterly plans.

Cross-team communication vehicles include:

  • Weekly status meeting: where we focus on projects that are blocked or at risk. We also use this forum to identify and approve changes to the plan that emerge during the course of the quarter.
  • Monthly product showcase: where we demo work that got completed in the prior month to stakeholders.
  • Quarterly retro: where we discuss our collective product delivery performance in the prior quarter, and identify ways to continually improve.

Conclusion

Product planning isn’t the sexiest topic, but it’s an important one. You need to determine the level of rigor required for planning, build out a roadmap framework, implement a planning rhythm, execute your plan, and communicate along the way. I hope you took something from this post, and best of luck arriving at a product planning process that works well for your company! Stay tuned for Part 4, which will cover the topic of “Leveraging Product Usage Tracking Data.”



Scott Williamson
As VP of Product Management, Scott leads SendGrid's 16-person Product Management team. Scott and his team are responsible for driving SendGrid's product strategy and new product development, with the mission of delivering products that customers love and value.