.png){kind=small}
Software versioning should be a straightforward practice. It’s not exactly something that you usually associate with anxiety, but that changes when you are a growing software startup.
When we decided to take our product in a different direction, our software version was 4.4.0.
For the first version of dablr, the version was 4.4.0-a.
By the time version 4.4.0-f rolled around, we were intent on releasing it to our customers. We faced technical challenges (as we all do) and attempted again with version 4.4.0-h.
At some point I looked away and it became 4.4.0-x (x in this context is not the math symbol, but the 24th version of our software).
Several sprints later, it became 4.4.0-zc.
Don’t get me wrong, the software version in of itself wasn’t the source of my anxiety. It’s what it represented. If you’ve read any book about growing a startup, you would know that what we were doing is considered to be a cardinal sin.
The longer it takes to release software, the longer customers are not using your software and are unable to provide feedback. That invaluable feedback could save you both time and money in wasted development efforts building something nobody asked for.
To our credit, we did reach out to different groups to test our software during this period, so weren’t completely feedback-less. That isn’t to say that there weren’t valuable lessons to be had.
Lesson 1: The principles behind the Lean Startup is useful, but not in all situations
Books like the Lean Startup are great for when you are starting from scratch. Our situation was a bit different, in that we are a B2B business that already had an existing base of customers. Our customers had already paid for a product that was of a particular standard, so introducing new complex features wasn’t easy. We had to find different ways to simplify a feature, enough to demonstrate what it was capable of, but still ensure that it matched the rest of the platform and remained as bug-free as possible.
For example, our Analytics Workflow feature was developed to help guide business and data analysts alike to complete different analytics tasks. There are a large number of tasks to consider, but to get it up and running, we focused on one or two tasks that would showcase the functionality the best. We then spent a decent amount of development effort ensuring that it worked seamlessly with other highly-used features of the platform.
Lesson 2: There will be bugs, so good customer management is key
Bugs are an inevitability. You can test and test and test some more, but there will be a point where you have to rip off the band-aid. For a business like ours, it became a customer management exercise to ensure that the introduction of new features went smoothly, and to manage the customer’s expectations if they didn’t.
We sent emails, wrote FAQs, recorded how-to videos and scheduled in as many meetings as possible (without bordering on annoying) to ensure that our software release would be successful. Sure, it didn’t quite go according to plan, but all of the issues we faced were mitigated by the relationships that our team had built with our customers.
Lesson 3: Don’t be afraid to get your software into as many hands as possible
Feedback from users actively using your software is considerably more valuable than independent users testing your software. Don’t convince yourself they are the same. Independent testers will be prone to liking the idea or concept of a feature and be less critical of whether the feature will actually be useful to them to use on a day-to-day basis. Whereas, active customers will be far more comfortable telling you if something does not work.
At this point I’d like to say that I’ve learnt my lesson, but it’s probably more accurate to say that it’s a work in progress. At the very least, I now know that it’s okay to take a bit more time to make sure that our product will still be of high quality for our current customers, but that it’s not okay to take too much time because you’ll start to ask questions like, “Wouldn’t this feature be better if it has x?”, and the eventual answer two months later will be, “No, turns out gamification wasn’t really necessary here.”
Good news is, I’m happy to announce that we are no longer using letters in our software versioning and we’ve settled into a more stable development pattern (it only took us 29 versions to get there!).
