In this week’s edition of my irregularly scheduled posts, I explore how to understand when a product is good enough to allow teams to move on to higher-value work. This was influenced by the adage that perfect is the enemy of good, but with a shift of focus from how we do the work, to how we define what work we do. For a great exploration of the dangers of perfectionism, take a listen to Adam Grant’s podcast episode, where he digs into this.
After a product successfully launches, there is often an expectation that a team will continue to iterate on that product and work their way down the backlog generated in the early discovery phase. Refining user flows and adding more features may deliver a lot of value. But is this the highest value work the team can deliver to the company overall? Teams need to understand when their product is “good enough” so that they do not miss out on other opportunities to deliver even more value outside of that product.
In one of my product areas, we had an ambitious set of goals/expectations with a relatively small new team. Bringing in the learnings from my prior experiences and thinking about MVPs allowed us to quickly deliver value. However, I knew we also needed to be nimble and shift our focus to new projects to maximize our impact.
The product area leadership needed to define what the long-term goals were and ensure our teams understood them. We could not expect the teams to understand opportunity costs if they did not understand our overall goals and strategy to get there. This was difficult because initially there were very few specific/measurable goals, but we took advantage of the awesome teams that we were building and ensured they were a part of the evolution of the thinking. Importantly we also spent time connecting those goals to the overall business goals of the company to ground it in the larger mission. We felt that not only would this result in better localized decisions but it would also inform overall strategy. Given the challenges in other areas, our ambitions would be limited by our capacity, but by instilling this into the culture it meant there were more people thinking about potential opportunities and that wee had a team that felt ownership over the problem space. Without this anchor to our overall product area value proposition, there would not be a foundation for making decisions.
Early on the teams struggled with when to stop focusing on the well-defined products they had been working on and when to switch to the less-defined opportunities. They had shipped our area’s first product and easily could have defaulted to iterating on it until there was a forced change in company direction. On one hand, this would have continued to provide value but on the other what would we be missing out on? One day as leadership discussed refining the user experience and adding more functionality with the team leads, I asked (possibly a bit too abruptly), “When is it good enough?” In that moment it had occurred to me that we all were spending significant time talking about the current product as if further refinement was planned work. While there was a definition of done for the MVP, we never discussed the definition of done for the product itself and thus did not really understand if we were done. This short but provocative question led to an energetic discussion on whether anything ever would be good enough, whether the products should be in maintenance mode, or how we should go about answering questions about being done. Through that initial discussion, we were able to challenge our assumptions and inertia. It led to the team defining the highest impact remaining work so they could drive the product to harvest mode (aka maintenance mode, but approached differently, which I will dig into in a future post). This allowed the team to shift gears into a new high-impact opportunity and feel good about accomplishing their goal. It reminded the team that we all needed to question not just how we approached a problem, but which problems we should approach.
Over the next few years, the product area used this question quite often, with the team joking about how often I asked “is it good enough?” or proclaimed “I think it’s good enough!”. But it was an effective shorthand, allowing us to easily express a complex calculation. This was our signal to step back briefly to see if the goals had been met and if it was time to put something down to focus on a new opportunity. The moment I knew how important this technique had become happened about a year after that initial conversation when one of my leadership partners in a session with our peers, in other product areas, asked the question if a recently shipped product was good enough and if we should have teams move onto other work that was waiting. She and I shared a knowing smile and continued with the conversation. Later that day as I was slacking about that moment, I was reminded that this was not my first attempt at using this idea: a few years prior my previous teams had created a #good-enough slack channel. This was used to discuss a system that we had been iterating on for months to determine when it was good enough to ship and meet our important deadlines. I did not realize it at the time, but there was a more fundamental perspective beginning to form.
Much of my product area’s success can be attributed to the talent we had assembled, but instilling this shared ownership of business goals and culture of “good enough” was powerful in focusing those awesome teams on the most impactful things. As Gergely Orosz points out in his recent post, there is a growing need to balance iterating on existing products and focusing on new opportunities. With the challenges many companies face, they will need to transition from hyper-growth models as an avenue for new development, and instead find ways to focus their teams on new products. While the solutions will differ from company to company, I encourage leaders at all levels to ask a very important question as they develop those plans. “Is this good enough?”. Give it a try, I did and I don’t regret it.