One of my all-time favorite quotes in our industry comes by way of the legendary VC, John Doerr, where he argues that "we need teams of missionaries, not teams of mercenaries.” This point captures so much, and gets right to the heart of the most important trait of strong leaders, strong organizations, and strong product teams.
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.