A guide for software developers to stop writing beautiful code, and instead make interesting products people will use.
Developers love making things. However, more often than not, they get caught in a trap of building things nobody uses.
There is a critical difference between making products YOU care about, and products ONLY YOU care about. For developers, this difference can be difficult to identify and understand.
If you’ve ever built a cool app that nobody cared about. This guide is for you.
I’ve said in the past, software developers have an entrepreneurial spirit. Like entrepreneurs, they share the passion and ability to make things. However the similarities pretty much end there.
There are valuable lessons developers should take from entrepreneurs when they become more serious about building useful software. This guide will touch on the surface of a few of those critical keys.
**You can and should go deeper into these keys in your own endeavors.
Stop Thinking It’s All About You
Let’s add domain knowledge like market research, cost benefit analysis, product-market fit and market position as a few items on the “to do” list for future research.
Right now, lets talk about the essence of making things.
There are basically two school of thoughts when it comes to making things.
Make things for yourself and hope to get lucky, or make things for other people, and hope to get lucky.
Most developers will identify with the former. All engineers I know build passion projects to showcase their talents and learn new things. The value of their product is to showcase their skills and execution for employment or personal glory.
This kind of thinking has a fatal trap: You built something that only has a value to YOU. Building things for yourself is a logical step for engineers. But it’s this kind of thinking that engineers must break out of to become better product developers.
On the other hand, entrepreneurs will identify with the second school of thought. Because a big part of an entrepreneurs job is to find opportunities to solve other people’s problems.
The first change any developer must make is to adopt a larger, more market oriented thinking. To start thinking about the whys and hows someone other than yourself would use your product.
But Don’t Think It’s All About Other People
Do not mistake thinking about a market as a mandate to cater to that market. Your product and your company will need a vision.
Your vision is your reason for building what you’re building. You must be willing to state it loudly and proudly into a market place. Your vision is your opinion about how something should be, your product is the solution to be that difference.
If you find yourself struggling to say something meaningful, it’s a signal your product hasn’t developed it’s identity yet. Do not be afraid to state your opinion and how your product serves its mission.
Your customers aren’t going to fully describe their problems and possible solutions to you. You cannot rely solely on focus groups and customer demands.
Having a core set of beliefs will help make it clear which requests and ideas to say yes or no to developing.
Start Caring About Stuff
Whether you are building something you want, or building things for other people, you need to care deeply about what you’re building.
More importantly, you need to care deeply about the problem your fixing, and not the solution you’re providing.
Whether you choose to focus on the product or on the people, I cannot stress enough how important it is for you to care deeply about the problem you are solving.
Stop Caring About Technology.
People don’t give a **** about technology or your technical achievements. And nor should they. That’s because they can’t tell the difference between you and a monkey hitting a keyboard with a rock.
Technology is much like wine. For wine lovers, it takes knowledge & experience to appreciate the differences between a Chateau Margaux and a Château Saint-Sulpice.
If your an unsophisticated consumer like myself, “Do I like the taste?” is your only metric. I am unaware that the makers of Margaux individually hug each grape, and therefore cannot justify the $4,500 cost vs a $15 buck Saint Sulpice.
People love using technology. But the keyword there is “using” not “technology”.
I’m sure your code is beautifully organized and documented app that has 100% code coverage. And your optimized SQL backed varnish cache returns compound queries in under 30ms. But it takes a seasoned engineer to appreciate your achievements.
If you want to build something to show off your tech muscles, by all means. But understand just because you care about something doesn’t mean your users will.
Good Ideas Aren’t Good Business
There is an uncomfortable process every developer must endure whenever they get excited about an idea. The truth is, something can be a great idea without making it a great business.
If you’re not interested in making money on it, then go fourth and godspeed.
But if you are hoping to turn this idea into a income source, then there are some reality smacking gut checks every idea must survive to make it worthwhile.
What Are You Doing?
Can you describe the problem your product solves and how it will solve without being vague?
If you explained it to a 5 year old child would they understand it?
Simply put, your app needs a clear purpose for use, and a clear reason why someone would use it. This concept is as important to product development than it is to marketing and business. This clear purpose is your “value proposition” and the problem it solves is your “mission statement”.
Your value prop is the reason why someone would need something like your product, and would choose your product vs a competitors.
If you can’t explain your product’s value in a simple way, there is no way for your market to understand it’s value. It would also be a clear signal you haven’t fully described and understood your product’s value.
DONT: “It’s an app that aggregates all the upper case letters in a Medium post and then creates a word cloud that finds repetitive patterns in a trending topic using AI from Azure and the power of the Cloud to create synergistic flows that signal a paradigm shift for marketing trends.”
DO: “We make and sell chocolate chip cookies”
Messaging isn’t just a marketing ploy, having a clear cut product value and mission statement is fundamental for your customers and your employees.
This is the core basis from which decisions are judged. Any decisions that subtract from your value or mission should be avoided, or your value/mission altered.
Recap:What problem does your app solve? How does it solve it?
Who Are You Making This For?
Say out loud and without using general language, who are you building this for?
I’m serious, describe as detailed as possible people who you think your app can serve.
“People with phones”, or “People with money” is not a good enough description.
Give me a description would qualify only 10 people in a room full of 100.
Now give me the name of 5 people that actually fit into that description.
Better yet, tell me how you would find someone in that group you DON’T know.
Find me 10 of those people. Then sit down with them face to face and .. … tell them about the problem your application solves.… ask if they have that problem.… ask how much of a problem is it.… ask what would they be willing to pay to solve that problem.… tell them about your solution. … ask them to give you 3 reasons why they would use your product.… ask them to give you 3 reasons why they wouldn’t use your product.
DO NOT DEBATE OR JUDGE THEIR CRITIQUES.
Don’t try to sell them the idea, instead open a dialog about the pains they feel with that problem, and what they do now (if anything) to solve it.
Repeat this process with as many people as you can find, until you’re highly motivated by newfound insights or hopelessly discouraged and abandon your original idea.
Ideas vs Execution
One of the biggest lies developers initially guard is the value of ideas.
I can’t tell you how many times I’ve sat with great developers to come up with the next great idea. Every single time, it was a huge waste of time.
Many people will argue a good idea makes or breaks a company. I use to believe that as well, but I no longer do.
I believe that a poorly executed great idea will go no where, while a well executed Okay idea will do fine. The reason I believe this is two fold.
First, a brilliant idea will go no where if you don’t ever build it. Second, if you’re worried that someone else can do your idea better than you — you’re already setting yourself up to fail.
Part of your value prop is not just your solution, but why you’re the right person to solve it. One of the core marketing concepts is that people don’t buy what you do, they buy who you are. If someone can build it better than you, they will.
I also argue trying to come with a good idea completely misses the point. You should be trying to find a problem you care about deeply which YOU can provide a elegant solution for LOTS of people.
There are a lot of actual market concepts and strategies to learn which you can read on Josh Kaufman’s The Personal MBA. But there is a simple popular rule of thumb to follow: Be first, better, or different.
Build Baby Build
Another major blunder well meaning developers make is overbuilding their products. When we’re first inspired to build a product, we imagine all the possibilities the app can serve.
Part of a good execution is in what you don’t build and saying NO to a lot of good ideas.
One of the sacred texts of startup culture is The Lean Startup by Eric Ries.
I am no longer a huge fan of the words “startup” and “lean” as they’ve become loaded terms. But I am a big practitioner of key lean principles.
One of the foundations of lean is to start small and learn quickly. You can learn about the learning feedback loop from Eric Ries’s book. But the heart of the lesson every developer must learn is this:
The quicker you can start learning from your customers, the more value you can build faster.
Start small and launch early is uncomfortable for developers who want to build to impress. But its a hurdle every developer must overcome.
This is a simple but major break in thinking. Realize you are not building an app, you are building a product. A product that must live in a market and be useful to people. And people have a funny way of giving things value.
Speaking of People
People suck.
They behave in all sort of counter intuitive and herd like ways.
That fail case you dismissed as “nobody would ever do that”. Some idiot is going to do that.
“People are going to love this feature” — nobody will use it.
“People will totally pay for this” — no they wont.
A major shock to developers who build things is how building awesome things doesn’t automatically attract loads of users.
Failing to connect with people is your fault, not theirs. People are not out there right now waiting for you to launch your product. They aren’t hopelessly looking for just the right solution you are going to provide.
Getting people’s attention and getting them to buy your product is going to take a lot more work. Trying to get someone to pay you $1 for something is actually a lot more difficult than you think.
Even if someone is actually looking for your solution, getting their attention in a crowd is hard work. Appreciate the work that marketers and sales people put into getting your attention and helping you make decisions.
There are hundreds of micro decisions that influence people to make decisions one way or another. You don’t have to acquire a PHD in psychology, but you should familiarize yourself a bit with core marketing principles.
I won’t go into details behind every concept, but get to know basic marketing and economic principles even if you’re still in product development. They’ll help guide your business decisions to support your application.
Businesses Are People Too
Not in a Citizens United sort of way, but in a ecological sense.
A major flaw most people let alone developers think about business is a false analogy. They tend to think of businesses like machines, with components who perform specific and isolated tasks.
Lie: “Developers build things, marketers find customers, sales people sell it”.
In reality businesses are more like living creatures, who’s organs all need to work in conjunction. There is no major organ more critical than another, and a failure to one system can bring down all the others.
A sales person’s job is made easier if the product has a better market fit. That market fit is cozier if the the product developers understand the customer needs more. The developers can build the product better if they understand the customer’s pain. They will all build a better value if they all understand their mission.
For us outside the business and sales industry, we only experience being a consumer. We tend to think we did all the work of finding the product and going out to buy it.
We fail to see the invisible forces at work that put that product in front of us. We are oblivious to the emotional and automatic decisions that helped us choose that specific brand.
None of these things happen automatically. Developers often don’t appreciate how much work it takes to stand out in even a small market.
Building an app, and sending a tweet or putting it on reddit doesn’t cut it. You are going to put a lot of work to get people onto your app, so you need to make sure your effort is worth it.
A Little Knowledge Is A Terrible Thing
One of the first traps I personally fell into was overconfidence by little knowledge.
I started my transition into business development by reading up on business theories and philosophy books such as The Lean Startup, The Pumpkin Plan and The Personal MBA.
Although they are all great books, it took me a while to apply their lessons into larger contexts in which they are intended. Instead I became hyper focused on issues that were irrelevant to me at the time.
For example, I lived LEAN startups and MVPs even though I had not defined a product to sell. I became focused on developing customers like The Pumpkin Plan without a starting list of clients. I learned how to run a business in The Personal MBA without having a product, a client, or a company.
I literally LOL when I think about it now. But in hindsight I was eager to build, but I used these philosophies and guides as a way to mask the fact I had no idea how to begin.
The biggest reason I started writing on Medium was no book helped me address the question of: Where do you being when you are at stage zero.
Be Lean, Be Mean, Be Green, But Stay Focused
So long story short from that self centered drama above is simple. Don’t get caught up theory. Its easy to let philosophies stop or distract you from basic and simple concepts:
Find a worthy a problem, Build an solution, Connect with people.
Taking a more serious approach to making software means you are hopefully incorporating at least one if not all three of these basic principles.
Don’t let practices, analytics and measuring stop you from building things and getting it in front of people. The whole concept behind major publications like Lean Startup or Rework is do not get caught up in distractions from your core mission: to build value.
Wrapping Up
I spent a lot of my time not knowing where to begin. I found myself caught up in learning so much that I lost focus on doing. Remember all of these theories and philosophies and practices are only there to guide you.
There are no guaranteed ways to succeed, but you guarantee failure doing nothing.
If in the end you want to build things for yourself, just have the courage to put it out there.
There is too much information out there for any one person to digest, but that shouldn’t stop you from trying.