There are many risks and advantages to being your own customer. Today, I want to talk about how I am doing this with my current business, PermanentLink, and how Danielle and I did this with our previous company FeedbackPanda.
So, what do I mean by being customer #1? I’m talking about using your own product to solve your own problems, scratching your own itch. Building your own solution. If you center your business around a need that you feel in your own life, you’re customer number one.
Let’s start with the benefits of scratching your own itch.
One of the most beneficial consequences of being your own customer is knowing when your product is good enough. It’s much easier to escape analysis paralysis when you solve your own problem. Once your product solves that problem sufficiently, you have a working prototype.
You can quickly determine if any given feature belongs in the core product or if it is a nice-to-have. If you need it, right now and right here, it’s a core feature. If you think you might use this at some point, it’s not.
This makes early feature prioritization easy. Instead of having to guess or assume whether your audience will welcome one particular feature over another, you will have a sense of what is most important to get done now. “Now” is the key concept here. If you want to divide your features into core and auxiliary feature groups, you can rank them by how impactful they are on solving your problem right now. I’ve written about the DIE and the RICE feature prioritization frameworks in Zero to Sold so that you can apply those concepts, but you don’t require something as elaborate in the beginning.
Knowing which features need to in the core feature group will just happen while you are using the early prototype of your product. When I started using PermanentLink to put stable and traceable links into Zero to Sold, I immediately ran into issues. I needed particular features, like custom domains or editing the URL of a link, right there and then. Without those core features, I could not have made any progress with my book. Other things, such as analytics, were not important at that point, so I deferred them. The only thing I implemented was to capture data that might one day be relevant for analytics. I left building the actual views and reports for a later day — because my workflow of getting those links in the book didn’t involve any analytics.
For every idea that came to my mind, I could immediately place it either into the core or auxiliary feature bucket. We did the exact same thing with FeedbackPanda, the EdTech SaaS that Danielle and I built and sold last year. Since she was an Online English Teacher and the product designer, anything that immediately helped her solve her problem with student feedback was a core feature. If it could shave off a few seconds off each feedback she needed to write, it was something we need to build quickly. If the feature idea would not have that desired effect, we’d put it on the roadmap but not build it immediately. The product got more efficient every day because we could immediately validate the impact a feature would have in the day-to-day workflow of Danielle’s teaching.
That’s the power of being part of your target audience. You don’t just understand what problems they have; you feel the pain yourself. You know how critical the problem you’re experiencing is because you also experience all the other problems in the field. Let’s say you’re trying to help hairdressers with your SaaS product. Unless you’ve ever spent a full day in a hair salon, you’re likely looking at an incomplete picture. You might be focussing on how they are interacting with their clients, but their real trouble could be how they source their hair coloring products. You never really know until you’ve been there.
In many industries, certain things are understood to be “unchangeable” or “just the way they are.” Your attempts to help might be viewed as an intrusion or as being too progressive. Being part of your audience allows you to innately understand where they drawn the line, how risk-averse they are, and how you can communicate new things in understandable terms. You’ll know the requirements and priorities of professionals in your niche. This is particularly interesting as many of these are often not explicit. Unwritten rules are hard to find unless someone tells you about them. And that is more likely to happen when you’re already part of the community that your audience is frequenting.
But being your own customer isn’t going to be the solution to all your problems. In fact, you run the risk of creating a few new problems along the way.
Two kinds of risk stand out to me: perception and attachment risk.
Perception risk is about a divergence between your anecdotal experience and the average experience of your target audience. Your workflow might not be the typical workflow, your problems — and, correspondingly, the solutions you seek — might be skewed toward your outlier perspective. For example, let’s take the hairdresser audience from earlier. If you are a hairdresser turned entrepreneur, your personal experience will drive your problem analysis. You will remember critical problems from your own salon, and you’ll extrapolate that into the general audience of other haircare professionals. But what if that problem you had with procuring hair coloring products only occurred because your vendor had a misconfiguration in their inventory software? You had to call them once a week, but other salons would never have to?
That’s why validation is still an essential part of building a business, even when you are your own customer. With PermanentLink, I try to invalidate my own assumptions that I built the process of writing and publishing a book. I ran into the link rot issue quite early, and that triggered my search for a solution. But do other writers run into this issue too? Do they run into it equally fast, or is this something that happens a few years down the road for most? Those are the questions that I needed to answer for myself, and those were the questions that I asked in my customer exploration calls. The results were interesting: they differed wildly between the authors I talked to. If I hadn’t checked for that, I would have built and positioned the product around my assumption that people are very aware of this problem.
I always assume that my experiences are anecdotal. That makes any theory of mine something that I try to actively invalidate by asking my prospective customers for their own experiences—and only then drawing conclusions.
That way, perception-based risk and the ever-present selection bias are mitigated quite a bit.
That leaves us with attachment risk. Over-identifying with the product and being overly attached to certain features is the most present risk in my entrepreneurial ventures. I have to work hard to stay away from making choices where avoiding losing work is the driving factor. Attachment to things that I have already built is a dangerous state of mind: it’s the sunk cost fallacy in action. If you think that what you already have right now needs to be protected, you’re actively sabotaging your business’s agility. If you learn something that requires you to pivot parts of your product, you should be open to making that change. Thinking that this would hurt your pride or dampen your accomplishment is self-defeating. But it happens to me all the time.
The problem here is that you’re doubly resistant to change: both as a customer and as a maker. The customer doesn’t want their workflow to change, and they don’t want to re-do the work that might come with a pivot. The maker doesn’t want their valuable time wasted, and they don’t want to re-evaluate their vision.
Being resistant to changing my vision is something that I have talked about before. Initially, I thought of PermanentLink as an infrastructure product, providing stable links to writers. But the more I spoke to authors, the more it became clear that their main goal is to make book sales, and any tool they use should facilitate or improve those sales. PermanentLink allows, for the first time ever in many writer’s lives, for a connection between the author and their reader outside of their book. I shouldn’t just ignore that, but I almost did, because it didn’t fit the “infrastructure product” paradigm. I identified too much with being an engineer. I forgot that every author is also a salesperson and a marketer. Being a good technician is not enough.
So, there we have it. Being your own first customer brings many advantages for your business, but it doesn’t come for free.
The cure to all of this is reflection and validation. To me, this often happens through the articles I write and the podcast episodes I record, just like this one. I get to reflect on my problems, and I get feedback from the founder community afterward. I recommend writing down your assumptions about your market, whether you’re your own customer or not. The mere act of writing creates a record of your understanding and a chance to share it with your customers in the shape of a question. No matter if you are solving your own problem or not, you will have to leave the building and talk to those you want to help. You will need their feedback to make sure you’re not restricting yourself with your anecdata.
As long as you consider any assumption you hold a theory, you can actively try to invalidate it. That way, you’ll keep biases at bay, and you’ll be able to build a product that doesn’t just serve you but also those who need it most: your audience.