Utility, Scale, Delight: The pillars for the Architect and the mantra for the Product Manager
Product Management might be new, but making sense of the ‘what’ behind the role (and the why), begins by going way, way back in time.
Product management is no longer in the act of becoming, it has come. It has come of age in the tech scene as a critical role to the development of successful software, both front and backend. Programs & curriculum at the likes of NYU, Cornell Tech, and on all the MOOCs, are now available and it is one of the highest paying, highest in-demand jobs. Yet, it still remains unclear how to explain product management to someone, even harder to explain how one can be qualified as a product manager, and in turn use those qualifications to merit calling them ‘good’.
I don’t have the answers. And even recently as I was hiring a product manager onto my team, I grappled with whether or not I truly unearthed a proximate evaluation of their qualities as a forecast into their eventual value as a pm. However, I do think it is important to ground the ‘what’ of product management in some philosophy. Demystifying its role. Because whether it is explaining to a friend, or hiring a PM, or conveying product values to team members and engineers, understanding ‘what’ product managers has great value. It can also help keep us focused and not lose our bearings in the midst of the chaos that comes with being a product manager.
The Architect — The Original Product Manager
When I was identified by my first company out of school as someone with the ‘qualities of a good product manager’, I had never heard of it before and did not know what that meant. Even though the idea of managing a product, and doing so in a way that will make it successful, made sense to me, I still had no bearing or foundation in product management. So I started to read a lot of articles, excerpts, and books. I was burrowing around to find the best way to conceptualize the meaning of a product manager’s role in a team that creates a software product (engineers, designers, marketers, release managers, project managers, etc…)
I eventually read a book called “The Most Beautiful House in the World” by Witold Rybezynski. Yes, the book was primarily about architecture and his personal story of building a home. Yet, the book was able to capture and personify what it meant to build whatever, physical or digital. It resonated deeply with my journey in building one of my first products, and the philosophical and practical evolution I experienced. And now whenever I read books about architecture, I find myself switching out the word ‘building/structure/home’ for ‘digital product’ and these books could be re-purposed and read as guides to product management (i’ll do an article on this alone- pretty cool exercise)!
Eventually, I started explaining my tole as someone whose functions are similar to an architect, but rather than building houses I build digital products. Architects don’t physically build the house, builders and engineers do. Architects don’t pick out the carpet or the blinds or the position of the side table, interior designers do. Architects evaluate the climate and the topography to decide on using wood vs brick vs stone vs vinyl, and they evaluate the location to assess where to position the house on the property to optimize natural light. Architects work with the homeowner to identify the needs they have, i.e., how many bathrooms, bedrooms, closets. Architects not only focus on the contents of the house but make sure that the functional flow of the house isn’t such that you walk into the house and you have a wall or stairs right in front of you, and that perhaps you have a window over your kitchen sink. They do this by collaborating with engineers and builders to make sure it will built with a scalable foundation/infrastructure, and that the functional utility of the house meets the standards of the homeowners and also makes practical sense for the builders. And they also work with the designers to delight the owners, by taking the physical and functional components and displaying them in a visually appealing way. You are ultimately taking a completely spoken and conceptual dream/vision and materializing it into a real world object (house OR software product!)
Now- there is plenty to go into on the interplay between Architecture and Product, but the main illumination I want to bring to the fore is the following phrase that came from the father of classical architecture, Vitruvius (in 30 B.C.!!!):
“Well building hath three conditions: firmness, commodity, and delight.”
Firmness = Scalability. Just as building a house that can withstand the elements and be built to handle the weight of several stories, a product must be built so that it can handle large volumes of traffic, that the best possible code is written to avoid re-work on future deployments, and that the architecture of back-end systems allows for the most robust, fastest and analytical product to go to market. Depending on how technical your product may be, a product manager will play varying levels of involvement here. But there is no doubt that he/she has to focus on the nuts and bolts of the technical foundation: that services stay as pure as possible and don’t perform functions that should be done by a downstream system, that the best reporting will be available for iterative development, that the releases are tight and the features are well documented and defined in order to produce fewer bugs.
Commodity = Utility. The functionality of the product is arguably where the Product Manager is known best for their contributions. You can’t build a house that has six bedrooms and one bathroom… Utility is critical to make something functional and desirable. Ensuring that the work of dev and design converge into a product of utility and with ease of use (defined by the KPIs relevant for the product’s marketplace), is where the product manager can really show his or her worth. When building anything, it is about the ability to optimally produce under an environment of resource constraints, which means making sure to compromise on noncritical features and standing obstinately for the lifeblood features.
Delight = Delight. When it comes to delighting a consumer with a software product, the Product Manager has to be an advocate for the consumer and best understand what behavioral patterns can be expected by the target market. In so doing, they can create a guideline for designers and ultimately allow them to do what they are great at and produce a delightful UI and UX.
Summing it up
Product plays an important role, but the role is only as effective as the product manager’s ability to grasp the interplay of the three conditions of building. This product development philosophy is not exhaustive and all-inclusive, but this approach has helped me stay grounded to a very simple mindset. Mental fatigue is not uncommon in product management because complexity and obfuscation is inherent in the product manager’s daily ‘ings’ (i.e., talking, building, prototyping, emailing, explaining, etc…). Building something firm, with commodity and delight, is just a simple mantra for the product manager when building the next great ̶h̶o̶u̶s̶e̶ software product.
— Max
Quote of the day:
In matter of style, swim with the current; in matters of principle, stand like a rock. — Thomas Jefferson