Staying on track when there is no track to follow

by alex 6. February 2013 18:30

I have several things that need to be done and it isn't always clear what should be worked on next. Being employed by someone else is great in this department because there's always someone yelling about things that need to be done last week, and you can just say "hey boss, what is most important right now?" And then boss man or woman will give you priorities in a way that makes sense, removing the burden of making hard decisions and allowing you to focus on delivering those goals.

This is not the case when you are the engineer driving the train. Because you don't know where... the... track is going. Or something like that. Just keep the train from exploding, that's what I've always said.

Anyway, deciding what to do next, so far, has been the hardest part of this experiment. It has recently occurred to me that I've been a little misguided the last few days. "Doing things" will walk you down the path toward a goal, but checking stuff off a list is not my goal; having an empty list of to-dos is not my goal either. I could keep doing things for two years until I'm tired and out of money. So let's stop that pattern now.

What needs to happen?

This experiment exists because I built a solution to a common software management problem and I want to help other development teams avoid the same pitfalls. I also want to earn at least a minimal living while doing this so that I can continue the practice for years to come.

There! Two goals to work towards:

  1. Help software teams avoid common pitfalls in release management and version control
  2. Support myself on the earnings from #1

These aren't directly-achievable goals, they're like like a rough mission statement. However, they do give me a bit of direction. To meet this goals, a few things need to occur:

  • I need to have a product that offers a measurable value to a potential customer-base
  • I need to advertise the value of the product
  • Potential cusotmers need to be aware that my solution exists
  • People need to understand the value of the product, and how it applies to problems they have
  • I need to offer a way to exchange their money for my product
  • I need to maintain high customer satisfaction (earn trust, actually deliver on the values that I promised)

In order: I have a software product, I have a website that sells it (poorly, but it does exist), my market is not reaching my website, my friends and family (intelligent people) don't understand what I'm selling, but I can take credit card payments and my one nonpaying customer is happy.

However, one thing is clear...

Stop working on the software

I am a programmer and it is my inclination - I dare say, my wont - to solve problems with code: adding new features, making applications faster and more stable, yada yada. It seems patently clear that coding is the last thing I need to do right now.

I have only one customer and they don't have any specific feature requests or needs that aren't currently met (minus one minor add-a-column-to-this-table request which I will deliver). Adding features to the product will not translate into more sales because my market won't see the results of this effort until after they've made a purchase.

What's a fella to do?

My sales site doesn't get traffic aside from my direct friends and family. That's my #1 problem right now - I can't do A/B testing and sales optimization, nor does it matter how bad my sales pitches are, if I don't have anyone actually looking at the site. I have two ideas to immediately address this issue:

Advertise with Google Adwords

Adwords is a service provided by Google to show advertisements to your target market in Google search results. This, presumably, should generate some traffic.

My keywords are expensive ($10 per click for "software release management"!).

I'm hesitant to pursue this avenue this because it has a monetary risk, I don't know what to expect for the results and I know that my sales pitches need work. But, Adwords should generate traffic - which would blindly address this goal - and they are a service that I'd planned to use "in the future."

Worst case, I blow my monthly marketing budget on expensive advertisements and the visitors bounce quickly. I currently have $100 a month budgeted for marketing, which is a small allotment compared to other small businesses.

Best case, I think it's reasonable to hope for some traffic that leads to the features page and then to pricing. I don't expect that buying this advertisement will directly result in a sale.

Minimally, this will be my first practical step in learning how this tool works. I expect there to be some ramp-up time before I see any benefits of enabling the ads; this will give me time to work on the copy and design of the sales site.

Create unique, interesting content

My second idea to get traffic is that I need to create interesting or useful content. My immediate thought is to write useful blog posts (compare different release managers, or solve some common versioning problems). I also wonder how useful it would be to make some of my code available with a very liberal license. For example, a .NET implementation of HTML helper classes for Twitter Bootstrap classes. I might also open source my authorization library, but I want to shake that model out a bit first.

Concerning blog posts, I am going to shoot for two useful posts a week on the sales site.

I could also write a few how-to articles on other web sites to generate crosslinks back to mine. Contributing to Stack Overflow regularly might be a good idea.

In conclusion, IDKWTDLOL, but I need to stop coding. I'm going to give Google my credit card number and draft an ad campaign. I will also draft a new post for the sales blog, hunt out some open questions to answer on SO and create a how-to on wikihow. I will also fix the copy on the landing page because continual improvement will be necessary to make an effective site that I'm proud of.


1000 Days to start a successful software company

by alex 1. February 2013 21:42

Hi. My name is Alex.

Yesterday, my 5-year tenure as an employee of a multinational automation company came to an end. I filled many roles within this company, from providing personalized customer support to designing scalable frameworks and reliable, secure applications. We deployed code to customers with strict availability requirements, where an hour of downtime could result in hundreds of thousands of dollars in immediate manufacturing losses.

I learned a lot about how to write good software: foundations that can be extended and customized to meet the forever changing needs of the customer; applications that can be updated and patched without fear of breaking unrelated functionality; frameworks with API that can be cheaply maintained to continue to support applications compiled against legacy versions.

But, I found that a very basic tool was not available.

The team had code repositories to audit changes and to unite the group's collective code; we had a build script to automate the compilation and versioning of the software products; and we had a wiki to house documentation. But we used a folder on a shared network drive to store our releases. We had no way to associate change logs with our releases - the notes always got lost or if we put them in zipped archives with the builds then they weren't searchable. Our builds - the result of our painstakingly crafted and fiercely debated source code -- were left to rot on a network drive.

We found some products that offered solutions, but they were cumbersome. Many required detailed configuration that was more complex than trying to use tar. Oftentimes the product required full control over the application life cycle management - our team would need to learn a new version control system, a new item tracker, and a new build process. These software packages have a tremendous start-up cost and a high cost of failure.

This is why I left my job.

We needed a low-cost, simple release manager. We needed a tool to collect release, associate change logs and migration details in a searchable way. We needed a tool to help us avoid DLL-hell and to help us navigate the web of inter-product dependencies. From these needs Ginger was created.

Today is Day One of my 1000-day software business experiment. I have a functional and stable product, exactly 1 customer, and $0 in revenue. My goal is to bring this product to market and sell enough licenses to keep the company going (I'll get into this later, but at the current product cost and my current budget, that works out to 36 licenses sold per year). If I am unable to market my product well or if I fail to meet the needs of my customers, then in 1000 days my capital will have been nearly depleted and my source code will go to the highest bidder or to the open source community.

Let's hope that doesn't happen.

This blog is a meta-blog about running the company. What went well? What was a bad idea? I want to tackle topics of business management, taxes, SEO, customer satisfaction, marketing and branding and much more. I will do my best to help other like-minded developers shed their aversion to marketing and sales by providing data about my direct financial gains and losses based on my choices, good or bad.

That's the goal anyway. I hope this effort will be informative or motivating to someone. However, my next post might be along the lines of "OMG, Anti Chamber is the coolest game ever!"

I promise to keep the LOL Cats to a minimum.


About the author

Something about the author

Month List