Many first-time founders start with a product idea before they have enough evidence that the problem is real. Larger companies face a different version of the same challenge: they may have users, data, and a roadmap, but still struggle to decide what is worth building next.
In this article, I explore where strong audio-product ideas come from and how to research them before committing serious time, budget, or engineering effort.
Client “hire” your product to get the job done
There are many frameworks that help product teams focus on user needs. Jobs-to-be-Done (JTBD) is especially useful because it reframes the relationship between a user and their problem: instead of starting with features, personas, or market segments, it asks what progress the user is trying to make in a specific situation.
In JTBD language, the need is expressed as a job the user wants to get done. The product is what the user “hires” to complete that job. For example, a post-production engineer does not hire iZotope RX simply because they want “audio repair software.” They hire it when recorded dialogue contains clicks, hum, background noise, reverb, clipping, or other artefacts that threaten the quality of the final mix. The real job is: “Help me turn damaged or messy source audio into material I can deliver, without re-recording, delaying the project, or compromising the creative intent.”
This is why product discovery in audio cannot stop at the feature level. A tool such as RX may include spectrogram editing, repair modules, repair assistant, scene rebalance, and stem view, but the deeper discovery question is not “Which module should we build next?” It is “Which moment in the user’s workflow creates the strongest pressure to hire this product, and what outcome must the product protect?”
How to research user problems
Social listening
Social listening in product development means studying what users say publicly across communities, forums, reviews, comments, Discords, Reddit threads, YouTube comments, LinkedIn posts, and support-like spaces. It helps you detect language, frustrations, desires, competitor comparisons, and repeated workflow problems before you run interviews. It is especially useful early in discovery because it gives you raw customer language and helps you spot patterns worth validating later through interviews or quantitative research.
Figure 1 – AI-powered analysis of Reddit threads and YouTube videos about the Dolby Access app.
Secondary research
To find interesting problems to solve, you can review existing reports and industry magazines. While they may not give you the exact pains, they can be a great source of inspiration and provide insights into what topics are discussed by professionals. Reviewing already available research is called secondary research (versus primary research that you perform or order by yourself).
In-depth interviews
Another technique you can use, is an in-depth interview – structured conversations designed to understand a user’s context, motivations, decision process, pain points, and desired outcomes. The goal is to understand the user’s world deeply enough to see what problem is worth solving.
For audio products, you might interview a dialogue editor and ask:
“Tell me about the last time you had to rescue a problematic recording.”
“What is your process and what tools did you use?”
“How did the deadline affect your decisions?”
The best in-depth interviews focus on real past situations, not hypothetical wishes. Instead of asking, “Would you use an AI repair assistant?”, you ask, “Walk me through the last time you had damaged dialogue and had to decide how to fix it.”
That helps uncover the actual job-to-be-done: the pressure, constraints, trade-offs, tool choices, emotional stakes, and success criteria behind the user’s behaviour.
Ethnographic research
Asking people what problems they have may not always work as some problems may be buried deeper – a dialogue editor can do some work manually for so long that he/she will not even consider this a problem to solve and it may not come up in the interview
Therefore, it is good to study users in their real context: where they work, what tools they use, what interrupts them, what they do, and what they do not say in interviews. Instead of only asking, “What feature do you need?”, visit people in the studio and observe the workflow directly.
For audio-product development, that could mean watching a post-production engineer clean dialogue in a real session: how they move between DAW, RX, notes, client feedback, deadlines, and file versions. You may discover that the real product problem is not “they need better noise reduction,” but “they lose time deciding which repair tool to trust under delivery pressure.”
Figure 2 – In the studio (author John Hult, source: Unsplash)
Other sources of ideas
Your own problem that others may have
Many amazing products came to life by solving its creator’s creative or workflow problems. Noam Levinberg, founder of Safari Audio, shared in our podcast that over years of his mixing and mastering career, he had always missed a compressor with a specific characteristic so he created the plugin. Andrew Scheps built his Bounce Factory to save time he spends on printing mixes.
The challenge with this approach is to be able to validate if other people experience the same problem and how big the group is.
Figure 3 – Audio Products Podcast with Noam Levinberg (see in the menu)
Gaps in your product portfolio
Larger companies can build products that make their solution more robust. A microphone company can build a windscreen, a mic stand or even a recorder so their clients can get the entire recording solution in one place.
Gaps in your product portfolio
If you already have a successful product, you may want to create variants that solve problems of a different customer group.
Yamaha has a big and heavy Montage M series keyboard which can be a great studio keyboard (or for pro musicians who have their gear taken care of), but it also has MODX, which has the same amazing synth engines but a bit lower specs and it is way lighter or cheaper – it can be used at a rehearsal and by people with smaller budgets.
Same product, new GUI
While the DSP can stay the same/similar, we may want to innovate on the interface level. It can mean creating some amazing artwork like Safari Pedals have but it can also mean employing completly new interfaces and technologies like MPE e.g. Rolli and Expressive E.
Validating your idea
Finding the size of the market (called TAM – total addressable market) can be very tricky as nobody has ever done large-scale research on the audio and music market. However, with the rise of digital music tools and bedroom production, the market for music tech products is growing. Native Instruments wrote in their press release during the acquisition by InMusic that they have 25M active users. After talking to plugin companies’ founders, the TAM in this segment can be estimated in millions and includes various groups (pro audio engineers, post-production, game audio etc.).
To validate the idea, you can employ various quantitative research techniques:
- Ranking questions: ask users to order needs, features, or outcomes.
- MaxDiff analysis: identify the strongest preference from repeated trade-offs.
- Conjoint analysis: test which feature, price, and positioning combinations users value.
- Kano model: classify features as must-have, performance, delight, or irrelevant (can be used as a quantitative survey technique, but it is more of a structured product-prioritisation model than a pure statistical method).
- Concept testing: measure appeal, clarity, relevance, and intent for a product idea.
- A/B survey testing: compare two product concepts, messages, or offers.
- Purchase intent scoring: measure declared likelihood to buy, trial, or join.
- TURF analysis: find the smallest feature/message set that reaches the largest audience.
- Cluster analysis: discover groups of users with similar needs or behaviours.
- Correlation analysis: see which pains connect with intent to buy.
- Regression analysis: identify which factors predict adoption or purchase intent.
- Other techniques not mentioned in the article
Figure 4 – Hypothetical Kano analysis of RX Advanced (source: my AI PM Assistant)
Once the problem and target workflow are clear, creating an alpha testing community can help validate whether the product idea survives contact with real use.
This is not just a group for collecting opinions. It is a controlled learning environment where early users test the product in their own sessions, report friction, expose missing workflow details, and show whether the solution earns repeated use. For audio products, this matters because adoption depends on trust: users need to see that the tool fits their DAW setup, file handling, time pressure, quality bar, and delivery process. The strongest signal is not praise after a demo, but repeated use when the user has a real job to get done.
Conclusion
Users don’t buy abstract innovation. They try to finish a session, rescue a recording, move faster without losing quality, reduce uncertainty, or protect a creative decision under pressure. A strong product idea connects directly to that situation. If discovery helps you understand the real job, validation helps you decide whether the solution is worth building.
The goal of product discovery is to avoid building in the dark. Start with the user’s workflow, listen for repeated pain, observe what people actually do, test the idea with structured research, and then let real usage show whether the product earns its place. Good luck with your new product!
In the next article, I will explore how larger audio companies can build product discovery into their product development process, so it becomes a repeatable practice rather than an ad hoc activity that is difficult to plan, resource, or evaluate properly.
If you would like to learn how AI can help founders and PMs in product discovery by collecting user feedback, scrubbing and collating the data – join us our AI-Augmented PM workshsop: https://ai-augmented.pm/
