![\"Kim](\"https:\/\/infobip.com\/developers\/wp-content\/uploads\/2022\/11\/Kim-Mauch-seattle-meetup-2022.png\")
<\/figure>\n\n\n\n<\/p>\n\n\n\n
Where does product discovery go awry?<\/h2>\n\n\n\n
But first – what is product discovery, anyway? Well, it’s just a fancy expression for “talking to customers,”<\/strong> Kim explains:<\/p>\n\n\n\n So it’s going out, and it’s finding out about your customer, it’s getting marketing requirements and figuring out what are the things that are going to help drive the business forward.<\/p>\n<\/blockquote>\n\n\n\n If you’re having second thoughts about why you would talk to a customer when you can just talk to your product manager, you’re not alone. Many engineers do. But here’s the thing:<\/p>\n\n\n\n A product manager does not always have the entire perspective of that customer in mind. Like in the old story, if you have multiple blind people touching an elephant, they will have a different interpretation of what that elephant is.<\/p>\n<\/blockquote>\n\n\n\n And the same thing happens when you’re talking to customers, everyone has their frame of thinking. Every person involved will have their own view of the reality of this elephant – or this customer, as Kim points out:<\/p>\n\n\n\n This can become problematic when you only have one, or maybe a couple of people, or even a couple of different groups of people within your company talking to customers because then you get into a game of telephone. And then suddenly, you’ve got this utterly disjointed product, and it’s not even solving the customer’s needs.<\/p>\n<\/blockquote>\n\n\n\n This is precisely why the discovery team needs to be diverse, so they can all look at the problem from a different angle. Kim first learned this from the Continuous Discovery<\/em> handbook by Teresa Torres<\/strong>, which she calls the Bible for product discovery:<\/p>\n\n\n\n You need to have a group of people that form the product team. In that team, you have a product manager and a tech lead – that doesn’t necessarily have to be a manager or even a senior person. It’s just whoever’s a lead on that project. There could also be a user design lead. All of these people would be part of the discovery process.<\/p>\n<\/blockquote>\n\n\n\n The first thing the team does is figure out the business outcomes they want to drive for their customers. You have to discern this from their feedback and find ways to make it happen through available technology and your product. That’s where Henry Ford got it wrong: <\/p>\n\n\n\n It’s not that they want a faster horse; they want a reliable and quick way to get to their destination. Once you get into that place where you found an excellent opportunity to find a way for people to get to their destination faster, innovation can come in.<\/p>\n<\/blockquote>\n\n\n\n With this mindset, the developers will create more innovative solutions than anybody else. <\/p>\n\n\n\n Kim witnessed this early on:<\/p>\n\n\n\n We were trying to figure out why a certain system wasn’t working, and I was trying to explain it. I was a new product manager at the company, so I didn’t quite understand the technology. Getting one of the engineers on that call, we were able to find out it was due to the way that we were charting all the traffic the system wasn’t working. And so because of that change, we were able to say, ‘Okay, well, we need to adjust the expectations’. And we needed to change the technology just a little bit to make it all work.<\/p>\n<\/blockquote>\n\n\n\n Lesson learned – always have engineering be part of product discovery. But how do approach developers when you want them to help you with product discovery? First, it’s important to recruit the right developer, not the whole team:<\/p>\n\n\n\n Not all devs are interested in participating, so I try to find ones who are interested in customer problems and already have a customer-focused mindset. Then I make sure everything is set up with the customer.<\/p>\n<\/blockquote>\n\n\n\n Developers don’t have to talk unless they want to, but they should understand that their insight and feedback are essential. The best participation comes when the time needed is short, and there are clear reasons why a developer should be there.<\/p>\n\n\n\n Establishing a relationship built on trust is a key element here. This happens when you work with the development team to define roles clearly. Generally, product managers own the “what, why, and when” questions \u2013 the definition of customer problems and how they relate to the business objectives, strategy, and roadmap.<\/p>\n\n\n\n Developers usually own the “how” questions \u2013 which technologies, architecture, and approach will best solve those customer needs.<\/p>\n\n\n\n Product managers don’t need to have technical backgrounds to work well with engineers, Kim states, but understanding systems and communicating context can help keep everyone on the same page:<\/p>\n\n\n\n Ask questions about the architecture and development approach, but don’t dictate how the developers should solve a customer problem. Good product managers help to give this context, which can help engineers create better solutions.<\/p>\n<\/blockquote>\n\n\n\n These better solutions lead to more users and user satisfaction, and most engineers Kim knows ultimately want to have happy users. <\/p>\n","protected":false},"excerpt":{"rendered":" You’ve probably heard Henry Ford’s quote about talking to customers: “If I asked them what they wanted, they would have asked for a faster horse.” Well, here is why he was wrong – and why engineers should be the ones asking customers for feedback. <\/p>\n","protected":false},"author":8,"featured_media":736,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_import_markdown_pro_load_document_selector":0,"_import_markdown_pro_submit_text_textarea":"","footnotes":""},"categories":[28,254],"tags":[262,263],"coauthors":[152],"class_list":["post-718","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog-post","category-engineering-practices","tag-product-discovery","tag-user-feedback"],"acf":[],"yoast_head":"\n\n
\n
\n
See past the “faster horse” feedback<\/h2>\n\n\n\n
\n
\n
Not every developer is a fit for product discovery<\/h2>\n\n\n\n
\n
\n
If you demand their time, let them know why<\/h2>\n\n\n\n
\n