“Working In” vs “Working On” the Business

Download MP3
Arvid:

Like, maybe the data platform Org Chart is gonna be almost gonna feel like a punishment in terms of the workload that it has or maybe it's quite liberating and I wanna do all of these things. Hey. I'm Arvid, and you're listening to the Bootstrap founder. I ran into a pretty substantial question this week. Am I working in my business or am I working on my business?

Arvid:

I've been spending so much time building features, talking to my customers, implementing fixes, and dealing with infrastructure problems, and even trying to upgrade the product design. And 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. I shouldn't be surprised.

Arvid:

PodScan is still on its way to product market fit at this point. 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. There's more.

Arvid:

Right? So 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. And I think I've been focusing a lot on the mission of getting to product market fit, building PodScan into this feature rich application that people can actually use. But I think I've neglected the vision a little.

Arvid:

So I 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 it from where we are today to where I want it to be. One of the most important parts is to look at the initial scope of the product and check-in with myself at this point. Is trying to extract information from all podcasts everywhere still enough? Maybe it's too much? Or is it just right?

Arvid:

Is it this Goldilocks moment? Well, over the last couple of weeks, I've seen a lot of people comment that having searchable insights into millions of podcasts is great and super usable, but they would also like x. Could be TikTok or YouTube or anything with an audio component. And I looked at these communications, these tweets, and these messages, and I found that these are mostly people brainstorming, not actual paying customers. And this makes me think that my current scope might actually be a good choice.

Arvid:

I don't think I under provisioned it. I gave it an audacious goal to stay on top of all podcasts released every single day, but that is already enough. And I think I should probably consider conducting a survey among my customers or my current users even to gauge their interest in expanding beyond podcasts. Because these messages here and there, that's great, but having some actual data, valuable data that could inform my decision making process here and then allow me to offer other things or more things should they be needed, and that kind of stuff ultimately informs the budget of my customers. But what I currently have and when I look at my initial breakout product, I find that I'm noticing that the idea of PodScan being this notification and summary and tagging tool has potential right now beyond what I initially imagined.

Arvid:

Because I built summarization features just to be able to take a transcript and summarize it into a sentence or a couple sentences. And almost by happenstance at the same time, I implemented summary keywords, kind of timestamp categories and topics condensed into individual words or small groups of words. And I think these can be extremely valuable in an aggregated fashion. That's something I didn't initially intend to have, it just happened. It's effectively now a database of millions of small trackable trends and topics.

Arvid:

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 when I was, asked by a judge at the AI launch demo day that Paddle organized what I think the future of PodScan might be. And I I said, right now, PodScan is Google alerts for podcasts, but I want PodScan to be Google for podcasts. And I think I actually got there or I'm getting there, like step by step. Like, just full time search, that's what Google search is, and maybe having trends that could be what Google trends is.

Arvid:

I could just put more and more of these particular features into the platform. And that gets me thinking, what else could PodScan be? What information is in all of these episodes, all these transcripts in between them that might be useful beyond their text format. And the more I think about this, the more I realized that maybe, just like when I started PodScan, I don't have to build this. I don't have to come up with all these specific ideas.

Arvid:

I don't have to be the person to know precisely what the tool is going to be used for. I think it's probably sufficient for me to just provide the underlying information well enough. Even at this point, somebody could use the API to pull all the transcripts and then run summarization on them, and then extract trends from them, and it would be quite expensive for them, but they could do that. I could take it all and summarize it and extract topics and create a trend tool. It's just that I already have the data, and I do sell the information to a point where if somebody were to take everything, it would be quite costly to get all of this information.

Arvid:

But the question is, should I build this or should I just facilitate it? And I'm realizing that hoarding the data or providing the data is the thing that provides the most value to myself, to the business, and to the customers of the business. Question here, what can be built on top of this? And do I wanna build it, or do I still wanna be providing the data layer? Just the data layer.

Arvid:

And in a recent conversation on Twitter, somebody suggested that I should just 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, and agencies that are using PodScan for data analysis and the alerting features. But I could well build a full transcript export, probably 100 of gigabytes at this point, and sell the whole thing to big data consumers interested in having access to transcripts almost in real time. And the more I think about this, the more I understand that all the things I could potentially build are mere abstractions.

Arvid:

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, where I had to set up a couple AI systems that work in tandem with my transcription systems, but the transcription itself is always cheap to operate for me. And anything on top of that actually might be questionable when it comes to whether it's worth it or not. Because somebody else might have a better system to just take the raw data and turn it into what they can use best. Maybe I should explore partnerships here with AI research institutions or companies because the data I already have could be valuable for training their language models, specifics to podcast content or specific things, fields in the podcasting world, and that might open up new revenue streams for me and research opportunities for them.

