“The Honda Way” For Software Product Management
I recently bought a Honda again for the first time in 5 years, after briefly cheating with Subaru. It made me rediscover why I love Honda so much in the first place, discovering all their neat little engineering surprises. I realized The Honda Way of thinking is very closely aligned to my Product Management philosophies as well.
For reference, I got a 2005 Honda CR-V. Did you know the seats are designed perfectly to fold into a bed?
And yet the second row also folds up completely to give you truck-like room:
And also there is randomly a picnic table hiding under the rear cargo area
Sure, these might be considered gimmicks, but they are also an amazing use of space, and required fairly well thought out engineering. These delightful surprises, that are functional, are what software product managers dream of.
Honda does many things we as product managers can learn from. They don’t use focus groups, instead they go out, talk to customers in the field, try to hear what they are saying (rather than do what they are asking for) and engineer solutions to those problems. In comparison to the CR-V above, GMC loves to do focus groups, and so you end up with the Pontiac Aztek
Some examples of innovative product Honda built by talking to customers to solve their problems and not following the cookie cutter:
The Honda CTX Motorcycle – Where the gas tank has been in thousands of bikes for 100 years, Honda moved and put room for a Helmet to be stored (a common problem of motorcyclists). This also made a better weighted, more efficient bike.
The Honda Insight – While Toyota gets the most credit for the Prius, Honda actually launched the first production Hybrid
The Honda Ridgeline – Unlike other full size trucks, it’s a unibody design, and has a TRUNK in the bed, because Honda realized most people that want a truck in America are not using them for work full-time.
The engineering thought that goes into every Honda always has little details: from a cooler in the Honda Element (and an interior that can be hosed off, after learning people want to bring their pets with them), to a side opening door in the original CR-V’s rather than the traditional SUV. Honda always questions the norm, and engineering leads to what the customers want.
To delve into this more, I read “Driving Honda” by Jeffrey Rothfeder, it’s an interesting analysis of how things are done at Honda that make them unique.
Rothfeder encapsulated it down to these principals, which strongly resonated with my take on Product Management in software.
- Individual responsibility over corporate mandates
- Simplicity over complexity
- Decision making based on observed and verifiable facts, not theories or assumptions
- Minimalism over waste
- A flat organization over an exploding flow chart
- Autonomous and ad hoc design, development, and manufacturing teams that are nonetheless continuously accountable to one another
- Perpetual change
- Unyielding cynicism about what is believed to be the truth
- Unambiguous goals for employees and suppliers and the company’s active participation in helping them reach those metrics
- Freely borrowing from the past as a bridge to what honda calls innovative discontinuity in the present
Thinking about each of these and how they can apply to Product Management:
“Individual responsibility over corporate mandates” – When individuals on a product team are empowered to take responsibility for their software, you end up with higher quality, more innovative work. If you are just doing things because “that’s what my boss told me to do”, you get uninspired, burned out engineers producing boring, bloated products.
“Simplicity over complexity” – This is probably the core of my Product philosophy. Simple products work. Simple is easier to optimize, simple doesn’t overwhelm. When faced with a complex solution, look for something simple.
“Decision making based on observed and verifiable facts, not theories or assumptions” – Another way of saying, “Be data driven”. Whenever I’ve worked on products you always get people who have “hunches” or “ideas”, but only when you look at the data do you really know how to make informed product decisions.
“Minimalism over waste” – You can apply this to lean development. Waste is spending 2 years of engineering on a product before releasing it. Release the smallest chunks and get feedback.
“A flat organization over an exploding flow chart” – More of an organizational than product issue, nevertheless if you need approval from 3 VPs up the chain, you’re not going to have a great product.
“Autonomous and ad hoc design, development, and manufacturing teams that are nonetheless continuously accountable to one another” – Similar to the growing “Pod” structure of product teams. Letting teams be autonomous creates a startup within a startup.
“Perpetual change” – Always question the status quo. Just because something worked for you or someone else 3 years ago, doesn’t mean it will work 3 years from now.
“Unyielding cynicism about what is believed to be the truth” – There are a lot of “facts” in product development, like “Reduce the number of fields to improve conversion rates”, but you should always be cynical of these until you have tried them on your own product. Every product/user segment can be completely different.
“Unambiguous goals for employees and suppliers and the company’s active participation in helping them reach those metrics” – Nothing gets teams spinning their wheels more than unclear goals. Working with third parties is even more fraught with disaster when given an unclear charter.
“Freely borrowing from the past as a bridge to what honda calls innovative discontinuity in the present” – Don’t reinvent the wheel, use elements of concepts that worked even pre-computer and innovate them for the current age.