Phil Laufenberg ‘Unpicking Henry Ford’s ‘A faster horse’ quote’

Adrienne: Hello, and welcome to ProdPod.  We’re a part of This is HCD. We’re bringing all human-centred practitioners real and honest conversations about product management.  My name is Adrienne Tan and I’m the co-founder of Brainmates.

Today, I’m here with Phil Laufenberg, he’s the CPO at Practera, an education software company in Sydney, Australia.

We’re discussing a quote that has been touted around in the product management circles for as long as I’ve been a product manager. That, my friends, is a really long time, it’s close to 20 years.  The quote is by Henry Ford, I’m sure most of you would have heard this quote before, it says, “If I’ve asked people what they wanted, they would have said a faster horse.” Now, there’s so much that we can talk about that, so let’s get started.  Hello, Phil.  

Phil: Hello.  

Adrienne: Thank you for joining us today.  

Phil: Yes, thank you for having me.  

Adrienne: Pleasure.  Let’s start by telling us a little bit about your product management career and what you love about being in product management?

Phil: Yes, so my product management career started back in Germany, when I was still living there.  I had a few businesses that I setup in parallel to university to really immediately apply the theoretical knowledge that I got from business school and apply it to a real-world context of, hey, does that actually work?  How can I use the things from out of the books to have an impact in the world? I’ve setup a few small businesses in Germany and eventually came to Australia, where I joined the education technology company, Practera in the first product role that they had.  Since then, I was working with universities, either as lecturer or guest tutor. Also, developed a learned platform with them to change the way we think about education. Drawing from that experience that I had developing products in my own small companies by applying the theory I had, to now, develop a product that helps other to do that, as well.  

Adrienne: Given that you’ve moved from your own small companies to a larger one such a Practera, what were the similarities in the product practices moving from small to mid-sized?  

Phil: Yes, the core similarity I think is that understanding of the person you develop something for, or you create something for.  Understanding the customer and what they actually need. You can create whatever you want, and I’ve been guilty of that a long time ago, to do something that I liked and then went out and no one really wanted it, didn’t work, so I did something else.  That was when I was still learning throughout my university degree, itself. Coming to Practera, the same thing, coming to any company, other product managers that I’m talking to are also the same thing, once we understand what the need is, the customer’s need to help them achieve their goals or overcome their struggles, then that’s when you’re onto something and when product is becoming successful.  

Adrienne: Excellent.  A great Segway to our conversation today.  Now, we all know that what’s popular, familiar in the product management space is the infamous quote by Henry Ford: If I had asked people what they wanted; they would have asked for a faster horse.  Firstly, we know that might not be true. He might not have said that, but I think it summarizes the problems with product or product management in general. I love to start talking about that.  

Phil: Great quote and I love talking about that specific topic.  I totally agree, there’s nobody in the world who actually can attribute that quote to him.  I think there was even a researcher who tried to figure it out and asked family members. There’s no record of that.  As at core value of that quote, I think it helps me to understand, or I like it because it goes into one specific area that I don’t necessarily agree with, which is interesting.  

Adrienne: Controversial.  

Phil: Controversial, that what you want on a podcast.  When we think about that statement itself: If I had asked them, they would have wanted a faster horse.  I think, well, if so, great, you asked them, that’s important, customer research. What I think is that you need to go beyond the faster horse, and especially in product management, that is your everyday job, going beyond the faster horse.  You have to talk to your customers, they might tell you that they want the faster horse, but that’s the tip of the iceberg. It’s what happens after, when you drill down, when you dig deeper into, why do they say that? What is behind to reveal the problems underneath, that you can then tackle?

Adrienne: Yes, I completely agree.  How do you approach the interview or the exploratory research process?  We all know that we shouldn’t, as product people, and of course as UXers and service designers, never ask the customers what they want, but then how do we dig deeper and move beyond the surface conversation to figure out what the customer problems are, what are some of your techniques?  

Phil: Some of the things that I usually use when I’m sitting with someone actually in an interview situation, of course, don’t, as you said, don’t start with the leading question of, what do you want?  Do you like this? Yes/no? The chances are, they will say yes because why should they hurt your feelings of saying, “I don’t like what you’ve just poured your heart into. The standard thing is, you start with building some report because later on, it’s a tactic to later on enable them to open up to you a little bit, because you need to somehow get a connection and a relationship with your customer, even though it’s maybe just a half an hour, 45 minutes.  Invest the time in establishing that. Once it goes into the more interesting bits, not interesting, of course, small talk is interesting as well.  

Adrienne: Nice save.  

