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.
In my last article I discussed the differences between an IT Mindset and a Product Mindset. I must have struck a chord because I heard from so many people, from all over the world, that they were stuck in an “IT Mindset” organization. Unsurprisingly, their next question was how do they change their organization, or in some cases, their question was around whether it’s possible to change an IT Mindset organization, or do they need to just leave and move to a startup?
The role of the product organization is to consistently deliver significant new value to the business through continuous product innovation. At a startup, the product team either innovates and provides real value or the startup dies. However, in larger, more established companies, product teams very often lose their ability to deliver that ongoing value. They just make minor optimizations to existing products. Or they continue to turn out more features that don’t make a difference.
I have long written about the importance of dedicated, durable product teams and that we should always strive to optimize for the team and not for the individual function (e.g. product management, user experience design, engineering, test automation, data science, etc.). It’s not hard to spot when teams have not embraced this model, as you see lots of organizational silos and “walls” between members of the team.