Developer-Driven Products

Don't usually make for great businesses.

Name at least a few developer-driven products that blow the competition out of the water in terms of usability and business value. I'll wait.

Developers aren't generally great at building products people enjoy and are willing to pay for. No stats to back this up, just throwing this out there.

Why is that?

As a developer turned entrepreneur turned product manager, I got a few thoughts.

tldr: user experience, customer development, business fundamentals.

A developer in a bubble

Back in the late 2000s, I chose to study Computer Science for two main reasons:

  • I grew up with computers. I enjoyed playing games, tinkering with hardware, and learning to code.
  • Some of my best friends were nerds, and they went to enroll in the CS program. I didn't have a preference, so I followed suit.

A few examples of the products I liked back then: computer games from the 90s, open-source software, my old Siemens A50 (I think), and a bunch of ill-fitting jeans and boring t-shirts. Not exactly in tune with the times, one might say.

And I was REALLY protective of my slightly archaic world. The idea of having anything to do with mainstream things made me deeply uncomfortable:

  • The first iPhone was released in 2007, but it took me another 5 years to even consider getting a smartphone. And when I finally got one, it was a cheap Prestigio because "Apple sucks and is for jocks anyway".
  • The only reason I was on the early social media of the mid-2000s was because of my first real high school love. This was pre-Facebook, and I didn't join Facebook until the mid-2010s, years after it got popular around here.
  • Viral projects of the time like The Million Dollar Homepage made me feel conflicted. I liked the idea of getting rich but hated the idea of popularity.

Naturally, I surrounded myself with people with similar interests. Perhaps not as extreme, but they were like-minded and supportive. It was a comfortable bubble, and I didn't see the need to even glance, let alone venture outside of it.

Adopting this mindset in high school has shaped my worldview for close to a decade. It also affected the way I thought of what makes products good.

Building as a developer

My first products weren't actually products: a bunch of Linux scripts, a few games that looked straight out of the early 90s, and other things I built out of curiosity.

I wasn't thinking of them in a business sense, and I had little idea of things like marketing and monetization. I had fun creating them, and some of my friends thought they were cool, so why would I need popularity?

If you had asked me why the iPhone was as popular as it was back then, I'd have replied with something along the lines of "it's because people are dumb, whatever".

Not an uncommon attitude among old-school geeks back then (and today?), but not a great belief to have if you're considering starting a business. That's what I did for the first time shortly after college.

Back then, I had two strategies for creating products that would make me filthy rich so I could buy a tropical island and never work again:

  • "If I build it, they will come." Pick an idea I like, turn it into a product, figure out monetization later. Example: an SEO-driven website dedicated just to the if/else statement syntax in different programming languages. Nichey!
  • "Everybody's doing it." Pick an idea that's hot in the online business circles and build an objectively worse copycat because I can't care less about it. Example: an affiliate website dedicated to fish tanks and aquariums. Yes, really.

I spent about a year toying with this kind of stuff on the side while working as a software developer. It didn't exactly make me rich. Or even moderately wealthy.

Actually, I don't even think I recouped my domain costs. Great success!


A few reasons:

  • Neither of my two strategies included the customer.
  • I completely disregarded the monetization aspect.

First, you are not the customer. If your strategy is based on building things that you like, it might not be the best strategy. Especially if the things you like are... not exactly popular among the regular people.

Second, building copycats isn't a great strategy either. Especially if you don't care for the product and do it purely for the money. Besides, if everybody's doing it, you're probably late for the party. A few years later, these were the reasons I stayed out of the dropshipping craze. Hated the idea, too.

Third, if you plan to make money with your products, monetization can't be an afterthought. You can't do what I did and think "I'll figure it out when I start getting traction".

I failed to get traction with my products because I was too focused on development to think about the answers to "What do people enjoy?". And without users, I never even bothered to ask myself "Are they willing to pay for it?". Which I'd probably fail to answer anyway as a developer with zero business and people acumen.

Not an engineer at heart

Thinking about this now, I could have stayed this way forever.

I had a job and a steady stream of income, so there was little pressure for me to change my ways. I could've easily spent the next decade building side projects for fun without ever cracking the problem of making them popular or profitable. I could've stayed a developer in the streets, creator in the sheets.

And I'm not saying it's a bad thing. If you're an engineer who enjoys building things on the side for fun, more power to you! Doing what you love is the best.

Was I doing what I loved, though?

The longer I stayed in my developer job, the less excited I felt about it. Is this all there is to it? Surely I was meant for something bigger? I mean, I'm building all of these products, and it's kinda fun. Can't I take it a step further?

At least three things bothered me:

  • I felt like I wasn't an engineer at heart. I didn't enjoy the aspect of writing code, and I wasn't great at it. I enjoyed seeing the results more.
  • I didn't like being told what to do. The projects I was building on the side were my projects. And it felt good, no matter how stupid they were.
  • I had a dream of making it big, and the job wasn't it. Small-time entrepreneur genes and a few too many Silicon Valley stories, apparently.

