How we build products at Everoad. Part deux: Planning.
By: Benjamin Chino
Tags: Product Management, Strategy, Startup, Planning, Product

Part deux. We plan together. And commit.

Planning is probably the most challenging exercise that exists for a Product leader. It requires an outstanding synthesis capacity to translate hundreds of insights into a couple of projects. It implies strong leadership to challenge teams on their priorities then sell a plan once it has been locked in. And it definitely demands grit — in the end you will be judged on whether you managed to deliver your plan.

I’ve sat through dozens of planning exercises. And I still come out of each asking myself: ‘have we been inclusive enough?’, ‘are people really bought in?’ or ‘are we investing in the right things?’ … Spoiler alert — this article won’t solve for your insecurities. You probably should continue asking yourself these questions, because they are fundamental to healthy product operations. What this article can help with, on the other hand, is decreasing the risks stemming from poor planning.

Our quarterly planning cadence

Breaking down one strategy into many

Planning should always start with an overall strategy. A product plan without a clear company strategy is like a Guns N' Roses tune without any Slash solo. Pointless. This is why ours always starts with the overall mission, big rocks and objectives that are set with the collaboration of the leadership team. But because building a centralized plan is close-to-impossible, especially in hyper-growth environments, we decided to let teams plan independently.

A product plan without a clear company strategy is like a Guns N’ Roses tune without any Slash solo.

Let me take a step back here. Our team is organized around Programs. Programs are conceptual territories designed to foster fast execution while ensuring tight alignment with their business counterparts. Each PM in our team owns a Program like Shippers, Carriers, Marketplace and so on. This allows them to partner with the relevant people in our company (our PM on Shipper works closely with our entire Sales team while our PM on Money interacts daily with our CFO) while remaining laser-focused on our users.

During Planning, each PM is tasked with crafting a strategy for their Program, leveraging their backlog insights to come up with priorities. Instead of ending up with one messy centralized strategy, we end up with several — yet, nicely sharp and focused.

Moving from insights to priorities

To write their strategy, our PMs simply tap into our backlog to identify the highest rated insights and translate that into priorities. If you remember from Part one, our backlog is structured around our Programs. This allows us to store insights at scale, in a crazily Marie-Kondō-organized way, thus accelerating priority identification.

But because Planning is — and always should be — a collaborative exercise, we confront our findings with our business counterparts to make sure that we’re truly aligned behind the objectives we are pursuing and the level of priority each item has been given. Think of it as Lebron & Davis partnering to chase this year’s playoffs ring.

Obviously, it would be a bit painful for us to review decentralized strategies, so we push teams to summarize their findings and list their priorities into a unified plan. This is what our Tech leaders eventually use to finalize Planning through costing.

Our Program strategies feeding into our unified plan

Costing or the ‘best worst’ way to size your investment?

An essential piece of our puzzle is costing. Our plan couldn’t make sense if we weren’t relying on data. This is why we spend a lot of time trying to size the cost of each item in a really granular way.

Our assumptions are quite simple. We have a theoretical capacity (we use working days but you can use another proxy) that we spread across several working blocks: Strategy, Definition, Design, Build & Launch. For each role (Product, Design, Engineering) we allocate a percentage of their time to each workstream.

As a result, we know exactly how much investment capacity we have on each workstream. Then, we simply estimate the cost of each item, across all dimensions. And the idea is to fit in as many projects as possible in priority order, starting with P0s, then P1s and so on…

To be honest, we’re not so happy with this process and we don’t think we have cracked the ‘costing’ challenge yet. This is definitely better than nothing — it helps us define a rough idea of our investments, while helping teams better understand how we work. When moving into building phases of projects (stay tuned for Part three) we refine that estimation to provide teams with an accurate view of planning.

The more our organization grows, the more time PMs & Designers will be able to spend time on grooming insights super early on together with engineers. As such, instead of doing long hours of costing during each planning exercise, they’ll be able to leverage insights that had already been groomed and cost.

Translating our plan into an operational roadmap

So far, our whole plan has been static. We need to translate that into time. Our team calls this ‘Tetris’ scheduling, though I sometimes feel this looks more like a giant uneven Rubik’s cube. We need to figure out when to work on each item in a way that makes sense from a resource point-of-view. This can be quite tricky as we have multiple teams working on multiple workstreams with multiple constraints (dependencies, holidays, development plans, etc.). As such, the more you can break down your team into teams, the easier this exercise becomes.