Something I’ve had top of mind for a while is the idea of building paid software. Not in a business-school-make-money kind of way though.
I’m interested in building paid software for the relationship with the people that use the software. How can I build something simple that helps people live better, or even just less painful, lives in a respectful way?
These are both things you can do with free products, but it’s not quite the same. Paid products force prospective customers to consider the value and if they want to opt in. There is an explicit value exchange that sets an important tone: people pay for the product and can continually assess whether it meets their needs.1
This relationship is beautiful. It’s good for business if product makers continue making improvements and treat product users well. In turn, users help guide what goes on the roadmap.2
Now that I launched my last product and am side-project-less, I spent some time noodling about general ways to approach building paid products. I’m sure I missed some, but these all seem like decent starting points.
Complexity is the enemy of many things. Software loves to morph into complex, tangled spaghetti over time. One route to making a paid product is taking a feature of an already successful, yet complex product and giving it new life. Letting it shine on its own. Unbundling is a subset of this.
Doing one thing really well is often better than doing a bunch of things that are mediocre.
If an old product escaped feature-complexity, it’s probably visually bloated or the design could use a touch up. Slapping a new coat of paint on the same or similar features, or even redesigning from the ground up with fresh eyes, will make it look close to brand new.
Great design is not easy, but a better design is often as simple as reducing visual clutter and sorting out hierarchy. Beware of just copying whatever design is popular or you’ll redesign again in a couple years.
With data leaks and breaches happening more in recent years, people are becoming more privacy-conscious. Taking an existing product and making a privacy-focused version should attract some interest, especially if the existing product/industry cares very little about privacy.
You can build a privacy-focused product through marketing alone — users will feel good, but it will all be for nothing — or you can do the hard work to ensure everything is actually private. This “hard work” might be as easy as upgrading to a more modern tech stack or architecture.
Tools that help users tell better stories or make better decisions are extremely useful. Finding signals for users from their existing data or enriching their data with novel sources will help them do both of these things.
Tactically, take some data and present it in a different way, or give a group of people access to data they didn’t have before. Humans are really bad at processing and finding trends in high-dimensional data so even if the tool just prevents comprehension errors, it’s worth something.
When new, high-growth platforms spring up, they can’t build everything for their users. Find out what these people need and make it. It might be hacky at first, but a lot of tech platforms open things up to developers nowadays. Being the first “app” in a platform’s “store” can lead to fast growth.
This strategy could also work for more mature platforms, but a lot of the low-hanging, tasty fruit will already be picked off.
Given a large enough company, old enough software, or both, there are groups of folks that hate their job because they are tormented by the same piece of software every day. Find and listen to them. Those that are experiencing a “hair on fire” problem want to find a solution quickly.
Potential blockers here are the people with the acute need don’t have purchasing or decision-making power.
If you pay close enough attention, you can find things that are annoying about almost anything, including your daily life. Likewise, you can also notice shortcuts that others don’t. Productizing a solution to these annoyances or making shortcuts more accessible/obvious will give you at least one user — you!
If you don’t think you have any problems, ask someone else about theirs. Try to notice how they work too. Is it different from what you do? Is that better or worse?
Almost every tech company builds the same internal tools. Find out who built them and ask them why. Did their last company build the same tool? If you work at a tech company, especially a large one, there are a lot of potential customers walking around.
If you think companies won’t switch away from their internal tools and buy your productized version, you are wrong. Internal tools are often very rough and expensive to maintain. Product manager and CEOs would love to use your product if it reclaims engineering time. Maybe your current PM or CEO is your first customer?
Closing notes: I’ve built paid products before, but as part of large teams. There’s something different about getting paid to make a paid product and being the one that gets paid by the paid product.
- Free products have more abstract value trade-offs (i.e. time/attention and instead of money) so there’s a lot less friction to amassing users.↩
- Calling people that use a product users is lazy. There are other options, but since this article is very general, I’ll continue using the term. At Patreon, we say creator, patron, fan, etc.↩