Blog homeOne of the balances that I am constantly weighing up is what to do with new functionality requests. These requests tend to fall into one of the following categories:
- A request that, if not undertaken, will mean we will lose a potential customer
- A request that, if not undertaken, will mean that not only could we lose an individual customer but also an entire group of customers with similar needs
- A request from an existing customer that needs the functionality in order to run their business
- A idea we have had
When I first started down the route of investing in creating a web based reservation system (2003) the needs were very simple. Therefore the functionality that was implemented wasn’t much more than an off the shelf ecommerce shopping cart that handled date related availability. In comparison to other travel systems, we are probably still very straightforward (because we have to ensure small tour operators can set it up themselves without needing help from us)
However now we have a system that has grown organically with many more features than we had at the start. With these features has come increased complexity.
A couple of quotes from customers summarises our problem nicely:
I like all the new functionality and now couldn’t run our business without it. However if you look back at what we ran our business with in 2004 we probably don’t need this new functionality
…and…
This system is too powerful with too much for us to learn
…and (from our client testimonials page)
We chose your system because it is not full of features that hardly ever get used
So you can see what the challenges are…… and it is a fine line that has to be constantly evaluated
- Do you turn down a functionality request from a new customer and instead concentrate on finding customers as similar to existing customers as possible?
- As a salesman, would you “just do this little change” in the hope of gaining a new customer- but in the knowledge that you are making the system more complex than necessary. This could cause long term damage for short term gain.
One of the problems with many of these requests from potential clients is that often companies buy systems based on a feature set that they think they need - when actually they probably only need 60-80% of them. I remember a project for a large UK tour operator I was involved with last year (while doing a bit of consulting on the side) where there were over 400 individual functionality requests for a reservation system….. which I summarised down to 30 or 40 business requirements that were much more understandable.
I still haven’t quite worked out what the best approach is - except to look at developments on a case by case basis. This, as a strategy, isn’t ideal and I am sure people cleverer than me could come up with a better way of solving this dilemma.
If you want to be notified next time something is published sign up for email alerts or subscribe to the RSS feed. Thank you for reading!