Arvid:

And it's quite likely that they already have a GPU cluster somewhere for these things to run on that I don't need to provide. Maybe a partnership is a good idea too. So in just thinking about these long term potential ideas, all of a sudden, I see that I've been really really focused on these tiny minute details in the coding up another UI layer for a certain thing, where I probably should have been thinking about, you know, very different things, much broader things. So I'm at a crossroads here. Do I keep building features and focus on working in the business, implementing all these things and coming up with new ideas and building new interfaces to show them to get to this product market fit I'm chasing?

Arvid:

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 by just accessing the data and building it themselves. Do I wanna build a tool, or do I wanna 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 just building it for them. I think I have to step out of this frame of mind where I'm the one doing it for people.

Arvid:

People can very well build things by themselves and probably better than I can envision it, no matter how much I talk to them. Building it for them is easier to communicate and easier for them to pay for though. Right? Because if I give them a tangible product, they can give me tangible money. Giving them the potential of a product often leads to them just having the potential to pay me for it.

Arvid:

So, yeah, it's more work and keeps me from exploring the full potential of what PodScan is to just build things all the time. And recently, also in a conversation with a person on Twitter, I was introduced to the concept of data fidelity. The idea of making sure that data is as accurate and timely and complete as possible. The more effort I've been putting into tracking the quality of my data, the more I actually noticed that with every slight improvement in data fidelity in the back end system, in my transcription layer, in my extraction layer, the fewer confused emails I get from my customers. So maybe I should lean into that more instead of looking at how can I make this data immediately usable?

Arvid:

I should look more into how can I make sure that the quality of the data improves every single day? Right now, I'm roughly at 98 percent accuracy when it comes to transcription quality. 97.5, 98, it kinda oscillates from day to day. It depends on how many episodes are released that are easy to transcribe, and then the hard ones kind of pull that number down. But if I can even increase this percentage by just half a percent, that means out of the 2% that would have been confusing to people, now it's just 1.5% and that is I think, what, like 4 25% production, something like this, which also means that I don't get 4 emails from customers, I get 3, and that's quite significant.

Arvid:

Right? So maybe I should lean into making this more transparent, this number, and just showing how it improves over time. How about I implement a data quality dashboard for my users, showing metrics like accuracy rates, completeness, timeliness, everything that data fidelity is about? It's likely an unexpected level of transparency, and it could build trust and differentiate PodScan in a market where usually internal metrics like this are quite opaque and secretly guarded. Like, people really keep these things behind locked doors because they don't think people need to know.

Arvid:

So, yeah, that's that's something I'm thinking about. Data fidelity is becoming a much much more relevant thing for me right now than implementing specific user interface features. Because I know that with 30,000 episodes coming in every day, I mean, I transcribe roughly a 100,000 episodes a day. It's just that there's, like, 10,000 episodes that are released every single day that I give the highest potential quality to, and then there's like 10 k that gets some kind of mid quality, and then I dismiss another 10 k that is probably like foreign language stuff that I currently don't integrate into the system. And then there's 70,000, that's just backlog.

Arvid:

That's historical data from couple months past, podcast episodes from 2013, 2023, anywhere in between. So 70,000 of those make it into the system every day as well. And the better the quality is for every single one of them, the more likely search is accurate, the more likely alerts are really accurate to what people really want, and the better the overall product. So I'm thinking more about Fidelity here. And when I look at the long term perspective of PodScan, I think I'm stepping back more and more from trying to figure out every single feature along the way.

Arvid:

I've moved into understanding better what quality data and quality API results actually look like, and I think it's a far cry from what I initially consider PodScan to be. Initially, I think I wanted it to be a marketing tool for my own purposes, 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 either by me, if I can help building stuff, or by other people that are paying for access to the platform and building their own tools and workflows on it. My long term focus will be on understanding what makes good data. Tracking the improvement and maybe regression of data quality over time and then preventing the regression from happening if I can, making everything better, and understanding how this could potentially move as a business into what direction it should go.

Arvid:

So when I think about PodScan, not just as a product, but as an operation, I want it to be something that is very stable like the business itself. And I think the podcasting ecosystem is a pretty good baseline for this. Everything is built on open standards. RSS feeds, just file uploads, file downloads. There's nothing proprietary about this.

Arvid:

