Products are like Cities
In Construction is Life, Kevin Kelly talks about cities and how when he used to visit large cities he used to get annoyed by what seemed to be never ending construction. He took this incompleteness to indicate that cities were bad planners. He says “Under construction was a street’s permanent state”. He states that he realized much later in life that the “constant din (i.e. sound) of work is the pulse of life for human environments.” and that this signifies an ethos of “we are not done yet.” Construction is Life!
I found that interesting and my mind immediately went to businesses and more specifically to software products. Similar to how cities such as New York are always under renovation, successful products, too are always in a constant state of renovation
The more that I think about this there are many parallels between software products and cities. Firstly, software products and cities are always in a phase of construction of withering. Secondly, cities that construct for the sake of construction are software products or features that no one uses, and finally cities like software can be exciting and serendipitous.
Software Products and cities are always in a phase of construction or withering
When I think about products they are either in a phase of construction or in a phase of withering. This phase of construction or withering happens in companies of all sizes. Think about buildings. A company might invest in and construct buildings and if they are continuously used the building will require upkeep, maintenance, new paint, and roofs – all in all a good sign. Sooner or later they will reach an end-of-life state and require that the company teardown and rebuild. Very similar to a software product either being refactored, upgraded, or re-written. This is of course called Tech Debt in software .. and it's a good thing. This means that you are in a constant phase of construction. By its very nature, an older company (or city!) will have more legacy products that are in various states of decommissioning. Deprecated products (and buildings) are constantly phased out to make way for new ones.
Construction for the sake of construction
Think back to the real-estate bubbles. Miami in 2008, for example. Developers constructed many high rises due to available budgets, expected demand, and the ever rising property prices, which as we all know didn’t last. This kind of “building” is fascinating. As a product manager this is a good example of what not to do -
constructing for the sake of constructing.
Have you ever been at a company that continuously creates but delivers no value? If you’re a Product Manager the first thing that you are thinking right now is what Marty Cagan refers to as Feature Teams. Cagan describes features teams as those that build without paying attention to the 4 risks that plague software products. In the above case obviously “value” risk was not considered.
Value risk (will people buy it, or choose to use it?)
Usability risk (can users figure out how to use it?)
Feasibility risk (can we build it with the time, skills, and technology we have?)
Business Viability risk (will this solution work for the various dimensions of our business?)
Cagan says that “The job of the product manager on a feature team is most commonly described as a form of facilitator, “herding the cats” to get the feature designed and delivered, or some nebulous and weak form of cross-functional leader that’s not responsible for anything specific. These feature teams will often think they are doing product discovery, but it’s just design and maybe a little usability testing”
Imagine (and I sure hope this never happens!!!) that you are building sidewalks on the freeway. The workers are there and building but who exactly is going to use these sidewalks? As Kelly said he was getting annoyed with the construction because he was using the roads. So if you have users that use your product and there are bugs and those annoy a user, you are indeed building the right product! The key point I am trying to make as a product manager is that your product might be “dug up” and people care. On the flip side, a perfect product that no one cares about is… well, useless!
Balancing Aesthetics
Another way to think about good products and cities is aesthetic. I have been in the Washington DC area for the past week and I have been observing the city. Suburban DC is really beautiful. Large roads, beautiful large houses with lots of space (compared to the standard $1.5M Bay Area “shacks”), new constructions, lots of trees, amazing running paths (and cute rabbits hopping around to boot), Big ass lawns. But if I am being honest it looks too plastic and sterile. Too .. constructed. Most builders seem to have used standard design v/s taking architectural risks. Most restaurants are the garden variety Taco Bells and McDonalds that you get everywhere.
When I think about software products I see them the same way. A lot of PM’s build
products that are very clean and “sterile” and they look “good” but are not very “exciting” which is why most websites and apps look and feel the same. Think about it. A popular interview question for Product folks is “Which Product do you love?”. Which app or product would you choose?
Think back to when a software product delighted you? For me the first experience buying stock on Robinhood comes to mind. I understand the argument about how it's gambling and a slot machine. Another example is gMail threaded conversations. It made tracking conversations easier and to date it's a feature that delights me.
Tying it back to suburban DC. How cool it would be to have houses that are large but look different. Each with their own personality. This is exactly why we love European cities that grew organically. You may be familiar with the work of either Jane Jacobs or Le Corbusier. Jane Jacob’s philosophy was organic growth of a city while Le Corbusier’s philosophy was that cities must be planned such as the Brasilia experiment.
Quite simply my point is as Product Managers how do you inject more delight into your product. Delight v/s basic function. Similar to how an organic city has nooks and corners with cute cafes rather than the sterile Starbucks environment
If you liked this sign up to my newsletter here
Acknowledgments
Thank you so much to Michael Dean for feedback on early drafts and for making this more understandable and relatable. I also highly recommend subscribing to his work and/or following him on Twitter
