Making software that makes money
You can't predict what the market wants. But there's a process you can follow to discover it.
The art of computer programming has produced more entrepreneurs than any other creative discipline in human history.
A programmer is rarely short of motivation to build new things, but nobody, no matter how experienced, can predict how the market will react to something new. Knowing what to build in the first place requires a process informed by robust principles.
So how can a software engineer learn to produce not just great code, but inherently valuable software that people will love? Keep reading and I'll share the process I've used to achieve this many times in my career. A process called "customer development," or "prototype-driven development".
Be first to get posts like this in your inbox
Reading this guide should shift your perspective about value creation from product framing to problem framing. Get used to seeing problems as the North Star, and not the product.
There's three things that will make this process easier for you:
The willingness to work hard for little potential reward for an unknown amount of time.
Have things in your life you're actively passionate about.
The ability to build basic software and ship it. It can be done without writing code, but you will have less freedom.
Finally, engineers: remove writing code from your mind for now. Coding is the comfort zone, and it's not going to be productive to ship anything until you understand the problem you want to solve. So let's start with the problem.
Step 1: Problem discovery & value proposition
Outcome for this step: A list of problem statements that are specific, measurable, and action-orientated, and a few value propositions for each one. See end of section for an example.
Problem discovery is about building a deep understanding of specific problems that specific people face day-to-day. The word specific is emphasized because problems must be precise, measurable, have clear boundaries, and be grounded in reality.
Value propositions capture how you intend to solve the problem, framed from the point of view of the customer. One sign of a good problem statement is that the value props will often reveal themselves. A good problem statement has many potential value propositions.
Focus on things you're already attracted to working on when going down the problem rabbit hole. Imagine you're going to work every day on this for the next three to five years. Ask yourself "will I lose interest in this?"
Here are some tried and tested ways to think through finding problems:
🔁 Write down your routines. Be detailed about this. Write down each discrete step. Then challenge each step: what could be easier about it? What happens if the step is removed?
💸 Count what you spend money on. You might learn more than you expect by going through your transaction history. Note down the things you purchase regularly. Ask yourself 5 why's for each one to discover your underlying motives.
😓 Look for wasted energy. This one can be done for yourself or other people. Problems that are very painful will make solutions way more attractive. Focus on the painful over the inconvenient and the boring.
Example: Problem statement and value proposition
Problem Statement: Independent video creators don't have much time to re-edit videos for short-form platforms like TikTok, Instagram, and YouTube Shorts, but doing so would be advantageous.
VP1: A plugin for video editing software that exports clips along with the final edit, saving time.
VP2: Autonomous software that prepares and uploads clips with no human input needed.
VP3: An editing team that can be outsourced affordably, specializing in short-form viral content.
What if the problem was already solved?
It's hard to think of a perennial product or service. Everything is open to change at any time, and if there's a solution on the market better than the status-quo, it will be valuable — even if it's valuable to a subset of customers.
The specific "who" in your problem statement is useful here. It directs you — the value producer — to serve a group of customers, also known as a niche. A large ratio of the fastest growing startups got going by capitalizing on an under-served niche.
Don't be afraid of small niches. If you can secure 1,000 customers globally paying $10/mo, that's $120,000/yr revenue.
Step 2: The first prototype
Your first prototype will test your value prop with your chosen market segment. You can, and should, run the test with minimal effort. You can do it with a press release, a tweet, a reddit post, or a webpage.
A successful outcome will get potential customers to show interest. Interest can be measured with a simple "email me when it's ready" form, an "I'm interested" button, or by counting the number of readers or page views on the webpage.
Get comfortable with the customer development loop. You can use the same methodology to drive more value creation, test business models, and prevent mistakes as you grow.
We prototype and test for the same reason a rock climber leading the climb anchors into the rock face as they climb higher. The climber could probably reach the top without falling, but if they overcommit and fall from a great height without an anchor, they are more at risk of disaster.
Steps to test different value propositions or solution statements:
Pick 3-5 solutions to test. Make sure solutions are anchored to the problem statement.
Go to where the customer is. Social media is a good start, but get as close as possible, use forums, Facebook groups , etc.
Observe the reaction to each post, and ensure you collect any feedback you might have received to work back into the process.
When you have your data and feedback, you should start to see a clear picture of which solution could win out.
Step 3: Prototype loop
After the results are in from the first prototype loop, the process can start again on the next one. The next loop could be building a demo, or testing further value propositions until you have the direction dialled in.
Functionally speaking, prototyping (or customer development) is the process of going from low resolution to high resolution, using lessons from the current step to improve subsequent steps.
A better way to build?
There's an art to customer development. Like TDD, it can over-complicate or distract focus from customer experience.
When it makes sense to use it, customer development feels like you have a treasure map that nobody else has seen. It invites the beneficiaries of a product to help shape it, and I personally find that to be a more meaningful way to work.
Good luck building!