I’m enamored with analogies. Since I was asked the question “how would you explain a database to your grandma” during an interview in college I have been obsessed to make analogies of technical stuff. I like to create analogies to help me conceptualize things, mostly, but also to 1) get other people excited and interested in what I do and 2) make communication simpler between technical and non-technical team members.

I vehemently believe that everything can be written to be understood by non-technical audiences. ( Elastic Search is a great example of making Full-Text Search understandable!)

The most popular analogy to the question what does a PM do is that you are the CEO of your product! Great! But I’d like to say that I don’t like it. In fact I hate it. It’s overly pompous and self-serving. The basic problem I find with it, is that it makes it look like Product Managers do decisions/strategy and little else. It creates a problem of people looking for this role because its a powerful role where you will tell the team what is to be done. As far as I know that is call a dictatorship and you will foster a horrible work environment that your team will quit and/or your product will be subpart because of lack of ownership and motivation amongst your staff.

The bottom line is that Product Management is a hero role: with great power comes great responsibility. I would also add that humility and a love for learning are essentials of the role.

So, I wanted to come up with analogies for the PM role that are not the CEO blah blah blah. So far I’ve come up with two analogies

Orchestra Director Architect ( the actual building kind)

Orchestra Director —

You couldn’t possibly know how to play every instrument but you have a team of people who are very good at their one instrument, you define what is going to be played, you set the pace and give high-level instructions, you don’t tell the trombone how to play but what you expect out of the player, they follow your lead all at once in synchrony. If you mess up, and provide unclear signals, then you get a bad output. And then you bring new partitures which the team and you must learn how to play again and again.

Basic right? I know it’s probably missing something about the different sections of instruments which we could equate to DevOps, QA, Support, Architect, Marketing, Sales, Ops etc but I don’t know that much about music so let’s cut it short.

Architect—

As a PM you are like an architect. You are the person with the vision. You are the Frank Gehry/Frank Lloyd Wright/Rem Koolhas/ Richard Meier/Santiago Calatrava/ I.M. PEI of your product. Do you know what engineering firm built the actual Guggenheim or the Louvre? I don’t and I assume you don’t either. The effort by hundreds of other people has gone unnoticed but they are essential part of the final product much like software products.

There is more to what architects do. According to lifeofanarchitect.com there are several architect roles:

Design Architect: they do manual sketches along with digital sketches. They often put together client presentations as well.

Production Architect: people that translate the previous sketches into proper blueprints.

Specifications Writer: pretty self explanatory. This type of architect writes “physical descriptions of the quality standards and materials that should be used to build a project”.

Contract Administrator: I got a laugh after finding this one. We could equate this to the budget administration or the relationship time you have with outsourcing or just all the other admin stuff that as Product Manager you will have to do.

So at a large architectural firm, the roles are split much like at a big tech company. This means there could be a Product Owner or a Business Analyst that do the specifications job or it could be the case that you as a PM are not required to do wireframes or sketches but your UX/UI guys is expected to do so with heavy input from you. But even if you work at a large firm as Product Manager you will have design-related responsibilities, along with production aka working with the developers on seeing the actual product being built, as well as some type of specifications either high-level or detailed.

So the similarities between a Product Manager and Architect are pretty good I say !

So let’s move one step forward and talk about who architects have to work with:

Civil Engineers: they construct and operate constructions sites. They are not limited to doing commercial or residential tall buildings but using the same construction principles they also work on bridges, roads, railways, tunnels, subway stations, stadium, planes etc, etc. The key operator is using the same construction principles over and over again. That sounds familiar doesn't it? These are your software engineers who know how to code, and apply that knowledge in different languages and paradigms to make it happen. They are several sub-disciplines like structural, environmental and transportation engineers that could be equated to the front-end, middle and back-end focus on different developers.

HVAC/Insulation/Safety: these are the guys that make sure your building is strong, and doesn’t move with earthquakes, that there is enough space for materials that expand and contract, that there are ventilation ducts and that is basically livable by human beings and can pass government regulations. This is QA! They try to break it with stress/load testing, try to get to places they shouldn’t to see what happens and make sure that it passes the users tests.

Builders: they execute against a plan. They usually are a lot of them versus a few engineers and architects. These guys could be your software engineers but I don’t necessarily think this is a good comparison.

Interior Designers are like UX/Interaction Designers. They make your product/building look great. From the right mix of natural light and artificial lights, to the right color palette, to the right furniture, these guys are all about the visuals. But they collaborate with the architect to understand where they come in, and they understand what is behind the walls and why restrictions or limitations are imposed by architectural needs. Think that every building has major foundation columns that need to be in place and the designer works to incorporate this element in the overall look.

So architects are essentially product managers of physical things. Of course one VERY important thing is that they are not trying to sell multiple buildings at once. At the most competitive levels, architects will be pitted against a handful of other architects and one design will be selected. They are not selling multiple buildings to multiple customers.

As Product Managers we also have to think of the customers who will purchase our product. Architects have one master to please, who they usually have a relationship with. Product Managers on the other hand have an idea of the prototypical customer and execute against that idea by developing features.

The contact with the customers in the form of data hopefully brings validation that the product successfully solves a problem for the customer. The idea is that everyone gets the same solution at the same price for a lower price collectively. No customization allowed!

This last part is the part of Product Management that I find addictive. Understanding the collective needs and pains of users and figuring out if your solution sticks. It’s the great unknown which can only be resolved by deep empathy for your users. It’s up to Product Managers to be the experts in your target market!

I’m looking for more analogies!! Let me know if you have an idea.

-Ale

References: http://www.lifeofanarchitect.com/what-does-an-architect-do/