Behind the scenes #7: What we learned from launching an MVP
Behind the scenes #7: What we learned from launching an MVP
...also instrumenting metrics, new podcast episodes and free access to our book for podcasters for a limited time
In this issue:
Get our book for free this weekend. Yep, just head to Amazon and get The Pragmatic Podcaster for Kindle free of charge until end of day Sunday.
Launching Metacast MVP in beta. What did we learn?
Should a startup invest in metrics early on? We think the answer is yes and are sharing how we did that for Metacast.
Latest podcast episodes. Episode 40 with our friends over at Tramline, a CI/CD platform for mobile apps, and episode 41 on applying to YC, MVP vs. MLP and a bunch of book and podcast recommendations! Listen to “Metacast: Behind the scenes” wherever you listen to podcasts.
If you know someone who will enjoy this, please forward them this email.
Behind the scenes, vol. 7
Newsletter archive: vol. 1, 2, 3, 4, 5, 6.
TLDR: We’re the team behind Metacast, the podcast app that is unlike any other. We’re in closed beta right now and are gearing up toward a public launch. Enter your email on our landing page metacast.app to receive an email when we launch (we won’t spam, we promise!)
This newsletter and our Behind the Scenes podcast is where we share our entrepreneurial journey with anyone who’s into storytelling about entrepreneurship and product development.
So, what have we been up to since the last newsletter?
Get our book for free this weekend Oct 27-29!
Earlier this year, we published a book The Pragmatic Podcaster: A Step-by-step Guide to Starting an Amazing Podcast. It’s currently available exclusively on Amazon and we’re running a promotion this weekend!
You can get a Kindle version completely free of charge Friday Oct 27 through Sunday Oct 29. There’s no catch but if you can provide a review on Amazon it’d mean a lot to us!
Launching an MVP in beta — what did we learn?
When we shipped closed beta of Metacast in August, we knew we were shipping a bare bones MVP, just like we would at AWS in our previous careers. The purpose of closed beta is to get something minimal in the hands of die hard fans who can provide feedback on the unique new capabilities, even if a lot of functionality and polish are still missing.
That’s exactly what we did.
The MVP of Metacast could do three simple things: search and follow a podcast, play an episode, and do the unique thing we’re banking on (our secret sauce). We’ve put all our effort into the differentiating feature while doing absolute bare minimum for the rest of the app.
Unlike AWS, we don’t have an established user base that we could pick from to participate in beta, so our beta users are mostly friends and family. Also, our product is a consumer product that attempts to replace users’ existing habits.
The latter proved to be a bit of a challenge for the MVP. People tried out the app and gave us feedback but most didn’t stick with it on a habitual basis. Without the foundational “table stakes” features, they couldn’t replace Apple Podcasts or Spotify with Metacast.
The term “table stakes” comes from poker and refers to the amount of money a player must bring to have a seat at the table. Similarly, in product development, table stakes features are those you must have in order for customers to even consider your product.
We launched the MVP without downloads and some beta users dismissed our app right away because they live abroad and don’t have a stable internet on their phone. We didn’t have playlists, so some users couldn’t use the app because it doesn’t plug into their walking/hiking routine. We didn’t have episode search, so some users couldn’t find what they needed and went back to Apple Podcasts.
Because of the missing table stakes functionality, some of our users never even got to the point where our differentiating feature was useful to them. We didn’t bring enough to the table to be able to play the game of who gets to be the user’s podcast app of choice.
This said, by shipping early and doing UX research with those users, we received great inputs on what the most important table stakes features are. We’re now hard at work to build those and launch an MLP (minimal lovable product) publicly.
It’s hard to find the balance between table stakes and differentiating features when you’re crunched for resources and time. If we started with table stakes first, we’d spend months simply copying the status quo. We front-loaded differentiators, test-drove our tech stack, and are now catching up on the basics.
If we were to do it again, we’d probably do exactly the same.
Should a startup invest in metrics early on?
I cut my analytics teeth at DHL where I spent five years doing business intelligence for DHL’s logistics operations. We had all data we needed for any decision. I took the BI role at DHL when I was 22, so pretty much from the beginning of my professional career I knew that data just had to be there.
Arnab’s and my very first project together back in 2015 was an internal analytics platform for AWS Console. It’s hard to believe but back then AWS had no idea what people were doing in its UI. We fixed that by building a platform code-named after a character in Asimov’s Foundation series.
In other words, we love data.
It doesn’t matter what size of the team you have. Investing in metrics is almost always worthwhile, otherwise you’re flying blind. It’s cheaper to instrument metrics right away, especially, if you already know how to do it, than to do it retroactively in a production system. Oh, and if you don’t do it right away, you can keep punting on metrics in favor of feature work (similar to tech debt) until you can’t steer the ship without data anymore.
Here at Metacast, we knew we wanted to have analytics right away, but we also wanted to be pragmatic, i.e. not to spend too much time on instrumenting telemetry and maintaining a data warehouse. Neither did we want to spend too much money.
We use Firebase, which provides a Google Analytics (GA) integration out of the box. That was great but GA doesn’t give you the ability to use events’ metadata. For example, we can see how many users played how many episodes, but specific episode and podcast titles are not accessible through GA’s interface. And of course, we can’t join events data in GA with our own data sources, like the tables that store podcast and episode info, playlists, etc.
In my time at Google, I really came to love BigQuery. It’s an amazing product (dear Google, please do not be evil and do not deprecate BQ!) Luckily, Google Analytics has an integration with BigQuery — you can simply stream GA events to a BigQuery table. Also, Firestore has an extension to stream data to BigQuery.
We set everything up in a matter of a few hours. First of all, it was really easy. Yeah, we had to look up some stuff on StackOverflow but it was minor. It worked like a charm and in just half a day or so we had all the data we need in BigQuery. As a bonus, you can connect any Google Sheet to BigQuery as a table updated in real-time. My mind was blown yet again. It’s awesome!
Now, we needed to visualize the data in a dashboard. Google has great internal tools for data visualization (like, they’re the best I’ve ever worked with, seriously kick-ass!) and I was hoping we’d get the same thing from Google Data Studio, which was rebranded as Looker Studio.
Apparently, there’s a “good” version of Looker that costs $5k per month — I don’t know what’s included… We can’t afford it, so I stopped my research immediately when I saw the price tag.
Then, I discovered Looker Studio, a free version of the platform. It’s really underwhelming compared to Google’s internal tools but it gets the basic job done for no cost, so we’re using it to generate our dashboards for now.
One may ask — are you guys wasting your time by investing in metrics too early?
The answer is an emphatic no.
Even though we’re in closed beta, metrics allowed us to see who uses the app, what they’re doing, what they’re listening to, and we were able to tailor our feedback outreaches to specific users. At the time we launch publicly, we’ll have all telemetry we need in place, so we can make more informed product, business, and tech decisions.
P.S. Being the nerds we are, we also started exploring the data we have. Did you know that Dan Carlin’s Hardcore History podcast episodes are on average 4.7 hours long? That’s twice the length of Lex Fridman’s, which I expected to have the longest episodes in the catalog (note: we’ve not imported all podcasts in existence into our platform yet, we’ve got just a sample of a few hundred shows right now).
Latest podcast episodes
Ep. 41: Differentiating vs. table-stakes features, MLP vs. MVP, YC application
What features do you build first - table stakes or what makes you differentiated? What's the difference between an MVP and an MLP? Is it worth applying to YC? ...and a few recommendations of books and podcasts that we're into these days.
Listen on Apple Podcasts, Spotify, or watch on YouTube.
Metacast Ep. 40: Automating mobile app releases with Tramline founders
A conversation with founders of Tramline, a CI/CD platform for mobile apps that we use for releasing Metacast. We talked about release standards (or lack thereof) for mobile and how Tramline solves this problem. We also dug into the founding story of the company, how they sold to first customers, fundraising from angels, and a few more topics.
Listen on Apple Podcasts, Spotify, or YouTube (no video for this one).
Coming up next
Episode 42 (next week) is going to be with Jennie, our Senior Software Engineer! It’s a follow-up to episode 17 where Jennie (not yet part of Metacast) shared her journey from a teacher to a Senior SDE at AWS (where she was part of Arnab’s and my team).
Support our journey
There are a few ways you can support our nascent business.
Subscribe to this newsletter
Forward this email or our podcast to a friend
Buy The Pragmatic Podcaster book or gift it to someone
Buy a t-shirt on our merch store
Ciao!