Phil: But once it goes into answering the questions that you’re after, it normally starts with the symptom, it normally starts – very often, it comes out as what they want.  It’s not a bad thing, necessarily because if you’re aware that this is what happens, that people start with their symptoms, they start with some specific aspect that might evolve from an underlying problem.  Once we have that, that’s where the conversation starts and where it starts digging deeper. With anything that a customer in an interview tells you, you can ask two questions mainly, one is the, why is that the case.  

There’s the technique called the five whys, which basically just tells you, why, why, why, why.  Roughly, about five times, you’re at the root cause of the problem. It’s a really intuitive technique that I have seen a lot of times in areas where you, when you think about it from a design or product point of view, it’s super obvious, but I previously haven’t thought about it, children.  Like, I think we all have either been the child asking, why is that? Why is that? Why is that?  

Adrienne: It’s so annoying.  

Phil: Until you get into that infinite loop.  Then that infinite loop then is the root cause.  You can apply that technique to any interview setting, as well.  The second question that will help uncover more and build up more of emotionally relationship or emotional topics is, so what?  When a customer or an interviewee tells you something, so what? You ask for that reaction. How do you dare even asking that, it’s so obvious why I’m saying this?  That’s where you can see the prioritization for that would be and where you can dig in deeper. When you hear something, it’s often the symptom, it’s often the first thing that they think about, but by asking very few simple questions, you reveal a lot more than you would have thought, very often, at least, that’s my experience.  

Adrienne: Now, I’m going to bring up something controversial because I have done quite a few customer interviews, as well, sometimes I find asking in various guises why quite challenging, especially five times.  Have you done that, have you actually asked, why five times?  

Phil: I did, actually.  Just not why, why, why, why.  There are other ways of articulating that same question.  Five is a non-scientific number that leads to it. A lot of times you ask why and then why again, then it goes into a direction that has nothing to do with your capabilities to solve, what your company or organization is focusing on.  At that point, you can stop either pull it back to a new track or go with one of the things that’s been mentioned. You don’t have to go five times, and, yes, different articulations of the question, I agree with you, asking, why, why, why, why, probably does more harm than good.  

Adrienne: Yes, I think for our listeners, it’s really important to say that the technique is great, but how you phrase the question or how you rephrase the question in some cases is really important, so that you still continue to maintain that rapport with your customer.  

Phil: Absolutely.  When you get told something that might be an underlying problem but you’re not yet happy, you feel that there might be something else.  I’m normally genuinely interested in understanding it. I think that’s a big factor because if you play the interest, if you’re not authentic, then you’ll have a hard time anyway to get to the bottom of it, but if you’re really inquisitive and interested and want to understand more, then you can articulate in the way.  What do you think might cause something like that, what you just said? Then you insert their words to get them thinking of the next step without mentioning the word why. You can probably go through the five whys without mentioning why even once. Having a few of these support sentences or alternative sentences on hand is helpful.  

Adrienne: Excellent.  I’m going to ask you the question in a different way, especially given the fact that we have lean experimental techniques available to us today, do you think then we could essentially test out the hypothesis.  If I asked people what they wanted, they would have said, faster horse. Do you think we could test this out using a lean experiment?

Phil: It depends on how slow the horse was of the person who said that.  

Adrienne: Well, let’s forget the horse.  It’s the concept, right, people have an idea about what a solution for them might be.  As product people, we use lots of different kinds of techniques and the user research method is one way, but then potentially, there is a way to test out that hypothesis.  

Phil: Yes, absolutely.  I think the first step is to go into a customer interview at all.  If the first thing you hear is actually a problem that you think is valuable already, there’s no harm in checking that out and quickly coming up with a prototype or a mock-up that can validate the importance or the benefit that would be available to that person and hopefully a large enough market segment if you solved it.  That’s also where a lot of team structures also come in, because to develop a prototype, you need to have some capabilities early in the customer discovery phase. If you have cross-functional team engineers and designers and product managers, who all are involved in that early stage of customer discovery, absolutely.  

Adrienne: What if you don’t?  What I you had just a product manager, what if you were some lonely product manager, could you not test this out?

Phil: Poor lonely product manager.  

Adrienne: Or generally they’re poor lonely product managers, sorry, guys.  

Phil: There are tools out there that do enable you to test it out and I am sometimes that lonely product manager that has to test it out because the designers are busy on the work that is at hand.  The engineers are implementing the previous things. Tools like Balsamic, for example, that you really quickly create prototypes, clickable prototypes. Even if it’s just sketches on paper and there was a situation where I had the same person in the morning and in the afternoon.  I had a quick chat; we had a brief conversation about her pain points. I came up with a few sketches and just flicked them back to her via email and received feedback that evening. It’s absolutely impossible to quickly and briefly create something that you can test and validate with, then potentially also with other people in the same segment, if you have access.  To your point, don’t make it a one-week/two-week/four-week iteration. It’s not necessary.  

