Devops for Growth

Product Management theoretically started back in 1931 after Neil H. McElroy wrote a short memo where he described “Brand Men” who had overall responsibility for the brand and managing a product. Ahead of his time he also described that the best “Brand Men” would do this through experimentation and customer interactions — obviously most people skipped that part!

Later whilst being an adviser at Stanford university Neil H. McElroy influenced two entrepreneurs named, Bill Hewlett and David Packark — names look familiar, anyone? Took the “Brand Men” ideology and put decision making as close to the customer as possible, by doing so they built the empire that we know today as Hewlett-Packard — (did you know Hewlett-Packard at their prime they sustain a 50 year unbroken record of 20% year-on-year growth which is just insane!)

As the name “Brand Men” suggests the origins of Product Management was truely in marketing. Largely contained to that area, Product Managers were focused on product sales through pulling promotions, price, and marketing levers, largely leaving the development of the actual product to others. This divide continued and with the rise of technology and software delivery methodologies such as PRINCE2, many Product Managers became well versed in handing over requirements over the fence to technology teams who would then build to such specifications. Such a divide can still be seen today in many organisations where Product Managers are seen as the ones who “know” the market and customers, and the IT department as the machine which is there to build to their requests.

This worked (arguably) well when products were packaged, physically shipped and changed infrequently but as digitalisation came onto the scene, complexity grew and the need for rapid feedback cycles and experimentation became paramount — this required a new thinking and new way to build products.

Trying to solve the organisational dysfunction of the dived between those building the product and those speaking with customers, Jeff Sutherland and Ken Schwaber proposed a new way to build products — a framework which promotes rapid feedback cycles and adaptation, they created what we know today as Scrum.

Seeing an ever-growing gap in the traditional Product Manager role Jeff and Ken decided to redefine it. In fact, they decided to broaden the scope of the role by bringing it closer to the team and customers — this was the creation of the Product Owner role.

“When I created the Product Owner role, I gave it more responsibility for product strategy and revenue generation than a Product Manager. I specifically pulled the best Product Manager Easel Corporation had out of Product Marketing and retrained him. It also has more responsibility for directly working with engineering 50% of the time to assure that the product fits customer needs. So it is a broader role in that sense but usually does not include Product Marketing (sales collateral, shows) or long term Competitive Analysis although it needs to support those efforts.

The goal was to eliminate the common Product Manager failing of throwing requirements over the wall only to have the customer receive something that they didn’t want.” — Jeff Sutherland