In my last article I discussed how we need to simultaneously learn fast in product discovery, yet still release with confidence in product delivery. I got a very good response from this article, as well as many questions as to how teams can get better at one or both. This quickly gets into a very deep discussion of culture. You can think of this as the characteristics of a strong innovation culture, versus those of a strong execution culture.
Most of us are working on solving some pretty hard problems, and it usually ends up taking some fairly complex systems in order to power these solutions. As such, for most teams there are two very significant challenges to tackle:
In my prior article I discussed my favorite alternative to conventional product roadmaps. That article seemed to strike a chord in people, and I received quite a bit of very positive feedback. However, I also received more than a few questions. This didn’t really surprise me because as I said in the article, this is not a minor topic. But in my back and forth with people, I realized that there were several common and often significant confusions, and sometimes, the discussions would expose a more serious misunderstanding about product and how product teams work.
I have always loved the General George Patton quote: “Don’t tell people what to do; tell them what you need accomplished, and you’ll be amazed at the results.”
I would argue that two of the most importance competencies in building great product organizations, indeed nearly any significant organizational undertaking, are leadership and management. Yet so few people actually consider what each of these really means. Many people just lump the two together. Some think this is what’s taught in MBA programs (it’s not). And sadly there are many that have never experienced strong leaders or strong managers.
To continue on the series on team autonomy (see autonomy vs. leverage, autonomy vs. mission and autonomy vs. ownership), I wanted to add one more important dimension to this discussion which concerns the practical implications of working on large, multi-team initiatives.
In my recent articles I have been exploring the critically important but complex topic of autonomy of product teams. First we discussed the trade-offs between autonomy and leverage, and then we discussed the trade-offs between autonomy and mission. From your feedback I know this is a subject that is important to many of you, and I realized there was one more dimension to this discussion that I should also put out there, and that has to do with the trade-offs between autonomy and the concept of ownership, especially code ownership.
In my last article I discussed the trade-offs between the sometimes conflicting goals of team autonomy versus leverage. Quite a few of you wrote to me and said this was a hot topic at your company, and several asked about the same basic topic, but less from an engineering perspective and more from a product and design perspective. This issue comes up enough in different forms that I thought it was worth elaborating on.