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”¦
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.
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.