Product Methodology and Driver Evolution

Crafts have an evolution. Product is no different. With that said, not all the phases of evolution are beneficial. Sometimes, we realize we need something different while still desire a way to wrap our minds and work around an approach.

First, product was primarily developer-driven. What the engineers said was possible and plausible led the day. As a result, products had lousy user experiences, inferior user interfaces, and often emphasized function over form and user value. Agile was devised to help engineers get better at working with other stakeholders and to work more iteratively. Agile didn’t save the day, however, and we now know that sometimes waterfall is called to have more definition and clarity of what is being created. Engineering methodologies let us down, so we had to move on in hopes of finding a better approach.

Second, product mainly became design-driven. With the acknowledgment that development-driven products weren’t hitting the mark and the advent of design thinking, design got to steer the ship. Products became more visually appealing, and user experiences improved, but this didn’t correlate to products being more successful because there still needed to be more problem and customer-centricity. Also, considerations of data architecture and integration dependencies, among other things, needed to get adequate attention. As long as a product looked good, everything else was secondary, creating additional challenges fostered in the product management era.

Third, product management was supposed to be the stage that improved the odds of successful products and overcame the limitations of being development or design-driven. Product management wasn’t a new approach or shouldn’t have been. Successful products have been created over time by teams that valued and acted on product management principles without having to lean on product management as a crutch to make the product teams successful. Has product management helped to evolve the company’s product approach and facilitate more successful products? No one can say definitively, and this is why you have companies like AirBnB announcing they are going away from formal product management roles to a principles-based approach closer to how they operated earlier.

Fourth, because we can’t definitively say that product management has substantially moved the needle on creating better and more successful products, and because of human frailty, there will be a next stage to the product driver evolution. The next phase is data as a product or some similar reference. Data scientists, analysts, and alike will be given more control over what a product should do and how it should do it based on the data running through and coming out of a product. Is this a good evolution? Maybe, but who knows? It is inevitable, however. If it isn’t data as a product and data people driving products, it would be someone/something else because, as humans, we need to point to and lean on a labeled approach. During the development era, it was agile; during design, it was design thinking; during product management, it has been roadmaps and other product management tools. People need labels and constructs from which to create digital products because the idea of it being totally up to our ability to make sense of a problem and to build something of value to users/customers without a methodology by which to do it is too scary.

In summary, data as a product won’t be the last stage of evolution; it is simply the next one. Will it matter? Probably not. In my experience, product teams that build successful products don’t need a methodology to lean on, and those that do, in the end, won’t be much better. Is data as a product bad? No, not inherently, just like the preceding methodologies weren’t. They all got adopted because of the limitations of prior approaches and because they had their redeeming qualities and value. That said, we must evolve beyond methodology and different crafts driving product creation and return to fundamental principles that don’t need a methodology or be role-driven.