Who is Podscan’s ideal customer? Who should I sell and market to? And how can I find out who could be ideal, and what choices do I have to make when whittling down that list?
Today, I’ll dive into the Ideal Customer Profile for my recently-funded yet still very-much owner-operated software business Podscan.
Let’s start with where I am (in terms of understanding my customers). Honestly, I wouldn’t be anywhere had I not talked to dozens of them over the last few weeks. When I set up my transactional email systems on ConvertKit, I had an epiphany: the welcome email is the very first time I get to correspond with who are likely the very best people to talk to: early adopters, willing to give a new software tool a shot. How could I not want to talk to them directly?
So I added a Calendly link with a wide-open availability window to every single email I’d send to my trial users. I even called it something like “early-adopters-are-the-best” to show my users just how much I valued their input. From that, I received dozens of bookings, and in these calls, I met a wide variety of prospective users.
Talking to People
Experience this article as a podcast, a YouTube show, or as a newsletter:
I found that they fall into a few significant groups.
The users with the clearest Job-to-be-Done were virtual assistants and marketing people who were tasked with booking podcast appearances for their bosses. I got the most “your tool saves me so much time and hassle” vibes from this very well-defined group. They also had the most precise insights into what they needed to get their jobs done: when Podscan didn’t provide the right data or enough of it, they would quickly tell me what they need and where they’d usually source it. Ultimately, this customer group reminded me the most of my customers back when we were running FeedbackPanda, an Online Teacher Productivity SaaS. These were people with a task, very little time, and a drive to use good software for good purposes.
That last part was equally apparent in another group of prospects I talked to: people working on software products in the podcasting space that were interested in adding observability and transcript access to their own products. In many ways, that was a completely distinct group: mostly technical or semi-technical founders with a vested interest in access to a massive database of podcast information not for their own research needs but the needs of their customers. Where virtual assistants were the end user of the browser-centric alerting and search features of Podscan, these founder customers would only ever really need the API-based features (which, of course, include alerts and search). They’d leverage the whole Podscan system almost as a white-label solution.
There was a third group, which I’d call “marketers and salespeople sifting through historical data for prospects.” Like the VAs, they’d find a lot of good use in the browser part of the Podscan experience, but were less intensely excited about the capacities of the product. For this group, a different “data enrichment” strategy will be needed — I can see a “ask any question of any podcast and get tabular AI-powered results” kind of module be something they’d find more alluring than keyword alerts or full-text search. I’m planning to build this eventually, but this will take some work.
So, between virtual assistants, founders, and marketers, what do I chose? Who should I focus on, and what should I ignore?
The 3 Assumptions
Fortunately, I’m running a calm business. And a calm business runs best when there is a framework for decision-making in place. I’ll share that with you now.
I have a rule for choosing an Ideal Customer profile which is based on three assumptions:
- ICPs are temporary
- ICPs are incomplete
- ICPs are binding
These fundamental choices are intentionally conflicting. How can something be binding but temporary? How can something ideal be incomplete?
Well, the reality of entrepreneurship is messy, and a framework to keep things calm has to account for this. In my case, I want my decision of an ICP to be something I can commit to. Let’s dive into what this means for my ICP choice:
When ICPs are temporary, I can set a begin and an end date for making them the focus of my business development efforts.
When ICPs are incomplete, I can update assumptions about the nature and the behavior of my best customers as I examine and explore them.
When ICPs are binding, I have to restrain my desire to serve other verticals or placate them into buying a subscription by creating features that distract me from my ICP.
When ICPS are temporary, incomplete, and binding at the same time, I can make the ICP I chose a time-limited yet-to-be-fully-explored target that gets my undivided attention.
And that’s just what I need right now, at the early stages of my business-building efforts. Something that’s clear enough to instruct my actions without being too rigid to ultimately change.
Applying the 3 Assumptions to Podscan
With the recent bootstrapper-compatible funding I managed to get, Podscan will be able to operate financially soundly for at least a year, very likely much longer — it’s already nearing $1k MRR these days. Once the massive backlog of podcasts is ingested, costs will drop significantly. So the runway is secured. How long should I focus on a single customer segment, then?
When considering this, a few numbers float around in my head. A year? 3 months? Maybe 6? What matters here is the velocity of that market. If I were to make founders my ICP, 3 months would suffice. That’s more than enough time to deal with people who, like me, live and breathe building products. Focusing on the needs of a group that is so accessible and willing to collaborate is easy.
It’s definitely easier than focusing on virtual assistants, because I don’t even quite know where to find them (other than in my email inbox where hundreds of them try to place their bosses on my podcast). If I were to make them my ICP, I’d very likely give it half a year or more, just to be able to find the right communities, forums, and marketing avenues.
No matter who makes it to ICP status, I am well-aware that I don’t know enough about them just yet. Particularly with assistants, I would have to intensify my call frequency just to really understand their workflow, the inputs, the outputs, and the multi-layered nature of their jobs to be done. Founders are often quite self-reflected about this, so that information takes less digging to unearth. Marketers and salespeople might present a discovery challenge here, too.
But I know that I have to make a choice. Right now, I am catering to everyone’s needs.
A Choice(?)
But maybe, that’s actually not much more than a problem of perspective.
After all, all work I do on the data platform side of things translates into more reliable and extensive features for browser-based customers. It’s not the same the other way around. If I work for a month on a feature for a specific end user, the background logic and data implementation might be useful for someone using the data platform. But if I build a generalized but specifically implementable data platform extension, it will be useful to anyone using the platform and to my own custom feature-building efforts.
An example here would be the capacity to have a pre-defined AI-based data extraction system for every podcast episode out there. If I build this specifically for my podcast guest booking customers, I end up with a very specific system that likely extracts who was on which show, what their main topics were, what URLs and products they plugged, and similar points. But if I were to build a more general module that could be configured with an arbitrary set of questions and data expectations, the system could easily create a bullet-point list of who was on which show just as much as it could return a JSON string containing every single mention of a certain industrial chemical, what time it was mentioned, who mentioned it, and if they are likely a prospect to sell safety equipment to. The generalized system will allow for the specific ones much more easily than the other way around.
This leaves me in a bit of a pickle. On the one hand, I have a well-defined customer with a clear Job-to-be-done. On the other hand I have a more varied customer segment that, when prioritized, would facilitate better features for the first customer segment (which, of course, I would then also have to build.)
Hm.
A Choice!
It’s a good thing I’m an indie hacker. Even with the Calm Company funding, I still get to make my own choices without outside interference.
So let’s make a choice.
I got runway, I have an “if this works, that will work too” situation with the data platform. And I know that the more podcast data (and any additional information such as podcast rankings, audience size, and the like) I have, the more valuable the platform will be to a vast host of prospects.
For the next 6 months, I will focus on building data platform features while also making sure that I do reference implementations of said features that will benefit my podcast guest booking virtual assistant crowd. Let’s bake the cake, have the cake, and nibble on it a bit.
If you think that’s crazy, let me know. If you agree with the approach, let me know too. I value the opinion of my fellow founders, creators, podcasters, and anyone who trusts their gut. Send an email to arvid@podscan.fm, leave a DM on Twitter, or find me at MicroConf US in Atlanta next week!
