OVERVIEW
Podball is a web-based tool that was created to help increase the productivity of hobbyist podcasters. This product was developed and created by a team of 1 product manager (myself), 1 product designer and 2 developers as a project for the Winter 2021 Co.Lab Cohort. Podball helps speed up the editing workflow by providing a cheat of edits based on the users’ needs having to detect and edit out certain instances:
- Ums and uhs
- Unexpected sounds (“thuds”)
- Filler words (like, you know)
- Long pauses
Podball also enables users to detect specific keywords in their podcast audio which can be very valuable in creating soundbites for marketing purposes.
Check out our 3 min pitch video here.
THE PROBLEM SPACE
Podcasts are a popular and growing storytelling medium. The COVID-19 Pandemic has continued to accelerate the increase of podcast listening, with global usage being up 42%. Podcasthosting.org reports that as of May 2021, there are over 2 million podcasts and over 48 million episodes.
Despite their popularity and low barrier to entry (recording studios are no longer necessary to record a podcast and can be done from the comfort of one’s home), the production process can be time-consuming with editing taking up the bulk of it.
I chose podcasting as the problem space, because as a podcaster myself, I understood the pain points of being not just the podcast host, but the producer of one as well. As someone who has spent a significant amount of time editing per episode, I could empathize with the user and provide input to the product from a user perspective.

BACKGROUND RESEARCH AND SCOPE
Prior to working with my team, I spent 3 weeks researching the problem space, conducting user interviews, synthesizing the findings and developing a product spec. I had conducted 15 user interviews with podcasters to learn more about their motivations for podcasting and to get an idea of what their workflow was like. The original proposed idea was to create a product that would automate the removal of certain filler words and sounds from the audio. Given the time constraint of only have 5 weeks to go from ideation to MVP, early on we decided to pivot and focus on a simpler solution that didn’t interfere too much with our user’s existing workflow.
Based on the interviews conducted, the pain points stated below were the most common:
- Finding and editing out ums and ahs (these particular instances were the most prevalent)
- Detecting and removing long pauses
- Detecting and editing out excessive filler words
- Detecting and removing unexpected sounds that often come up when one is recording from home or sounds that come up during recording in general (dog bark, siren, cough, etc)
- The ability to detect and remove swear words
- The ability to locate specific keywords within the audio to use either for editing or marketing purposes
TOOLS USED
- Zoom – Sprint meetings and other relevant meetings
- Slack – Ongoing communication
- Trello – User story creation and creation of weekly sprint backlog, product backlog
- Miro – Research synthesizing, user story mapping and additional visual collaboration
- Figma – Design and collaboration on wireframes and prototypes
- Google Drive – Organization of project files
USER PROFILE
The product designer performed additional user research using Reddit and Facebook podcasting groups to help synthesize her findings. All of the research indicated that our proposed solution would be more suitable for amateur/hobbyist podcasters as opposed to more advance podcasters who tend to have more personalized workflows, budget for tech and often a different outlook on how and what to edit.
*For more information on the user persona, competitive analysis and the user’s journey, pls visit: http://solmasdesigns.com/podball-co-lab/
USER TESTING
The product designer and myself worked together on the user testing portion of the project. She developed the lo-fi and hi-fi prototypes. I reached out to podcasters to schedule user 20 min user testing sessions, where they were asked a few questions about their podcasting workflow. They then proceeded to go through the prototype as we observed how they interacted with it. We then asked them questions about the prototype itself and if they could see themselves using our product.
The first round of user testing revealed a lot about the potential for our product and how/if our idea would work within a podcaster’s existing editing workflow. The first prototype we tested was a simple, scaled back version of what we hoped to produce for our MVP, but it was enough to find out that users were excited about the product and saw it as having the potential to be a very useful tool. While there were lots of encouraging takeaways from round one of user testing, it also quickly became clear that the few lines of copy that explained the product would need to be expanded on with a dedicated landing page as one user was under the impression the product wouldn’t just locate the instances, but automate the edits as well.
Prototype images courtesy of http://solmasdesigns.com/podball-co-lab/
1st Round of User Testing
2nd Round of User Testing
The second round of user testing was encouraging as we had both the design and idea validated user after user. From both rounds of testing we received some ideas of how the product could evolve in the future including being used to help people improve their speech giving, or creating a plugin that works within a user’s chosen DAW (digital audio workstation).
THE OUTCOME AND FUTURE OF PODBALL
By the end of the 5-week timeline, we had a working MVP that was able to demonstrate all the features based on sample audio files created by the team. Due to the short timeline, the hi-fidelity designs haven’t been fully implemented, but the team plans to continue to work on Podball and navigate how to scale up from a simplified MVP to a more robust product that would include a database and more advanced tech that would require some budget.