Three lessons learned from my early days of releasing software

Posted: May 7th, 2010 | Author: | Filed under: posts | Tags: , , , , , , | 1 Comment »

The other day, I received a call from a user of one of the software products I developed, back when I was running my own web development consulting firm, Shedd Technologies International. In addition to doing pure client work, there were several products that I packaged up and made available for use – some as freeware, some as commercial software. It’s been many years now since the products were actively developed and I was impressed to hear that they’re still proving to be useful.

The call provoked some thought about what I learned from the process of developing and supporting a set of packaged software products. This is a fairly long post – it’s part reflection for me, though I would think it would be also be potentially useful to any other young entrepreneurs looking at building software products.

We all have so many different experiences in our professional and personal lives. It’s really only after these are over and after you look back that you start to see what you learned from the experiences. There’s certainly a lot of value that you can get out of taking a look back, though, and this is a process that I’m going to try to do fairly regularly going forward. Especially with startups, the day-to-day is so crazy, I think it will be useful to take a step back every 6 months or so to reflect on what we’ve learned, what worked well, and what we can improve upon. But for now, here are some reflections and lessons learned from the start of my career with technology on the web”¦


 

Background

First, the background:

Not long after starting consulting work, some client project work led to several pieces of software being developed, which lent themselves to release as packaged products. For a site needing a photo gallery, I developed the code that became a simple script called PhotoGal. Another client needed an affiliate management system and this was extended into Affiliate Manager, which was because a commercial product that I sold under a consulting model ““ base license fees + fees to install and adapt it to your individual business. There were also two products other products developed, as well, which were not extensions of consulting work. Support Services Manager was created as a helpdesk tool for internal use, but was released and really only used by external users. DLMan, a digital product delivery system, was perhaps my most concerted attempt to develop a packaged product.

There are a lot of lessons that I can pull from this work. As a whole, my software products were moderately successful, depending on your metrics. While it’s hard to estimate the actual installed base, Support Services Manager (SSM) was widely downloaded with more than 20,000 downloads, in addition to being packaged into the Fantastico web-hosting control panel tool. PhotoGal probably had around 5,000 downloads. For the commercial products, it’s much easier to gauge, because of sales figures. Affiliate Manager had a small user base, seeing use with a handful of clients. DLMan was more successful, at least in terms of revenue.

DLMan took about a week of development effort to build out for the first release and went on sale for $45/license + additional charges for installation and extension modules. If I was billing the development time at what was my standard consulting rate, the product would have roughly broken even. DLMan did drum up a steady business in related consulting, modifying the product to suit a variety of purposes and industries and this business certainly helped make the product worthwhile.

Certainly, in terms of users or sales, I didn’t have any blockbuster successes. Still, the process of developing the software, supporting it, and learning what users really needed was most important, though, and gave me a number of lessons that I have pulled from as my career has progressed.

At a high level, developing the software gave me a better understanding of what it takes to write a system from scratch and made me a better consultant with this ability to look at systems with a deeper perspective. Supporting the software also put me in touch with the people actually using the code and showed me a whole host of new considerations to take into account when building products, along with the value of actually speaking with customers. I also gained experience with pricing, discounts, sales, and numerous other important points. But perhaps most important was that I learned about what’s really critical in terms of releasing software.

 

Lesson Learned #1: Being Open

Being young and naïve, the products were all released under a fairly restrictive license that I wrote myself. I wanted to keep people downloading the software through my site and was unsure what opening the code up under a full OSI-compatible license would have meant.

This is something that I still see today. There is this instinct, that because you built something, you want to hold on to it and try to find some way to benefit from it.

In retrospect, the better road would have been the open source road. While I was concerned about keeping control of the code and limiting modifications, this was counterproductive to what I should have focused on – increasing adoption and getting the code into the hands of users – building a community around the products. As mentioned above, much of the revenue generated from these businesses was actually in the consulting work and customization of the initial products. Not only would this not have been affected, it probably would have increased, because adoption would most likely have increased from having a less-restrictive license. As a result, being open probably would have had given a nice benefit to the bottom line, in addition to being the right way to do business.

 

Lesson Learned #2: Keep Updating

Looking back, the markets that I got into were good choices and the products were well timed. SSM came out about 6 months before PerlDesk (one of the most popular helpdesk scripts at the time) and its integration with forum packages was something that distinguished the product (and drew a userbase). DLMan didn’t really have many competitors upon release, though a SaaS-based offering was released soon after (which was before many of the digital-download enabled shopping card packages).

After the fun of building a product was over, though, and having lots of new ideas, I was usually ready to move onto another project. I would still actively work with users needing help through the forums, but in terms of new releases, they were very rare. Other offerings coming into the market combined with sporadic updates to my software was not a good combination and led to a declining userbase.

 

Lesson Learned #3: Remaining Focused

Following SSM’s release, I kept looking at new competitors that were emerging and their larger feature sets. The one SSM competitor that was really noticed was PerlDesk (as mentioned above). I’m not quite sure of the exact cause, but PerlDesk got a lot of attention following its release and gained a big following. The feature set was roughly the same at the outset, but PerlDesk kept releasing and adding new features. There was a lot of temptation on my part to match their additions at first, but then the gap got quite large and I lost my inspiration for the project.