Adrienne: Excellent.  Going back to the famous quote, have you made this mistake, have you gone out to ask customers what solution they’re after and what were the results?  

Phil: Yes.  Guilty.  

Adrienne: Me too, guilty, as well, early on in the career.  

Phil: One of the good and not so good thing is, you can get lucky.  If you get lucky with that, then it might incentivize the wrong behaviour or the wrong perception of other people, how customer interviewing should be done.  If you are lucky, that might actually be bad in the long-term because you don’t realize, you don’t learn from your experience of what you’ve done wrong. However, at some point, you will run out of luck and you will just realize how much time you realize you wasted down the line, because it’s not just designing and implementing and launching the wrong thing, it’s also maintaining that thing now.  Internally, there’s support and a perception of that new thing that is now in the product. Why would you get rid of that again? It becomes just so expensive to backpedal once it’s out in the marketplace. The earlier you validate and the more you can prevent betting on the wrong horse, the better down the line.  

Adrienne: I think, though, whilst as product and UX folks, we know, and we’re learning the techniques to not bet on the wrong horse.  Very often, in any size organization, from a startup right up to a really large business, there are lots of different kinds of stakeholders that come up with you and say, we need the faster horse.  Now, how do you manage that conversation when your executives and stakeholders want you to build a faster horse because they know best?  

Phil: The hippo.  Absolutely. You mention a very important point; customer interviews are ideally with your customers always.  Practically and realistically, that’s not the case. A lot of ideas and lot of input that you get is from your co-workers, from your managers, from executives.  How I go about that is really appreciating that first and foremost because one, it tells you that someone is genuinely interesting in improving the product and doing something good to the users or the buyers or the customers of the product.  There must be something in there, I’m always looking for that nugget of gold that is in that idea. There was something that sparked this specific request.  

The difficult part then is to manage the expectation there, just because you have an opinion or idea about that, it will end up in the product because if we would do that, if we give into this workflow, then we will not have time to think about or go out and find the really valuable problems.  Again, it might be just the right thing. If you’re lucky and you get told the right thing, but more often than not, it’s an underlying problem that is true, but the solution to that problem is normally the wrong one. What I do with stakeholders often is, when they come up with an idea, I immediately try to change the conversation to the problem.  

Getting to the bottom of the problem by asking, why do you think that this solution would help and who would benefit from that?  Getting who’s it for and what problem do we solve for the business? Depending on who the stakeholder is who comes up with the idea, if it’s more on the business side, I also ask, how would it benefit the business in numbers?  Especially with executives, that helps a lot. The second bit that I do is differentiating between opinions and facts and do you have some data? If not, okay, it’s opinion, and getting an understanding that I don’t say that because I devalue your opinion.  

As I said before, if it comes up from an expert who’s in that field and your colleagues normally are, and there’s something to be discovered there, but one thing that really worked well in the past when this happened is, using these questions of who would it be for?  What is the problem? What have you experienced? It might have been someone from customer success who he is all the time about this one issue. It might be someone from sales who hears or who has a perception with this extra thing, customers would buy more often.  

Changing that to, what is their problem then and how would they benefit from it?  That alone, first of all, changes the conversation to a custom-centric problem-based thinking approach.  Then at the same time, I say, okay, if I would go with only that piece of information, who it is for, what their problem is, to the other room, and ask a few people there, hey, guys, this is a customer of ours, or a customer segment with these specific problems, what do you think we could do to get rid of that problem?  I ask the initial person; do you think the entire room would come up with exactly the same idea that you had?  

Adrienne: I love this one.  I’m going to try this one.  

Phil: So far, I was very successful with that.  There comes the immediate retrospect. Yes, there might be other solutions to that.  That gives me the space that I need to really discover what is behind there. What is the solution space?  Again, going back to the quote, it might be that you were just told to build the faster horse. What I then did was, I change it to, okay, I now understand that people need to go faster from a to b, a specific segment of people needs to go faster from a to b.  Hey, other people, what do you think? Maybe the engineers know, do you know what, there’s this new thing called combustion engine, maybe we can do something with that? Which your initial stakeholder might not have the information even. In that way, it helped me a lot to get the permission to explore and discover further.  

