Last February, we decided to create a weekly podcast called Bytes Over Bagels.
We did it to help promote and talk about all the amazing Chicago startups we were learning about, meeting, and working with in design and development projects. Last week, we published our 25th consecutive episode.
So, how'd we get there? The same way we create software. By going about it thru agile methodologies using small iterative cycles to continually test and get feedback on the product.
Once you're done skimming, there is a point to this at the bottom of the blog.
- Name it
- Make a logo
- 8 minute show
- Recorded on iPhone using iTalk recorder
- Static website with HTML5 single audio file player for just one episode
- Increase show to 20 minutes
- 1 Featured band from Chicago each show
- 2 Shure mics with stands
- 1 Audio Compressor
- Started taking semi-pro photos
- Static website with HTML5 audio player for multiple episodes
- Implement new UX pattern for handling more than 1 episode
- ITunes Podcast setup
- Added show sponsors
- 4 Shure mics
- 8-channel mixing board
- Increase show to 30 minutes
- Implement new UX pattern for scanning larger inventory of episodes
- Static mobile friendly layout
- Weekly Email newsletter add with template
- Increase show to 35 minutes
- Add show time scrubber to HTML5 audio player
- Added Vine videos of guests
- Hosted the Moxie Awards :)
- Pitch 32 tech startups (four per show): (#ChicagoTechStartupMadness)
- Add static bracket to homepage and vote via Twitter
- Added Instagram
- Added featured tweaks/quote from guests thru Twitter/Facebook
- UX to better skiimming of guests and guest names
- Built squarespace site for dynamic control over content by all team members
- Creating landing pages for all guests for better sharing
- Creating landing pages for Bracket, Newsletter, Sponsors
- Fully responsive layout
- Incorporated Social stream from twitter/facebook
- Created Youtube channel
- Transribing all interviews
- Incentivize newsletter signup
Like most entrepreneurs and startups, we had a grand vision for what this could be in the beginning. We could see the product as a whole and wanted to make it huge! That's still very important and speaks to having a shared focus for the product with the whole team.
That all said, their is a big takeaway from the most successful startups we've worked with and interviewed. Vision is still very important, but doesn't amount to anything without the will to stick your neck out and test it with minimal investment. Call it failing fast, or focus, or test-driven development, or agile. But I think it's common sense.
If people didn't listen to our first episode, why put the site on a CMS? Or why design a bunch of backstories on the guests? Why bother making the player more sophisticated or sending out emails to people who want to learn more? Or why bother investing in nice audio equipment? Or better designed pages and UX patterns?
So, what's the one thing your users need to love about your product? Can you test it with less investment? Can you GO to your customers in person? Does it really have to be fully baked for people to get excited and to begin supporting your vision?
We grew Bytes Over Bagels from seeds and were disciplined enough to not overwater it with features. This allowed us to better focus, ask the right questions and continue down the right path for our product. The next person coming along who wants to get into our space may come across our website and say, "Crap, we need all that!! I can see it!"
We are taught by the media to make the most of our BIG PRODUCT REVEAL. I'll bet you evaluate your competitors all the time or refer to the feature set of your favorite websites to help drive your product development. It's really really easy to think you need this baseline set of features to be successful. I'm here to tell you, you could never be more wrong and we have 25 interviews with Chicago's most successful entreprenaurs to prove it.
Bytes Over Bagels is just one example and I thought it was important to show what iterating 6 times in 6 months looks like for a product that was created to take over the world. :) Would you have started so small? Try shipping one great thing and continue to improve it until you run out of ways to improve it. Then add another feature.
There's one other important thing to mention here. It's not just about the feedback loops, or mitigating the risk in your time/monetary investment. It's about teaching you and your team about the value in shipping and how that will change the way you look at your product. The results can be eye opening that first moment you get user feedback. Or the first time your social reach doubles. The conversation changes from, "I think we should do this", to, "Based on what we've learned, we know we need to do this."
From Paper prototypes to WordPress sites, those who ship know:
Teaching yourself and your team simply how to ship, may be the most critical step to reaching the full potential of your grander vision.