Less than a year in, I quit my job to become a full-time creator.

(One of the dumbest decisions of my life! Don't do it, there are better options.)

This turned out to be enough of a shake-up to get me thinking in a different direction. I started exploring freelance, which eventually led to me working on an online pharmacy platform for a local client. It didn't pay well, but it was a business.

That's when I learned what people are really willing to pay for. This kicked off a series of products I've built that weren't great but paid my bills. Eventually, one of them turned into a business, and I stopped being a developer altogether.

Learning the value of UX

I had no concept of UX throughout high school and college. To me, user experience and usability were synonymous with usefulness to me personally. If the product did what I wanted, it was a good product, no matter how clunky it actually was.

This made it possible for me to spend years running Slackware and Gentoo without taking issue with having to jump through hoops on a daily basis to keep them up to date and do things I needed to get done.

It wasn't until I graduated, moved abroad taking my desktop with me (in a disassembled state), and got a job that I first started having doubts about my definition of usability.

For one, I could no longer afford to spend hours (or days) recompiling packages, dealing with dependency issues, struggling with Wine, and figuring out why I can't get my new webcam to just work.

(Yes, I know there are more user-friendly distros. Unfortunately, all of them suffer from fundamental issues, which is how we got the year of Linux Desktop meme. It was true back then, and it's still true today in 2022.)

That poor machine eventually failed and I had to begrudgingly get a new Windows 7 laptop. It didn't take me long to realize Windows wasn't actually as bad as I was painting it. Everything just worked, which was a pretty new feeling to me.

I kept a separate Arch setup for another year or so, but Windows became my default go-to choice and I had no incentives to switch back.

Getting into drawing around that time and struggling with GIMP instead of Photoshop did little to reinforce my belief in the greatness of open-source software. Here's my GIMP rant from back then that I shared in my earlier article:

This whole experience made me start thinking of "good UX" as something that:

  • Is simple.
  • Saves time.
  • Feels good objectively, not just subjectively.

It also made me more conscious about the UX of products and services around me. I stopped looking at the world from my nerdy perspective, or at least made effort to be more objective. A great skill to have, especially if you're building products.

Years later, before I learned to rely on usability testing, this made it that much easier for me to trust my gut feeling when designing UX for our own products.

Once you get good UX, there's no going back.

Learning the value of customer development

Customer development was harder for me to grasp than UX, for two main reasons:

First, I wasn't a people person. The fact that I wasn't an engineer at heart didn't make me social. I was still shy and socially awkward, and the need to interact with people made me anxious.

In the early days of my first successful products, I had trouble dealing with support requests because I took them too personally. Proactively reaching out to people to disprove my ideas was absolutely out of the question.

Second, I got lucky not to need customer development for a while. The experience of building ecommerce modules as part of my online pharmacy gig provided me with a product strategy I could replicate:

  1. Think of a piece of functionality a typical online store needs.
  2. Build a self-contained module to do just that.
  3. Publish it on a module marketplace for the customers to find it and buy it.

It didn't matter who the customers were. I sold to developers and store owners from the same marketplace without doing any marketing. And for my early modules, there was no difference in requirements between these user groups.

I first learned the value of customer development a few years into building the product that later turned into my business.

The product was a module that turned an online store into a two-sided marketplace. It was simple at first, and I kept doing what I did before: adding features I thought made sense to "users" without thinking who those users were.

You can get away without customer development for quite a while if you're lucky. In my case, this has eventually turned the product into a bloated mess of features that weren't good for anyone.

It took me a few months of drowning in support tickets to realize this isn't working. I finally mustered the courage to talk to some of my customers more seriously. I then spent some time thinking about the direction I want to take the product in and killed off a good chunk of features that didn't align with it.

You might say this wasn't a formal customer development process. True, but it made me seriously think about who my customers really are for the first time. This would come in handy later when I was faced with a lot more complex challenges.

Learning the business fundamentals

By which I mean everything else that turns a product into a successful business.

I've built my early products with near-zero knowledge of sales, marketing, finances, managing people, strategy, and operations. A few years and a few unsuccessful outsourcing attempts later I decided to figure it out myself.

In the end, the business wasn't a great success, but it wasn't a failure either. While I didn't become an expert in business fundamentals, I got good enough to be able to assemble a small team and take our product through multiple pivots while staying 100% self-sufficient with the exception of the final year and change.

Ultimately, this experience allowed me to transition to product management, which I consider a success, all things taken into account.

And that's my story of going from a developer-driven mindset to a more customer- and business-oriented one. This is a personal experience, obviously.

Developers are people, and people are different. I've just spent a few months building up my Twitter presence, and I'm happy to see so many developers being open, public, and business-oriented.

Products are different, too. Not every product needs to be a business. And not every product needs to be perfect UX-wise. But it helps to know what makes successful products truly successful if your goal is to build one.