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.
Virtually every leading tech company has jumped on the empowered, dedicated/durable, cross-functional, collaborative product team bandwagon, and I think things are much better for it. I don’t see very many companies that are still using the old models (primarily the pool model).
There are of course many ways to come up with significant new product ideas. Historically, the two main approaches have been: 1) to try to assess the market opportunities and pick potentially lucrative areas where significant pain exists; and 2) to look at what the technology or data enables – what’s just now possible – and match that up with the significant pain. You can think of the first as following the market, and the second as following the technology. Either way can get you to product market fit.
One of the tenets of Product Discovery, Lean UX and Lean Startup methodology in general, is to try and avoid or reduce waste. Mostly that means tackling the situation where we design, build, test and deploy a solution that fails to meet its objectives. However, in this article I wanted to focus on another form of waste, one I find particularly frustrating, one that I’ve seen in countless teams, and one that I believe is completely avoidable.