I’ve gone from full-time employee to part-time.
First of all, this is huge for me. The Closet Assistant makes more than enough for me and my family to survive, and it’s stable enough to rely on.
There needs to be a fundamental shift in how I operate the business, however. That’s what this post is about.
In the month of August, I spent the entire month adding features.
I spent the last week reverting most of those. Let me explain why.
Smaller feature updates
It’s hard as a developer to not try and code your way out of problems. You just want to keep coding. Keep adding. Keep automating.
However, this can lead to other things falling apart. It can also make you vulnerable to making too many changes at once.
Your customers are used to how your software operates. If you go straight from version 1 to version 2 without any ramping, your customers might not like the change.
Features and other code improvements should be implemented in small chunks, with feedback and verification that there’s no issues with what you pushed out.
You should be testing your code (no, not unit testing), but at least checking if things work. That’s debugging 101.
But sometimes you miss something obvious, and your customers panic because “it’s broken”.
You don’t know what “it’s broken” means, and because you shipped 10 features and changed some of the existing code, you don’t even know where to start with debugging.
When you ship smaller updates, it allows you to fail gracefully.
“Oh, that’s broken? I know the exact place that could be. Yup. Okay, it’s all fixed.”
“Oh wow, you’re the 10th person who has emailed me about that. I’ll get back to you in a week. I might have it fixed by then, we’ll see when I can get another 4 hours of uninterrupted work done.”
When you’re an indie developer, who doesn’t work full time on your project, you can’t waste precious hours fixing the problems you made (and fixing code that’s not broken when there’s problems to try and figure out what’s wrong).
Take time to plan out your features. Ship them one at a time (maybe two if you’re confident). Small, consistent changes will feel great to customers, and it will bode well for your sanity.
By shipping small features often, you get better feedback about your vision for the product.
The product direction is ultimately up to you, but it’s largely dictated by the demand of your customers.
If you bundle a bunch of features into a new update and shove it at your customers, they may or may not like it.
If they like it, great. You are aligned on vision.
If they don’t like it however, then you’re out a month of work and you need to revise the direction you were taking the product.
Your customers complain when you remove things you use, but they don’t say anything when you add stuff that they don’t use.
You don’t know what features are significantly more popular than others unless you ask.
Asking for feedback too often can be annoying, so your customers will become numb to it.
However, if you launch small updates, every time you add a small update there’s an opportunity for your best customers to chime in about what they like or don’t like.
They’re also an opportunity for you to ask for feature requests and what your customers would like to see happen.
This helps keep you aligned with what the customer wants, and it keeps them aligned with the features you expect to actually ship.
Better features, better marketing, better product.
Sometimes, making the features you already have better is the way to your customer’s heart.
If you already have customers, they came and paid for the features you have now. Not the future your product has.
When you ship better features, instead of just new ones, there’s delight all around.
You can’t change too much, but you can adjust the speed, flexibility, and autonomy of the user.
Making things faster, more flexible (but still simple), and having chances to automate repeat tasks are all wins.
This will help reduce churn, while also making your current customers bigger advocates for your product.
Sometimes, you can add all the features you want to a product and it won’t move the needle.
It’s essential that you are focusing on marketing your product, not just writing code.
Things like writing blog posts, how-to guides, advertising, and other forms of marketing can be powerful with the features you already have.
This is similar with design.
There’s definitely a ‘good enough’ with design, and once you hit that you can put it down for a while. Only when things have matured should you think about changing the design.
I’ve been running a test with FB Ads. I have been running about $20 a day in prospecting ads.
They’ve been largely ineffective, as most of my targeted traffic comes in through SEO. So, I’ll be running some Google ads for keywords I’d like to rank for, competitor keywords (with comparison guides), and for my own brand keywords.
This is guaranteed to drive results, as I’ve seen that SEO is basically the only channel that drives free-trials.
Simply nailing this tactic will explode my growth much more than any feature would. The market is not saturated in the slightest.
Everything you do drives a better product. The documentation. The support. The design. The features. The results.
All of these things should be maintained and should represent a company/product you are proud of.
How this impacts me
I’ll be sticking to a weekly feature roll-out schedule, writing an article every two weeks, and iterating on my marketing channels monthly.
As of right now, I am working two full days a week on the Closet Assistant. That’s way more than I was working before.
Now I actually get a chance to decide what I do with my time, instead of it being chosen for me by handling whatever was most important.