This really resonates. I have seen so many teams waste energy chasing the illusion of a “perfect plan” instead of using planning as a working document.
I'm curious though. You are putting what to build first, which is the opposite of what most product leaders are advising. Usually the reason is "what gets measured gets managed" / starting from business outcomes. But it's not that you are yoloing and praying for the growth to happen. You also have metrics set up, just in a decoupled way? Why is that? In the end it seems to fill the same purpose as OKRs as you still need to know which needles are your new shipped products going to move. It's like reverse engineered OKRs
One thing that seems to be missing from this overview is prioritization. In my experience, that's also easier to do when you start with metrics to target. How do you approach prioritization?
Great questions, I'll try my best to answer, but individual product teams and our leadership might be in a better place to answer.
1. We're less worried about things being "managed", small teams are close to users and the product and we have low hierarchy. Execs can have a clear view into how products are performing and trust the product teams to do what's best.
2. Metrics play a secondary role and it's up to product teams to decide how to use them.
3. A lot of our growth comes from solving bottlenecks or issues customers (or potential customers) are having. Some of these can be discovered through metrics, others not.
4. Prioritization is done sort of at a team by team level, it is up to those teams (and really the individuals on them) to decide what to work on. We don't have a strong prioritization framework or structure. Some weeks people work on customer requests, other weeks, it's improving query performance or building a new feature they think will help usability. They're able to do this because they don't have someone telling them what to do either.
This really resonates. I have seen so many teams waste energy chasing the illusion of a “perfect plan” instead of using planning as a working document.
I'm curious though. You are putting what to build first, which is the opposite of what most product leaders are advising. Usually the reason is "what gets measured gets managed" / starting from business outcomes. But it's not that you are yoloing and praying for the growth to happen. You also have metrics set up, just in a decoupled way? Why is that? In the end it seems to fill the same purpose as OKRs as you still need to know which needles are your new shipped products going to move. It's like reverse engineered OKRs
One thing that seems to be missing from this overview is prioritization. In my experience, that's also easier to do when you start with metrics to target. How do you approach prioritization?
Great questions, I'll try my best to answer, but individual product teams and our leadership might be in a better place to answer.
1. We're less worried about things being "managed", small teams are close to users and the product and we have low hierarchy. Execs can have a clear view into how products are performing and trust the product teams to do what's best.
2. Metrics play a secondary role and it's up to product teams to decide how to use them.
3. A lot of our growth comes from solving bottlenecks or issues customers (or potential customers) are having. Some of these can be discovered through metrics, others not.
4. Prioritization is done sort of at a team by team level, it is up to those teams (and really the individuals on them) to decide what to work on. We don't have a strong prioritization framework or structure. Some weeks people work on customer requests, other weeks, it's improving query performance or building a new feature they think will help usability. They're able to do this because they don't have someone telling them what to do either.
Hope this helps!
I feel you on this. Because of the challenges, I’ve adopted an approach of updating a “rolling quarterly forecast” once per month.
I’ve had a ton of success with this across multiple organizations. I think it does a great job of attacking many of the challenges you list head on.