Tag: #ProductManagement - Talent Whisperers®

This “Building Bridges“ question is from my list of interview questions I for a Product Manager role. However, it can also be used for an Engineering leadership role…

If, as a product manager, you wanted to have engineering build a bridge, how would you convey that to engineering?

If it’s an engineering manager or director that I’m interviewing, I flip it around and say, how would you interact, what would you ask when a product manager comes to you and ask you to build a bridge? The other aspect here is how a manager of engineers or PMs presents problems to their reports. Are they empowering or dis-empowering?

Level 1 Answer – The pure how to build bridges (solution statement)

The simple answer given is along the lines of I’ll give you (ask for) all the requirements for building the bridge including materials, numbers of lanes, whether it should be a truss, suspension, cantilever, arch, cable-stayed, beam, girder, pontoon, etc.
How many resources and how long will it take for you to build that bridge?

Level 2 Answer – Still a How, but some of the what (combo problem and solution statement)

More on requirements such as what is moving across (pedestrians, bikes, cars, trains, semis), how often, peak load in numbers and weight, …), how far apart, how windy, what climate…

This is still a “how” as they are proposing a bridge of some form is the solution, but they are leaving you to decide the type of bridge, materials, etc

Level 3 Answer – What (problem statement)

I have had some product manager candidate recognize without prompting that they should never ask engineering to build a bridge. They should say this is what I need to get from A to B and how often and how far apart A and B are. They provide more context to the problem

Oh, your kids need to cross a creek on the way to school – got it, we’ll build you a rope swing
I see, you’re talking about San Francisco Ferry Building to Sausalito – got it, I build you a ferry system
Ah, you’re talking France to UK, got it, I’ll build you a Chunnel

Here, I like to help illustrate the importance of a good problem statement by observing traffic on the Golden Gate Bridge and the San Francisco Bay Bridge. Neither, in their design, took into account that more traffic flows in one direction in the morning and in the other in the afternoon. However, the Golden Gate is all on one level, and now they shift the middle divider to allow more lanes in one direction in the morning and others in the afternoon/evening. That’s not possible with the Bay Bridge.

Level 4 Answer – Why (meta problem statement – why is this a problem looking for a solution?)

This is where it gets interesting. They don’t start by saying this is what needs to get from A to B at this distance and this frequency, they instead explore why is it that these people/things need to get from A to B, what is the motivation, what existing solutions might exist, …

Let’s say there already is a narrow bridge to Staten Island Technical High School and the issue is that it gets jammed up with parents and kids all driving across at the same time and kids getting to school late and parents being annoyed due to the time sync… What if instead of widening the bridge or building a new one, we build a parking lot on the mainland side and have buses ferry kids across the existing bridge?
Or, people need to commute from Oakland to San Francisco to get to work and the bridges can’t handle the capacity during rush hour. Do we want to compete with all the other bridge builders, or do we look for other opportunities presented by the “why”? Perhaps offering rental office space with good teleconferencing on the side of the bridge where people live, or better tools for working from home, …

Does the candidate demonstrate and understanding of why we want to be open to creating insight into a market for a solution that is completely different than the one initially conceived?

What does the “right” product manager look like for building bridges?

Is this the kind of Product-Engineering thinking we want if we want to disrupt a business that’s been in existence for centuries? This kind of thinking is what results in thinking about an automobile instead of a faster horse…

The other thing that happens with Product Managers that operate closer to Level 1 on the continuum is that this reduces the connection to purpose and craft engineers and engineering leaders when they are told what to build and how rather than being a problem to solve where they, as the experts arrive at the optimal solution themselves. You often find this approach in large organizations that aren’t primarily software houses (such as banks, insurance companies, large retailers, etc) where the developers are seen as IT or programmers rather than as engineers. It is hard to attract and retain good engineering talent into such a culture.

An image representing the importance of a bridge or connection between engineering leadership and product management in the context of problem-solving

Henry Ford, Innovation, and the “Faster Horse” Quote

Henry Ford is rumored to have stated:

“If I had asked people what they wanted, they would have said faster horses.”

When engineering teams encounter a production issue, a common practice is to do a Root-Cause Analysis through asking 5 Whys. This approach was developed by Taiichi Ohno. One of the inventors of the Toyota Production System and described in his book Toyota Production System: Beyond Large-Scale Production. This helps understand the immediate cause of a problem, but also what led to that problem existing to begin with. In coming up with a Problem Statement, there is also value in doing a 5-Why analysis

Example of a 5-Why analysis for Building Bridges

Why do we need to build a bridge?
To get people from A to B.
Why do people need to get from A to B?
Because the live in area A and work in area B.
Why do they live in one area and work in another?
Because offices are located in area B and housing is nicer/more affordable in A.
This could lead to a few different next why questions
Why do is housing so expensive in area B, or
Why area there no offices to work from in area A, or
Why do people need to be in the office to be able to accomplish their work?
The answer to the last why may simply be because that’s the assumed way to work. Or, people aren’t set up to work effectively from home – both of these were put into question during Covid.
Why can’t we enable people to work more effectively from area A?
This could be because they don’t have the right equipment. Or, they lack tools to work from home, or because there isn’t shared work-space available in area A.
Understanding this underlying root cause of the problem could lead to arriving at solutions. These might not even require some people going from A to B every day.

Empowering engineering teams to find the optimal solutions

Furthermore, when Product or Engineering Managers offer solutions rather than problem statements, they only dis-empower and demotivate teams. Also, create an expectation that solutions will always come from the Product/Engineering Manager. These, in turn is surprised when they don’t scale and feel over-burdened. Liz Wiseman speaks to this (see below). It’s the question of wanting to be the 10x contributor vs the leader of 10 10x contributors. In the end, do you want to have a 10x or 100x impact?

Dan Pink’s what motivates us Drive – The Surprising Truth About What Motivates Us, is applicable to software engineers:

Transparency to Autonomy, Empowerment to Mastery, Line of Sight to Purpose

Autonomy (Don’t micromanage – it’s a sure-fire way to take the wind out of their sails.)
Mastery (Help find ways to master their craft; show genuine appreciation for it.)
Purpose (Why do you come to work, why do you work for this company and not another? What, in your eyes, is our business’ purpose, how does that align with what you see as your purpose? What do you hope to impact by working at here?)