Building Bridges Between Product and Engineering

Golden Gate Bridge from Kirby Cove

This “Build a Bridge“ question is from my list of interview questions I like to ask.
It works for both a Product Manager role and 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?

Level 1 Answer – the pure how (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
  • Oh, you’re talking about San Francisco Ferry Building to Sausalito – got it, I build you a ferry system
  • Oh, you’re talking France to UK, got it, I’ll build you a Chunnel

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?

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…




Leave a Reply
