Cookie Consent by Free Privacy Policy website

Iterative Development: Longer Development Cycle - Better Products

May 14th, 2014 - Posted by Jamie Thomson, Managing Director


RedTie has always been a SaaS based Web to Print software supplier and our monthly payment plans include software updates as standard. This can lead to expectation, amongst our customers, for new releases at regular intervals, however this is in actual fact not a problem when you base your development plan on customer feature requests. We have been developing Web to Print software for over 10 years and have a lot of customers who posess almost as much experience in using the software themselves so ideas for the future are constantly being submitted. Our development plans for RTT and RTQ are both exciting and healthily long.
A little over a month ago we released a new product called RTT Plus and we had to follow a development methodology that was different from the way we work on our established products. Typically our development process involves selecting the next feature we are going to work on, writing the specification for the feature, budgeting for the time required, scheduling, developing, testing, releasing to our customers so they can carry out testing and provide feedback and then releasing to the live code. It is a process that works well for incremental feature releases and at any one time we have 3 or 4 of these features at various stages of this development cycle.
RTT Plus however is not an incremental feature; it is a new product in our Web to Print software line up. It was a much bigger project than a typical feature for our other products and the idea came about more as a result of listening to our potential customers rather than our existing customers. You may be aware that RedTie runs a lot of educational seminars about taking print online and in the discussion section of those seminars we are constantly getting feedback on what printers want. The plan for RTT Plus was born out of those discussions.
In software companies you will often hear the term Minimum Viable Product (MVP) which is used to describe the minimum amount of features that need to be developed for a product to be useable. It doesn’t have to be fully featured and can be used for internal and external feedback. On large projects it is very useful to get something in the hands on non developers as early as possible, potentially saving a company from producing something that customers do not want. Our MVP RTT Plus arrived at the end of 2013. Some companies may have released it for sale at that point, it was fully functional, however we felt that because it was going to be released alongside some very established products we needed to give ourselves enough time to ensure that version one would be something that could make money for our customers money right from its launch rather than just a technical demonstration.
As a result we took the product out of the developer’s hands and started to use it internally and the feedback started to flow almost immediately, from functionality to user interface, nearly everything in the software needed improvement. This is where the iterative process really began, the developers made updates, based on the feedback, which were then released internally for more feedback and over a number of cycles RTT Plus was transformed from something that worked to something that worked really well.
Obviously this added to the development time and in fact made the release date hard to pin down but the resulting product was certainly much more than a MVP. Towards the end of March we started to receive feedback from our customers and with each iteration we further improved the release version. 
RTT Plus was fully released in April and is now in operation with a growing number of printers. You can read more about it here or to discuss your requirements and arrange a live demo get in touch by any of the methods on the Contact Us page.