It's all very open, well standardized, and well supported. And it kinda gets me back to the question, is it enough? Well, we talked about this earlier. I've been thinking about integrating TikTok or YouTube, and it's not that complicated technically. PodScan is already built as a flexible platform, and I could very easily pull all these transcripts from YouTube as I would want.

Arvid:

But do I want that? Do I wanna support these proprietary platforms where I don't even know who holds the rights to these transcripts or what I can really do with them? The benefit that podcasting has is that it's a widely distributed system. Podcasting is a misnomer really. It's many different platforms that all kind of glue together through open standards.

Arvid:

It's it's what I like and I wanna stay here. There's still a decade old history that I'm working through right now and it's a growing segment, podcasting, with a lot of people releasing new shows and becoming more professional and successful at their current shows over time. I think I will have to confront the thought that I will have to really reposition PodScan though. It's scary to think that it will probably be hard to do this because right now it's very easy to say, hey, if you have a brand, check it out. This is a tool that finds your brand and notifies you of mentions.

Arvid:

I think once I move more into this whole data platform world, it's harder to sell. What I'm currently working through is, am I actually running 2 businesses at the same time here? Is there PodScan, the search and alert tool, and then this underlying data provider that should be a different entity or product? Should I divest from having it all integrated into one platform and then present just the API side of things, the access to the data as its standalone product with standalone pricing? Probably.

Arvid:

There are many, many ideas here that I have, and I'm just gonna share them because I wanna explore them here. One option is to create a separate brand for the data platform, positioning it as an enterprise b to b solution, while maintaining PodScan, the current thing as a smaller b to b product almost in the b to c space. This could allow me to do more focused marketing and development strategies for each of them, but it would also double my workload. And it's noticeable to me that the most approachable and interested people over the last couple of months that I had conversations with have been those building systems on top of the API. They've been the best at communicating and describing what they want because they actually have a clear vision of the product that they wanna build, unlike people who just wanna check for their name and see where they maybe get mentioned.

Arvid:

If there's an agency or a business trying to implement PodScan, they know exactly what they need, and they generally also have the best understanding of technical feasibility and expectations around how quickly new features can be implemented. So these are kind of enterprise y customers. They may not be as big as an enterprise business, but they have the approach that an enterprise customer would have. They have this understanding of what tools can do and how they should be integrated, how critical they are, and, you know, what expectations can be had around them. The way they use customer service is way more issue focused, like, on the actual challenge that they have in their business and not bug or problem focused when it comes to Pod scan.

Arvid:

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 specific goal that they can actually voice and describe. And I think I would like to work more with these kinds of people. Yeah. That's why I'm at least currently thinking about this tension between taking all these small steps now to improve PodScan as it is and then planning for these giant leaps and shifts in who I wanna talk to to transform PodScan into this comprehensive data platform for the future.

Arvid:

The wonderful thing about long term planning like this, which often enough is also the reason it's so frustrating, is that things change over time. But I think setting goals and getting some kind of clarity around what I want in my business and what I want it to look like in a few years is always worth exploring. And finally, as a little aside here, I think I will also draft a company org chart for the PodScan of 2029. I learned about this in Michael e Gerber's great book, the E Myth, that draw up this future version of your business. Like a big org chart with all all kinds of positions and many, many employees, and then put your name next to all of them.

Arvid:

And if you have cofounders, you split it up. That's what Danielle and I did back in Power Feedback Panda days. And that will help me understand what kind of work needs to be done to get to that point one fine day, and to understand all the nuance, little jobs that need to be done in this business, all the roles that need to be filled. And maybe I will also see if I like it or if I don't. Like maybe the data platform Org Chart is gonna be almost gonna feel like a punishment in terms of the workload that it has, or maybe it's quite liberating and I wanna do all of these things.

Arvid:

I will see once I draw it up. And that's it for today. Thank you so much for listening to the Booster Founder. You can find me on Twitter at abitkahl, a I v I d k e h l. You'll find my books on my Twitter course there too.

Arvid:

If you wanna support me in this show, please tell everyone you know about PodScan dot fm and leave a rating and a review by going to rate this podcast.com/founder. It makes a massive difference if you show up there, because then the podcast will show up in other people's feeds, and any of this will truly help the show. Thank you so much for listening, and have a wonderful day. Bye bye.

Creators and Guests

Arvid Kahl
Host
Arvid Kahl
Empowering founders with kindness. Building in Public. Sold my SaaS FeedbackPanda for life-changing $ in 2019, now sharing my journey & what I learned.
“Working In” vs “Working On” the Business
Broadcast by