Dear founder,
I ran into a pretty substantial question this week.
Am I working in my business, or am I working on my business? I've been spending so much time building features, talking to customers, implementing fixes, dealing with infrastructure problems, and even trying to upgrade the product design.
All of this is still working in the business – it's operational work in the trenches.
It's taking small steps, looking at the ground, instead of dreaming of giant leaps while gazing at the stars.
🎧 Listen to this on my podcast.
I shouldn't be surprised. Podscan.fm is still on its way to product-market fit. I can see it on the horizon; there's definitely something there that reliably creates joy and value perception for my customers. But that doesn't mean I should spend all my time implementing features and adding value.
Today, I'll do some founder brainstorming. And you'll be right in the middle of that storm, like it or not!
As they say, entrepreneurship is always a balance between the mission, the vision, and the execution needed to make them both happen. I've been focusing a lot on the mission of getting to product-market fit, building Podscan into a feature-rich application that people can use. But I think I've neglected the vision a bit.
So, I'd like to take some time to share my approach to looking at what Podscan could eventually turn into on a bigger scale, without losing sight of the reality of what it is right now and how much effort will be required to get from where we are today to where I want to be.
One of the most important parts is to look at the initial scope of the product and check in with myself. Is trying to extract information from all podcasts everywhere enough? Or is it too much? Or is it just right – a Goldilocks moment?
Over the last couple of weeks, I've seen people comment that having searchable insights into millions of podcasts is great, but they'd also like X – TikTok, YouTube, or anything with an audio component. These are mostly people brainstorming, not actual paying customers. This makes me think that my current scope might actually be good. I didn't under-provision it; I gave it an audacious goal to stay on top of all podcasts released every single day.
I really should consider conducting a survey among my current users to gauge their interest in expanding beyond podcasts. This could provide valuable data to inform my decision-making process — and what I offer here what ultimately informs their budget.
What I'm noticing is that my initial breakout product, the idea of Podscan being a notification, summary and tagging tool, has potential beyond what I initially imagined. As I built summarization features, I almost by happenstance implemented "keywords." The time-stamped categories and topics condensed into individual words or small groups of words can be extremely valuable in an aggregated fashion. It's effectively a database of millions of small, trackable trends and topics.
So, what Podscan has, and what I think it can provide way beyond what it currently does with real-time monitoring and search, is trend forecasting and trend analysis. I joked recently that right now, Podscan is Google Alerts for podcasts. I want Podscan to be Google for podcasts.
This gets me thinking: what else could Podscan be? What information is in all of these episodes, in all of these transcripts and between them, that might be useful beyond their text format? The more I think about it, the more I realize that maybe, just like when I started Podscan, I don't have to come up with these ideas. I don't have to be the person to know precisely what the tool is going to be used for.
It's probably sufficient for me to provide the underlying information. Even at this point, somebody could use the API to pull all the transcripts and run a summarization on them. It would be quite expensive, but they could. I could take it all and summarize it and extract topics and create a trend tool. It's just that I already have it, and I do sell the information to a point where, if somebody were to take everything, it would be quite costly to get all this information.
So, it is hoarding the data that will provide the value. The question is, what can be built on top of this? And do I want to build it, or do I still want to be providing the data layer?
In a recent conversation on Twitter, somebody suggested I license all of this information to companies who train AIs. That's something I hadn't thought of at all. I've been thinking of selling monthly subscriptions to individuals, brands, or agencies to use Podscan for data analysis and alerting features. But I could well build a full transcript export, probably hundreds of gigabytes at this point, and sell this to big data consumers interested in having access to transcripts almost in real-time.
The more I think about this, the more I understand that all the things I could potentially build are mere abstractions, different sets of lenses through which to look at the underlying data. Depending on the effort I put into it and the systems I build around it, like for summarization, I had to set up new AI systems on top of my transcription systems. But the transcription itself is very cheap to operate, and anything on top of that might be questionable when it comes to whether it's worth it or not.
Maybe I can explore partnerships with AI research institutions or companies. The data I already have could be valuable for training language models specific to podcast content, and that might open up new revenue streams for me and research opportunities for them.
So, I'm at a crossroads. Do I keep building features and focus on working in the business, implementing these things and coming up with new ideas and building new interfaces to show them? Or is it more important to take a step back and examine if there's even a need for that, or if other people would be willing to pay me more than I could make in potential new customers to just access the data and build it themselves?
Do I want to build the tool, or do I want to enable other people to build tools? I feel that it's so much more exciting to build something that people can reliably use to facilitate their own experiments, rather than building it for them. Building it for them is easier to communicate and easier for them to pay for, but it's also more work and keeps me from exploring the full potential of what Podscan is.
Recently, I was introduced to the concept of data fidelity – the idea of making sure that data is as accurate, timely, and complete as possible. The more effort I've been putting into tracking the quality of my data, the more I notice that with every slight improvement in data fidelity in the backend system, the fewer confused emails I get from my customers.
How about I implement a data quality dashboard for my users, showing metrics like accuracy rates, completeness, and timeliness. This likely unexpected level of transparency could build trust and differentiate Podscan in the market where usually, internal metrics are quite opaque and secretly guarded.
So when I think about the long-term perspective of Podscan, I've stepped back from trying to figure out every single feature along the way. I've moved into understanding better what quality data and quality API results actually look like. It's a far cry from what I initially considered Podscan to be. Initially, I wanted it to be a marketing tool, but it's turning out to be a data platform, which is wildly different. The marketing tool is just the first tool built on the data platform, and more tools are being built every single day.
My long-term focus will be on understanding what makes good data, tracking the improvement and maybe regression of data quality over time, preventing it from happening, making it better, and understanding how this could potentially move as a business.
When I think about Podscan as an operation, not just as a tool but as a business, I want it to be something that is extremely stable. The podcasting ecosystem is a pretty good baseline for this. Everything is built on RSS feeds and simple file uploads and downloads. There's nothing proprietary about this. It's all very open, well-standardized, and well-supported.
But it is enough?
I've been thinking about integrating TikTok or YouTube, and it's not that complicated technically. Podscan is built as a flexible platform. I could very easily pull as many transcripts from YouTube as I want. But do I want that? Do I want to support proprietary platforms where I don't even know who holds the rights to the transcripts?
The benefit that podcasting has is that it's a widely distributed system. Podcasting is a misnomer; it's many different platforms that all kind of glue together through open standards. I kind of like that, and I want to stay there. There's still a decade-old history that I'm working through, and it's a growing segment with a lot of people releasing new podcasts and becoming more professional and successful at their shows.
I think I will have to confront the thought that I will have to really reposition Podscan. It's scary to think that it will probably be hard to do because right now, it's very easy to say, "Hey, if you have a brand, check it out. This is what finds your brand and notifies you of mentions." A data platform is harder to sell.
What I'm currently working through is: am I actually running two businesses at the same time? Is there Podscan, the search and alert tool, and then an underlying data provider that should be a different entity or product? Should I divest from having it all integrated into one platform and present the API side of things, the access to the data, as its own standalone product with standalone pricing?
One option is to create a separate brand for your data platform, positioning it as an enterprise B2B solution while maintaining Podscan as a smaller B2B product, almost in the B2C space. This could allow for more focused marketing and development strategies for each offering.
But it would also double my workload.
It's noticeable to me that the most approachable and interested people over the last couple of months have been those building systems on top of the API. They've been the best at communicating and describing what they want because they have a clear vision of the product they want to build. They generally also have the best understanding of technical feasibility and expectations around how quickly new features can be implemented.
These are, in a way, enterprise customers. They have an understanding of what tools can do and how they should be integrated. The way they use customer service is more issue-focused and not bug or problem-focused. It's focused on a plan, and if there are challenges along the way, they're always in the context of trying to reach a goal.
I would like to work more with these kinds of people. So yeah, that's what I'm currently thinking about – the tension between taking small steps now to improve Podscan as it is and planning for giant leaps to transform it into a comprehensive data platform for the future.
The wonderful thing about long-term planning —which often enough is also the reason it's so frustrating— is that things change over time. But setting goals and getting clarity around what you want your business to look like in a few years is always worth exploring.
And as a final aside, I'll also draft a company org chart for the Podscan of 2029. I learned this in Michael E. Gerber's great book "The E-Myth" — draw up the future version of your business, with a few dozen employees. That will help me understand what kind of work needs to be done to get to that point one fine day.
Lots of big picture thinking for this week. I'll share the results in one of the next episodes here.
I'll share a few updates about my SaaS on the pod, and if you want to track your brand mentions on podcasts, please check out podscan.fm — and tell your friends!
Thank you for reading this week's essay edition of The Bootstrapped Founder. Did you enjoy it? If so, please spread the word and share this issue on Twitter.
If you want to reach tens of thousands of creators, makers, and dreamers, you can apply to sponsor an episode of this newsletter. Or just reply to this email!
No comments:
Post a Comment