Discover more from Entrepreneur Office Hours
Entrepreneur-ing In Public: Journey Log #13
The tempting pull of dangling revenue
I teach entrepreneurship at Duke and I’m publicly growing a company — Autopest — from $0 to $100k/year in revenue in order to help entrepreneurs better understanding the process of building startups. Learn more about my journey here.
Between my own travel schedule and the July 4th holiday, I haven’t shared an Autopest update in a couple weeks. In truth, I also haven’t worked on it as much as I could have because… well… vacation.
Despite my sporadic focus, three interesting customer-related things happened these past few weeks that are worth sharing because they’re good opportunities to teach about the kinds of things you can expect when you launch a startup.
The lessons begin with the two new customers I picked up while traveling. They both asked for new features. In addition, a third person request a feature that I decided not to build (and, as a result, he decided not to become a customer).
I’m sharing these stories because they’re similar to experiences you’ll likely encounter more than you’d expect when you launch a company. Specifically, people will often like what your product does, but they’ll want unique tweaks and updates to fit their specific needs.
In the early days of building a startup, you’ll be so desperate for customers that you’ll be tempted to build whatever they want. But should you?
Let’s explore some of the scenarios…
Thanks for reading about my journey growing Autopest from $0 to $100k/year in revenue. To keep following along, be sure to subscribe!
Scenario #1: The logical, low-lift feature
I got a random LinkedIn message from a free Autopest user asking if the platform could BCC every message it sends to a pre-specified address (e.g. BCC messages to a CRM for tracking customer communications).
At the time, Autopest couldn’t do that, but I realized it probably needed to since lots of professionals have to record their customer conversations in a CRM.
I specked out the feature and realized it wouldn’t take more than a few hours to build, so that’s exactly what I did. A few days later, I’d added the new feature and shared it with the person who asked, and he promptly became a $15/mo customer.
That’s clearly an example of a worthwhile feature expansion. It’s low-lift, it makes sense with the overall product vision, and it adds customers. What’s not to like?
(The only downside in this case is that, a few days later, the buyer told me he was leaving his company and would need to cancel his account. But he assured me he loved Autopest and would pick it up again as soon as he landed at his next job, so I still consider that a win.)
Scenario #2: Major overhaul for a passionate user
Next on the list of new customers wanting something different is user who loves Autopest. I mean **LOVES** it. I have an email from him where he describes Autopest as being like “crack,” and he keeps wanting to increase his usage limits.
Luckily, he’s also willing to pay. His company’s account is currently paying $100/mo, which means he’s tripled my monthly revenue.
That’s the good news.
The bad news is that Autopest was never built to handle the kind of scale he wants from it, and accommodating him means having to do some serious product adjustments.
Is it worth it? Should a startup let one passionate user drive its product decisions?
In my mind, the answer to this kind of question depends on two things:
How much do the product updates pull you away from your core work? In this particular case, the kinds of things my passionate customer is asking for are the kinds of things I might expect to deal with if/when other big customers start using the product. As a result, I can see how doing the work now to accommodate certain functionality could have longterm value. That’s a definite plus.
Is the person willing to pay? In this case, the customer has been willing to “put his money where his mouth is,” and that’s a great sign. Never, never, never, NEVER pre-build a major product feature if the customer asking for it isn’t willing to pay upfront. If they won’t pay first, it’s a huge red flag you’ll be wasting your time. (Unfortunately, I learned this lesson the hard way.)
Scenario #3: A fundamentally flawed feature
In addition to developing new features and functionality for two users over the past couple weeks, I also rejected the request of a third user who would have become a paying customer. But the cost of that customer was too high.
In this case, a free user emailed to tell me he really likes Autopest, but he doesn’t need his follow-ups created by AI. Instead, he wants to write his own follow-up email templates and use those. He said he’d be willing to pay for an entire year up front if I agreed to build a “templates” follow-up feature, and I was tempted to do so. But there was a big problem: it goes directly against my core reason for building Autopest.
Yes, I could technically build what this potential customer wanted, but my goal has always been to make Autopest as easy as possible. In contrast, asking people to create templates isn’t easy. In fact, it’s the exact kind of work I didn’t want to do that ultimately led me to build Autopest in the first place.
Despite being tempted by his money, I turned down the customer. I even pointed him toward a handful of other tools that do what he wants. And, yes, giving up that revenue sucked, but it was necessary.
In previous companies, I chased bad revenue. By that I mean I built features for customers just because they asked for them and they were willing to pay even if those features didn’t make sense with the vision I had for my product and company. The outcome was always bad. I ultimately regretted the choice because I saddled myself with one-off features that weren’t core to the vision and purpose of my product.
Don’t make the same mistake as me. Revenue is great, but you can’t sacrifice your longterm vision for short term payouts. If you’ve validated your product and you’re confident you’re building the right thing, never agree to add features and functionality that violate your product’s core purpose. Doing so can only lead to one outcome, and it’s not the outcome you want.