For a while now I’ve suspected that, as a lone tech founder, I have a blind spot when it comes to pitching software products that appeal to people sufficiently for them to make regular use of them. The products I build just don’t fit a market well enough to gain those regular devoted users.
What I appear to be good at is making usable products; ones that make people go “That’s great!”, “It’s really slick”, “That’s such a cool idea” (I feel obliged to confirm that those are actual quotes from non-family members!)
The problem is that beyond a demo, cool ideas that aren’t easily applicable to the everyday lives of real people don’t turn into popular products. What do I mean by “easily applicable”? Simply that the distance between what the product does, and what the user wants to do, must be minimal. This reduces the friction that the user experiences, makes using the product more of a pleasure, and increases the chance that they will return to use it some more.
Having realised that I have a blind spot, I spent a while asking myself what that might be, fully suspecting that it has been the same blind spot for both of my products: UbiquiList and Changes That Stick.
After a few days and some soul searching, I think I hit the nail on the head:
I build overly-general products for a world that loves specifics
Why? I suspect it’s a result of the way we grow and develop as software engineers. We spend our careers learning to isolate concepts, define terminology, generalise where possible, and build the most flexible and reusable solutions we can, within reason. From a software standpoint, this is all good.
But when it comes to product design and market fit, the world appears to love specifics. People don’t want a general-purpose framework for logging and visualising their progress towards personal goals. They want an app that tells them not to eat the donut, that they lost 2lbs this week, or that they just achieved their personal best running time. Likewise, they don’t want an app for general-purpose list-based collaboration. They want an app for smoothly collaborating in precisely the ways that collaboration works best in their organisation, whether that is list-based, project-based, chat-like discussions, whatever.
I spent some time studying products that have gained traction and regular users, and my assumptions were confirmed: All of those products excel at specific use cases, and then add general functionality beyond that. But crucially, they nailed that specific use case first. I guess that delighting a subset of potential users with something that fits their use pattern closely is a great way to begin to win devoted followers. Beyond that, the app can be expanded to fit more general use cases and to pull in more users.
So my takeaway lesson is that whilst generality is good in theory, specifics must come first. I am learning to think in two modes simultaneously: generality and reuse for software design, and specifics first for product design.
This feels like a hugely valuable lesson for me, as a lone tech founder. But even in startups where there are other non-tech co-founders, I suspect that being aware of this issue will help tech co-founders to understand and contribute more effectively to product design. It is also yet another reason why I am currently searching for a non-tech founder, and I suspect that I will have other blind spots that I would like to avoid.
I would be interested in hearing if this fits with your experience of trying to find product-market fit, whether you’ve achieved that successfully, or whether you’re struggling to get there too!