<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Product Discovery on MYLES — Strategy &amp; Innovation Consulting</title><link>https://myles-innovation.com/tags/product-discovery/</link><description>Recent content in Product Discovery on MYLES — Strategy &amp; Innovation Consulting</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sun, 15 Mar 2026 00:00:00 +0100</lastBuildDate><atom:link href="https://myles-innovation.com/tags/product-discovery/index.xml" rel="self" type="application/rss+xml"/><item><title>Product Discovery: Methods for Finding What to Build Next</title><link>https://myles-innovation.com/blog/product-discovery-methods/</link><pubDate>Sun, 15 Mar 2026 00:00:00 +0100</pubDate><guid>https://myles-innovation.com/blog/product-discovery-methods/</guid><description>&lt;h2 id="the-backward-discovery-problem"&gt;The Backward Discovery Problem&lt;/h2&gt;
&lt;p&gt;Most enterprise product teams believe they do product discovery. They interview customers. They run surveys. They attend trade shows and listen to what the market is saying. They compile feature request lists from sales teams and support tickets.&lt;/p&gt;
&lt;p&gt;And yet, despite all this effort, their hit rate on new products hovers around the industry average: roughly six out of ten fail to meet business objectives.&lt;/p&gt;
&lt;p&gt;The problem is not that these teams skip discovery. The problem is that their discovery process is backward. They start with solutions and work back toward problems. They ask customers &amp;ldquo;what do you want?&amp;rdquo; instead of &amp;ldquo;what are you trying to accomplish?&amp;rdquo; They catalog feature requests instead of measuring unmet outcomes. They let the loudest voices — whether internal champions or key accounts — set the agenda.&lt;/p&gt;</description></item></channel></rss>