Team Learning Summary
Across all three of our tests from last week, our goal was to understand whether creators actually value collaboration, simplicity, and audio quality enough to justify building around those features. We ran a mix of ad based and prototype based experiments, each targeting different parts of the product risk.
- Matthew, Yosief, and Emily explored whether creators care more about audio quality vs integrated video tools.
- James and Rachel focused on whether creators actually prefer real-time collaboration to asynchronous workflows
- Julian and Naima tested whether editors truly want advanced audio controls or prefer simpler tools.
Together, these tests helped us identify which features make SoundWave truly valuable and which might overcomplicate it.
Audio-First Editing Adoption:
Link: Evidence
All 3 interviewees said they’d use an audio-only tool. That’s good news. The interesting part is why and when. One person specifically said he’d use it “if it produced better audio editing” and liked the streamlined UI. Another pointed out that export/import friction “doesn’t take that long… I usually have to do that multiple times anyway.” The third would use it “for a film or something that needs good audio” but stick to iMovie for quick projects. Our takeaway is that people will absolutely tolerate workflow friction for better audio quality, but their use case matters a lot.
High-stakes stuff (like full podcasts) means they want quality tools. But, for quick projects, they want convenience. For us, this means our core hypothesis holds up for the segment we’re targeting. Lack of video editing isn’t a deal-breaker for content teams working on serious audio projects. The audio-only approach is totally viable here. We need to be sharper about who we’re building for though. We’re not the tool for solo creators doing quick turnarounds, which is fine. Our sweet spot is probably collaborative content teams working on premium productions where real-time collaboration actually saves time and hassle. From here, we could test with 5 users from actual collaborative content teams. We need to validate that team-based editing justifies the tool-switching overhead. In our mind, that’s the key question now.
For our product, the plan is to keep building out collaborative features (simultaneous editing, comments, version control) alongside core audio quality stuff since both matter equally to our value proposition. In terms of positioning, we can update messaging to emphasize “collaborative audio for teams who value quality” instead of general audio editing (folks who need collaboration and are willing to pay), and be more selective in who we target. However, this direction does raise the question of “are we narrowing our TAM too much by excluding the quick-content crowd?” So we should be careful and really spend time hammering out what, exactly, our ideal market looks like.
Real Time Collaboration Adoption:
Link: Evidence
We created two landing pages using adaptive.ai, one for real time collaboration and one for solo browser based editing. We shared both on the r/PodcastPromoting subreddit to see which idea got more interest. The collaboration version performed much better. It had 320 views, 60 upvotes, 4 comments, and a 24 percent click through rate. The solo version had 146 views, 24 upvotes, 1 comment, and only an 11 percent click through rate.
Comments also showed much stronger enthusiasm for the collaboration concept. The comments pointed towards channels for immediate feedback and easier ways to convey a vision as a big plus that would save them a lot of back and forth. Another mentioned that version control was a major pain point. In contrast, solo creators mostly said their current setups were fine and that they would not switch just to edit in the browser.
These results support our belief that team based workflows have a bigger problem to solve and a stronger need for a better tool. The difference in engagement showed that collaboration is not just a nice feature but something that directly addresses real frustrations. Going forward, we plan to focus our MVP on shared editing, commenting, and version sync, and test if users actually invite collaborators when they first sign up.
Advance Audio Capability Need:
We put up a simple fake Instagram-style feed at https://julianallchin.github.io/ctr-test with both ad concepts embedded and used separate bitly links behind each ad (one for simple tools, one for the advanced tools) to capture clicks without setting up full analytics or real paid campaigns. We didn’t track total page views on the main feed, so we’re not sure how many people actually saw the test, but we know at least 16 clicks went to the simple version and 9 to the advanced version. People may have clicked twice—it’s unclear.
To avoid spending money and dealing with Meta’s ad policies, we mocked how a real campaign would behave by sharing the link organically with friends instead or running actual ads. And we minimized position bias by randomizing which ad appeared first in the feed so results weren’t just “people click the first thing they see.” The outcome challenged our original assumption that podcast editors primarily want advanced editing capabilities and suggests that we should focus our concept and future tests on simple, fast, low friction tools before diving into complex (and potentially expensive to develop) pro features.
Team Reflection and Next Steps
When we reviewed all three tests together, the strongest and most consistent theme was the value of collaboration. Across both the prototype feedback and the landing page results, creators showed much higher interest when the tool emphasized real time co-editing and shared workflows. That pattern held even when individual preferences around editing complexity or workflow speed differed. Collaboration consistently came up as the clearest pain point and opportunity.
The results around audio quality were more mixed but also revealing. Matthew, Yosief, and Emily found that people working on high-stakes projects were willing to trade convenience for better audio quality. At the same time, Naima and Julian’s experiment showed that when choosing between simple and advanced versions, most people clicked on the simpler one. After discussing this as a team, we agreed that these findings describe two different user types rather than conflicting results. More professional or team-based creators value high-quality sound and control, while solo creators and hobbyists prioritize speed and ease.
Taken together, these tests suggest that our best path forward is to focus on collaborative audio workflows for small teams. Our next step is to build a set of lightweight prototypes that test specific collaboration behaviors, such as live commenting, multi-user waveform editing, and real-time playback sync without truly building them out. We also plan to run a short onboarding test to see if users actually invite a collaborator when given the option, since that would confirm the importance of teamwork in practice.
In the short term, we’ll continue refining the prototype experience instead of jumping straight to a full MVP. Each test will help us better define where collaboration adds the most value and how to keep the interface simple while still supporting high-quality editing. These insights will guide our next design sprint and future user tests as we keep narrowing in on what makes SoundWave most useful to creators who work together.
