- Lessons Learned the Hard Way
- Posts
- Values + Process: Product Operating System
Values + Process: Product Operating System
A different kind of newsletter today
Different kind of newsletter today: I’ve been thinking about how to best set up the team and the org in a way that aligns what we believe in (“organizing principles”, below) to a process for strategic planning and execution.
To give credit where it’s due: the vast majority of the below is a summary of what I learned from my time at The Knot Worldwide. We replicated much of this when I was at Buoy Health and I think it worked well there, too, despite being a very different stage of company.
I’d love to hear from you if you have feedback on this. Every organization is different, with different culture, size, complexities, etc. So I don’t expect this to work well as-is for everyone, but it probably works for companies with 30 to 3000 employees if, and only if, you have CEO buy-in on the organizing principles.
Thanks all, and have a great weekend.
Dave
Good process derives from our values, so let’s talk about our organizing principles:
Strategy before execution: To reach the highest peak, we can’t just close our eyes and walk uphill. The biggest waste of resources is time spent building the wrong thing. Taking the time to create a hypothesis for how we win, describing how we’d measure sufficient progress, and capturing that as OKRs is how we create the shortest path between today and our goal.
Outcomes over outputs: We can’t reliably know in advance if a particular feature will successfully deliver value to our users and our business. By setting goals around the delivery of value instead of the delivery of work, we can make room for those who are closest to the data and to users to discover the best solution that creates the most value.
Autonomy, earned through accountability, increases velocity: Discovering the best solution requires rapid iteration and testing of various ideas. To move quickly, teams need to be able to cycle through these ideas without having each and every one approved by the chain of command. Earning the trust to do so requires the team holding itself accountable to delivering on their committed outcomes.
Based on these operating principles, we can create operating system processes:
Quarterly planning:
5 weeks before end of quarter (EOQ): exec team starts to plan for next quarter’s strategy and OKRs.
4 weeks before EOQ: First draft is published to department leaders.
3 weeks before EOQ: Department leaders use draft company strategy and OKRs to draft department strategy and OKRs. Bottoms-up feedback on company-level strategy and OKRs is sent up to the exec team for consideration and potential inclusion.
2 weeks before EOQ: Larger companies will want to do a third level of strategy and OKR drafts, at the team / squad level. This is when we figure out our hypotheses for what we think would best achieve the draft OKRs, our reasons to believe in these hypotheses, the % of team resources we want to dedicate to each, and capacity planning. This information is sent up the chain to help refine the department and company level OKRs.
1 week before EOQ: Department leaders meet with stakeholders to review their OKR progress in the current quarter, celebrating wins and owning losses, and sharing what they learned. They are also presenting their proposed strategy, OKRs, and roadmap for the upcoming quarter. (Team leaders are doing the same to their stakeholders, if applicable.) Debates are being had on 1) if these are the right goals, 2) whether this is the best path to those goals, 3) are we resourcing appropriately to achieve our goals. The discussion may spawn some post-meeting follow up action items, but a successful meeting ends with general alignment from all stakeholders.
1st week of new quarter: All hands presentations are given to look back at the previous quarter’s OKRs and learnings, and to communicate the strategy and OKRs for the new quarter. Strategy memos are published to further explain, if desired.
6 weeks into the new quarter: Mid-quarter check-in presentations at each level (exec, department, team) to see how we are progressing to goal, review how we plan to spend the remaining 6 weeks of the quarter, how we want to respond to at-risk OKRs, and consider course corrections or changes in resourcing.
Metrics review:
KPI reports are generated every Monday and reviewed by the KPI owners Monday afternoon. Investigations are started and plans created, when necessary.
Exec meets Tues/Wed and reviews metrics with relevant explanations and action plans as part of their meeting agenda.
Product development using 2-week sprints:
Teams kickoff their sprints with sprint planning and end with a retro. Depending on the culture, a sprint demo ritual may also be valuable.
On the last day of the sprint, the squad PM sends out an update (via email, slack) sharing a TL;DR exec summary, OKR progress update, what we did in the sprint, what we learned, what we’re working on next.
In the first week of the sprint, the squad trio, lead by the PM, meets with stakeholders for a biweekly Product Review. This is the meeting where PMs get to ask stakeholders for feedback and decisions. This is also when stakeholders get to ask PMs questions that are on their minds. The pre-read is the update from the prior week, which means no time should be wasted in the meeting presenting the content already contained in the pre-read.
In the second week of the sprint, the squad trio, lead by the product designer (PD), meets with stakeholders for a biweekly Design Review. This is the meeting where the PD shares their latest designs for feedback and decisions. This is not a design approval meeting, because we can’t know what works until we test it. But stakeholders can and should give feedback for the team to consider, and make decisions on requirements where needed.
This approach delivers on our organizing principles: we are using OKRs to capture our strategic planning and our focus on outcomes as the measure of value creation. We are giving the individual teams autonomy to discover the best solutions, and in exchange they are holding themselves accountable every 2 weeks via updates and Review meetings, at the mid-quarter OKR check-in, and at the end of quarter OKR review. Stakeholders have visibility into what is being worked on and no less than biweekly opportunities to give input, see what’s going on, and impact execution. Most importantly, we’re insisting on having a clear “why” for everything that we are doing and the opportunity cost for choosing it over something else.
Reply