Adrienne: Have you ever come unstuck by using this technique?  Have you ever encountered someone that said, no, I’m really sorry, I don’t want to answer that question?  Why don’t you believe me? Any kind of negativity, how do you overcome that?

Phil: At times, yes, it happens.  There are so many different facets to that problem.  First of all, is it just before lunch and there is angriness?  What’s happening around in their lives? Especially when you co-locate it, it’s easier to get an understanding.  Sometimes it’s good to just acknowledge the fact and come back to it a bit later. You have a choice to debate at any point.  If you feel that there’s a lot of negativity coming towards you when you push back a little bit and unearth, chances are, something else is going on and it’s a bit of a venting.  

That person would have a different opinion or would be able to communicate or go into a discussion with a more positive mindset, when the environment or the context changes.  That’s one thing that I would always think about first, why is it such a debate and why is there negativity in there? In the end, you’re still going for the same goal, you’re still working for the same organization on the same product, apparently, hopefully, and that product has a vision and a mission.  You’re all driving there. I go from the initial concept of, everyone wants to contribute to that mission to reach it.  

Everyone has their opinions, and everyone has their lives, everyone has good days and bad days, that’s number one.  If it is, however, not that, and it’s someone who is so convinced that it’s the right thing to do, there are a few other techniques and methods I use to… then go ahead with it.  As you said before, it doesn’t take long to create something that you can use as a prototype, a clickable something. Very often, the stakeholders appreciate that as, yes, you have taken on their idea, because from a debate to immediately pushback, even if you know it’s probably not the one, but it doesn’t take a lot these days anymore to go with it and say, okay, I trust that with your experience that you had….  

What I feel is and what I’ve experienced is that people who are pushy on no, but I know it’s best, are the ones with a lot of experience in the field.  You should respect that as well. The probability that there’s something correct in there and something very valuable in their opinion, is a given. It’s not that bad to then take it on, respect it, and, again, be curious about what is behind that.  Normally, I then really want to figure out, okay, if I haven’t thought about that, but someone else who is in that industry, in that environment for a decade plus, I want to learn how that person came to that conclusion.  

I learned that by quickly doing a prototype, quickly talking to one or two people in the customer segment that is relevant, and unearth, either I was wrong with my opinion, great, I learned, or we found something that’s even more valuable and I wouldn’t go back and say you were wrong.  I checked your idea, it was great, and by talking to our customers who pay for the product, we found something even better, what do you think about that and continue the conversation, to build the relationships. Otherwise, you burn bridges right and left and centre and then you have a hard time going through in the future.  

Adrienne: It sounds like you have such an open mind and that you’re calm and that you’re very patient.  Would you describe yourself as that? Is that generally how product managers should behave? Leading question.  Oops.  

Phil: Thank you.  I think you should be balanced.  You should not get into heated debates when it’s not necessary.  Think about the people you work with and you are all in your role and in a job working for a common cause and make that your first priority whenever you think about something.  Debate different opinions about a topic are important. That’s how innovation happens. If we are different, that means we explore different angles of the same problems. Often, it’s not worth to get angry or mad or lose the cool in those situations.  I also think it’s something you can learn and to become more resilient and become more understanding of when situations arise that gets heated, and step in and be the moderator and facilitator of those conversations, if it’s you and other people. Or at least be mindful of what’s happening.  Yes, I think everyone would definitely benefit from being calm and balanced in those meetings. Because in product, every product manager deals with a whole array of stakeholders and you have to make decisions that normally don’t please everyone. If you make decisions only to please everyone, your product probably won’t succeed.  Learning that skill of being resilient and being mindful and being able to be the calm product manager in the middle of the chaos is a good benefit, I think.  

Adrienne: Lots of wise words there, Phil.  

Phil: Thank you.  

Adrienne: Thank you very much for your time today.  I think one thing that stands out for me is the, apart from the fact that you shouldn’t ask your customers the question, do you want a faster horse?  I think the more important learning is focusing on the fact that everybody in the organization hopefully is driving towards the same goal. If you have that kind of common understanding, then the heatedness, the potential angry situations can be calmed somewhat if we all know, believe, understand that we’re all working towards the same goal.  Thank you very much.  

Phil: Absolutely.  Thank you.  

Adrienne: Thank you for listening Prod Pod.  If you want to learn more about the wonderful shows on This is HCD, we’ve got others.  Such as the Power of Ten with Andy Polaine, Bringing Design Closer with Gerry Scullion, and Ethno Pod with Dr.  John Curran. Please visit: thisishcd.com, where you can sign up to our newsletter, join our Slack channel, connect with other human-centred practitioners around the world.  Thank you for listening and speak to you next time.