“So, what do you do?”
“I am a product manager.”
“I’m in the software industry?!”
“…but… erm. What do you do?”
Sounds familiar? This is how I explained to my mom, what a product manager actually does.
I don’t know about your mom, but mine actually has overlap with tech people in her work and she still had no idea what I was doing. When trying to explain to her, I came up with the analogy of building a house and I’ve used it a couple of times now.
It didn’t only help people outside of tech understand what I do, it also gave me a new perspective about what I do. Putting something into simpler, more commonly understood terms is a great exercise for any PM to get better understanding of the matter at hand. Which turns out to be really useful when that matter is your job.
Building a House
A house is something everyone knows. It is a lot more palpable than software for most people, especially when you talk about building it.
To build a house you need a whole team of experts on different subjects, like an architect, a brick mason, a plumber, an interior designer. You want to make sure that your future home owners are happy with their new house and it won’t collapse or the wiring will short-circuit and the house burns down.
If everyone would just do their thing, this would be chaotic, so you need a foreman. A foreman leads the work crew, but does not have disciplinary responsibility. Yeah, you’re not the CEO, you’re the foreman of your product.
Future Home Owners
Let’s go a bit bigger and assume our house will be an apartment building with several units. The stakeholders are the ones commissioning the building, they have a vision and a strategy (hopefully) and fund the endeavour.
So there’s some high level input from them.
I like to think of my customers as the people who’ll actually live in the apartments. Yes, they will move into my product. Ok, maybe not, but you know what I mean.
They have ideas about their future home, those ideas might not all be feasible, some might not even be completely tangible and some might differ greatly from what the stakeholders aka investors have in mind.
In the end you have to keep both your stakeholders and your users in mind to build the best house for everyone.
The Work Crew
Here’s an overview of the team members you ideally have on your cross-functional work crew. See what I did there?
You gotta have people taking care of the statics of your house (architect, both in housebuilding and software). Someone needs to get all the plumbing and wiring in place so everything works, but you don’t see it (backend developers). You want your dry walling to be flawless and give you the perfect surface for your wallpapers and the rest of the interior design that has to happen (front end developers and designers).
And while everyone works on the house together, one person has to have an overview, so that you don’t end up with a house that’s lacking the basics like the door. If you have crooked drywalling, the wallpaper can be the prettiest one, it’ll look wonky. And if you did not build a good fundament your house might collapse and you will have to start over.
What a PM Actually Does
- You have to constantly work on your house so it’s up-to-date. If you just leave it for a while, it might get shabby and the paint will chip off, maintenance isn’t flashy, but necessary.
- Sometimes you have a great house, but the market demands fancy extras, so you go ahead and build a sun room or a pool and sometimes you add on a room and ruin the whole building. (We’ve all been there, haven’t we?)
- Don’t let pretty interior design blind you, plumbing might be terrible. Make sure the plumbers on your team will make sure this doesn’t happen by keeping you in the loop about their pipes. (Those are your own dirty thoughts!)
These are just a few examples, I keep using this analogy to explain nuances of my day to day work and being a product manager in general. I see myself as part of the team, but I am also the one that talks to various business partners. I will do anything and everything for my team to build the best house we can! Beat that, Bob the Builder!
This post was inspired by a fellow PM asking how people explain product management to non-tech people. Do you use analogies to explain PMing, which one’s your favourite?
About me: I am Lisa Mo, that’s short for Monika, 33, passionate about product management, agile methodologies, learning (right now web development), craft beer and makeup. I just moved to the Great White North, Toronto to be specific. I am always happy to connect and chat about my experiences and what I have learned so far, sharing knowledge is fun!
If you liked this, your applause is much appreciated! You can also find me on Twitter and all the PM slack teams, like Product School, ProductStack or Mind The Product, etc. 😉