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.
One question that I continue to get from many company leaders is whether or not product managers should be given P&L responsibility for their products.
I have always been interested in taking the holistic view of product teams and understanding and appreciating each and every critical role. In a recent article I wrote about the dynamics of strong teams versus weak teams, and judging from the response to that article, many of you are interested in this as well.
NOTE: My friend and colleague Jeff Patton is the author of an upcoming book on the general topic of User Stories and especially the technique of Story Mapping. I was asked to write a foreword for this new book, and this article is an excerpt from the foreword. I was also a reviewer of the book and it is definitely a must-read for any product person and fills a very big gap in the current library of Agile titles. If you’d like to pre-order the book you can do so from O’Reilly.
In my last article, I discussed the power of milestones and I promised I’d talk about one of my favorite techniques for rapidly delivering on milestones. First, as a reminder, by milestone I mean delivering on some significant achievement for your business. This might mean achieving a meaningful improvement to a key KPI, or meeting the needs of a new type of customer, or getting the results of an important A/B test. Remember that the point of a milestone is the business result, and not the date.