What I Learned About Starting a Software Company: Part 1

I realized that I wrote this article, How to Digitize Anything, but never explained why I'm qualified to write about it.  I thought it might be a good time to share the backstory. Five years ago I started a software company called DayJibe. 

This was my first business, and I went through the entrepreneurial rollercoaster.

I envisioned developing a platform that digitized architecture and civil engineering firm processes—an all-in-one digital toolkit for these firms. 

My product at the time was novel, and very few companies were doing it. I hired a software development firm and spent a year working mornings and nights building the product. The extreme joy quickly moved to frustration, however. 

After each development cycle, I realized what I was building was becoming bigger and more expensive, yet further from finished. As a project manager unfamiliar with software, I felt the burn of scope creep, and I also felt trapped by the sunk cost fallacy. 

I will save the rest of the story for another article (I promise!), but what is important is what I learned about digitizing processes. 

Digitizing an "analog" process by talking to potential customers is often counterintuitive. In fact, it’s so counterintuitive that I made common mistakes after being warned by a mentor and reading a great lean startup book that specifically explains how to avoid the mistakes I made. 

Why? Because I thought I knew better than what the customer wanted based on my own experiences. Some of the features I thought would be amazingly valuable just weren't to the client. Meaning I had spent time developing and creating features that didn't move the needle to close a sale. It may seem simple, but realizing that your ideas don't matter, but the clients’ needs do, is difficult for a first-time entrepreneur and anyone with an ego. 

I also learned that customers pull when they like something. Imagine fishing. When there's no fish on the line, regardless of how much you reel in, you'll never catch the fish. However, once you get a fish hooked, you feel them tugging at your reel and you know they want what you have. This pulling is essential to knowing you have something that adds value to your user. 

The second thing I learned is digitizing a process becomes significantly more complicated if one portion of the process is not in your system. Perhaps it's a manual process, part of another software product, or located somewhere where you need to build an interface or what's known as an API. Not all systems talk to each other, and often the interface comes with restrictions. 

Lastly, there's a part about digitization that is not sexy and not often talked about: labeling. 

Having the correct labeling of databases is essential for digitizing products. Without it, you will need to hire an army of people to sort through and fix your databases so they can properly talk to each other. Some of this can be automated, but you'll likely need people to help depending on how bad it is.  

I hope sharing some of my learnings helps you understand why I'm passionate about this topic, and why I believe in creating products that pull users because they are valuable.

Have you built up a software product? What were your biggest learnings from the experience? Let me know your thoughts or tweet me @theomarproject.