Assumption Risk and Test Selection
This weekend our team revisited our assumption map from David Bland’s lecture to figure out what beliefs could completely derail SoundWave Studios if they turned out to be wrong. We talked through every major idea behind our product and ranked them by how uncertain they are and how much damage they’d cause if proven false. It quickly became clear that our riskiest assumptions weren’t about UI choices or color schemes and they were instead about the core foundation of whether people actually need, want, and would pay for what we’re building.
After some debate, we narrowed it down to three critical assumptions:
-
Real-time collaboration: This is the heart of our product idea. If creating together in real time doesn’t actually make editing easier or more enjoyable, then our entire concept loses its main value. We’re betting that podcasters are frustrated with sending files back and forth, but if that pain isn’t as big as we think, collaboration might not be the selling point we imagine.
-
Audio-first editing: Even if our collaborative platform performs well, it only matters if creators actually prefer an audio-focused workflow. Our assumption here is that podcast editors care more about high-quality audio tools than about having built-in video editing features. This is a risky assumption because many creators today record video podcasts or publish to YouTube, so deprioritizing video might make the platform feel incomplete. If most users still expect integrated video capabilities, our “audio-first” approach could limit adoption from the start
-
Advanced audio capabilities: We’ve talked a lot about how complex our editing tools should be. The risk here is that we build advanced features most users don’t actually care about, or that we overestimate how technical our audience is. If podcasters just want something fast and simple, investing time in pro-level features could pull us in the wrong direction.
We chose these because they strike at the two pillars that decide whether SoundWave can work at all: desirability (do users want it) and focus (are we building the right things). These assumptions are the most dangerous because they involve user behavior and motivation things that can’t be guessed or reasoned out, only tested.
Each pair on the team created a test card for one of these risks, and in the next phase we’ll actually run these tests to see what’s real and what’s just our own optimism. The goal is to learn quickly, not to prove ourselves right.
Test Cards
