Two years ago I made what felt like a smart decision: instead of betting everything on one product, I'd build two. FillTheTimesheet for time tracking, PromptShip for shared AI prompts. Different audiences, different problems, different revenue streams. Hedge the risk.
What it actually taught me wasn't about diversification. It was about how badly founders lie to themselves about feature traction.
The "if I build it they'll use it" trap
When you build one product, every feature feels essential. Of course people will use the new integration. Of course they'll love the timezone-aware reporting. Why wouldn't they?
Building two products in parallel kills that illusion fast. Suddenly you're forced to ration your engineering hours, and the question stops being "should we build this?" and becomes "if I only have 4 hours this week, which of these eight features actually moves the needle?"
That single shift surfaces a brutal pattern: most of the features you're certain about have no users. They have feedback. Feedback isn't users.
What "no users" actually looks like
In FillTheTimesheet's first year, I built a granular permission system because three customers asked for it. They needed admins, managers, and read-only roles. Built it in two weeks. Shipped it proudly.
Six months later: 4 of ~600 active accounts had ever opened the permission settings page.
Same story in PromptShip. We had a beautifully-engineered version history feature. Diffs between prompt versions. Branching. Restore. We shipped it because power users asked. Months later, fewer than 2% of teams had ever clicked into a prompt's history.
Both features stayed. Both kept costing maintenance hours. Both were features I would have sworn were critical.
The lesson neither product taught me alone
If I'd only been running one of them, I'd have stayed convinced. With both running side-by-side, the comparison was unavoidable: features I was equally certain about were getting wildly different adoption. Some were ignored across both products. Others — boring ones I'd reluctantly shipped — were used constantly.
So I started measuring two things on every feature, every month:
- How many distinct users touched it in the last 30 days?
- What % of active accounts is that?
If a feature can't clear 10% of active accounts within 90 days of launch, it goes on a "kill or fix" list. Most go. The page is shorter, the codebase is smaller, support tickets drop, and — counterintuitively — retention goes up because the product becomes easier to understand.
The takeaway
Customer requests aren't validation. Roadmap energy isn't validation. Even paying customers asking for something isn't validation.
Use is validation. Repeated use is real validation.
If you're a solo founder or running a small team and you're feeling buried in your own roadmap, try this: pull a usage report on every feature you shipped in the last 12 months. Sort by distinct users in the last 30 days. The bottom half of that list is your answer about what to cut.
You'll feel some grief. Then your product gets faster, simpler, and easier to sell.
Top comments (0)