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.
In this article I wanted to talk about a concept that seems to be increasingly missing in product teams.
In an earlier article (Flavors of Prototypes) I heard from many people about how it helped them to see prototypes in a new and more powerful light. Even though I had written previously about each separately, putting them together can help people get the big picture.
One of the most significant changes in how we do product today is our use of analytics. Any capable product leader today is expected to be comfortable with data, and understand how to leverage analytics to learn and improve quickly.
Prototypes of various forms have been around for as long as we’ve been doing software, since the famous Fred Brooks quote: “plan to throw one away, you will anyway.” However, many things have changed. Not the least of which is that the tools and techniques we have for developing prototypes and testing them have developed dramatically. Of all the different MVP techniques, prototypes are among my favorites.