Rather than suffering from feature-envy, I probably should have gone the other direction and kept SSM as a streamlined, optimized helpdesk tool. One aspect of 37 Signals’ Getting Real methodology that really resounded with me was the focus on getting something useful out to the users and keeping the feature set lean. Most of the features competitors had were nice, but not essential. Creating an effective core product that worked really well, and then working as hard as I could to listen to customers, would have been far more effective than succumbing to trying to match competing products feature-for-feature.

 

Retrospectively, there were certainly many choices that I could have made differently which would have probably resulted in a more effective product strategy and increased adoption/success. Still, the work certainly proved its value in terms of building my core consulting business and also teaching me a lot about critical success factors for software products. My overall product strategy was decent, at least in terms of market timing, since I found real need in markets that heated up soon after I entered them. But the most valuable thing I got out of the experience was learning how to take a product from concept to functioning software, satisfy customer needs, and what worked/didn’t work in terms of making that product successful. For that, the experience was highly useful and I’m glad that I had the courage and foresight at the time to take advantage of it as much as I did.


Create Opportunities for Yourself – a story of Excel and startups

Posted: May 3rd, 2010 | Author: | Filed under: posts | Tags: , , , | 1 Comment »

As a consultant at IBM, there was one particular project where we needed to validate the financial calculations in a huge data set. The end result was a detailed Excel workbook with a number of financial calculations, all extracted from an extensive series of pivot tables. The data was being generated by an automated process and we needed to compare the output against a model. The process proved to be fairly laborious. About 15 data files were generated per test run and each data files took quite a while to prep and validate. To illustrate this a bit more clearly, in order for the process to work, the formats needed to be brought into Excel, data types converted, a pivot table generated, and then the pivot tables compared. This had to be completed essentially twice, once for the model set and once for the output set we were testing. Each run of the process took hours – needless to say, it was fairly tedious.

Looking for an opportunity to help, I took ownership of this process and, after realizing the tedious process wasn’t going away, started looking for an easier way to get what we needed. I had used Excel quite a lot beforehand (for various financial spreadsheets and projections, etc.), but had never used it as a development platform, to handle complex data analysis. Still, Visual Basic for Applications didn’t seem too bad. I started to automate the process – step by step. The first part that I automated was the generation of the pivot tables. That was easy enough to do with the Excel macro recorder (otherwise, the VBA code for pivot tables generation can be a bit hairy). That helped speed things up, but I thought, why not go further. So I automated the conversion processes. And then the data import processes. And finally, the process to compare the data sets and generate the workbook deliverable.

The end result was a process that took at least 8 hours on a good day was cut, step by step, all the way down to about 13 seconds with a series of macros that I developed and then integrated. The process also went from being something that needed extensive step-by-step instructions to something that could be run with a click of a button. I also changed a workstream that was mind-numbingly tedious into an opportunity to broaden my experience with using Excel for complex analysis tasks.

So, not only did I gain a ton of experience building complex, automated models in Excel, I produced a deliverable that could be reused on future IBM projects, as well as a tool that the client was able to make use of going forward, as well. Not bad for something that the team didn’t realize they needed originally and that I was able to assemble piece by piece. (It also established me as the Excel guru on my team, so I was quickly given another financial analysis process to implement in Excel.)

There is another story that further illustrates the topic. When we were starting out with FanGamb, I joined the team to build and run the product development team, but I was also very interested in using the FanGamb / DreamIt opportunity to expand my own experience. I knew the product areas well, but wanted to get more exposure to some of the business operations. I had some experience from running the business operations of my consulting firm in high school/college, but wanted to dig deeper. Fortunately, there was an endless amount of work that had to be done. I took ownership of many of our financial operation tasks – maintaining Quickbooks, working with the accountants, setting up payroll, working with my co-founder on the financial projections… Sure, it added some work to my plate, but it also really broadened my experience from just being the tech guy to someone who has a better handle on the full operations of the business.

Startups are particularly good opportunities to take on tasks that might not be your core area of focus, but give you enormous experience. Not only is there’s an awful lot of work to be done, but unlike in the corporate world where you need to be essentially given permission to work on a task, startups reward taking initiative and ownership. So, you get to create opportunities for yourself to gain experience in the areas that you’re interested in. This is a key reason why startups are such a fantastic opportunity for new grads.

The lessons that I took away from all of this? First, figure out what areas you want to grow into – what additional experience will complement your existing skillsets? Are you a tech guy looking to gain more exposure to the business side? Is your past experience mainly in one area and you’re looking to have a broader base from which to run your own startup one day? Set some goals for yourself.

Then, set some expectations for yourself. You’re looking to pick up some additional experience, not become an expert overnight. You’ll have the temptation to want to tackle everything at once. The IBM Excel task, for instance, was so tedious that it would have been easy to want to build out the entire macro set at once. Instead, I took it slowly, building out the pieces iteratively and integrating it as I went. I think this is the right way to go, lest you become hung up on an issue or get discouraged.

Finally, be open to opportunities that come your way (or that you trip over in the dark). You may come across different things that if pursued turn into significant opportunities for you. An opportunity to create a web site for my Boy Scout troop and another local client opened the door for a hobby in web design to shift and become a consulting business. Building web pages for clients then shifted again and became an opportunity to work with international subcontractors. A big part of creating opportunities for yourself is leaving yourself open to them and running with different leads to see what works out.