How we build products at Everoad. Part deux: Planning.
As a Product leader, you might often be faced with three very hard objectives: addressing your customer needs in a prioritized way, rallying teams behind your plan and demonstrating high impact to your entire company.
Unfortunately, there is no magic formula here. Building philosophies largely depend on the organization itself, the people that run it and the stakeholders they interact with.
Through this series of articles, I’ll walk you through how we do things at Everoad, and the results this philosophy has yielded. Our tale will touch upon insights, planning, cadence and more-than-you-could-think-of hacky stuff.
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.
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.
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.
Et voilà. Our roadmap is now fully functional and indicates quite clearly where we stand, on each project, at all times. Obviously, our operational roadmap is fully transparent and accessible for any member of Everoad. They can retrieve the timeline of each project, but can also access project documentation, project channels, project boards and project contacts. But more on that later.
In short, here are the three principles behind Planning at Everoad.
- Backlog should be the backbone for Planning.
Don’t reinvent the wheel each time you do Planning. Just make sure your backlog is healthy and up-to-date and simply tap into it to identify the most urgent priorities. - Make it as collaborative as possible.
Partner up with key stakeholders to craft a plan that is tightly aligned with the overall strategy and the needs of our users, thus ensuring that your entire company is bought in. - Science-it-up, as much as you can.
Build your plan on truly data-powered foundations so that you don’t end up with a beautiful plan on paper, that makes absolutely no sense in reality.
Now, to be brutally honest, don’t (always) stick to your plan. For real.
Wait, what?
Chances are you will not respect it anyway. To put it another way, a plan is an objective, some form of horizon. It should never become a set of blinkers. Your source of truth should always be your business ; how it evolves, the context around it, the opportunities that arise - all of that should contribute in real-time to your plan. As such, be flexible. Move things around. Deprioritize items and reprioritize others. This is the best way to ensure that you always remain tightly aligned with the overall strategy of your company.
With that, happy 2020 planning folks!
