Ideas from the team


Behind Our Product Development Process

How do feature requests and ideas become part of the Spektrix system? What's the thinking behind how we develop our product?

Balance innovation with usability

Our roadmap is informed in part by our clients and in part by our own team. We carefully balance innovation with usability, delivering cutting edge features and continuous improvements to the system. To do this, we listen carefully to the requirements of the market, understanding not only their functionality requests but also, and often more importantly, the goal they’re trying to achieve through that functionality request. It’s our job to find a way to use technology to meet those goals in a simple, intuitive manner that works with the wider concepts within the system.

Build on strong foundations

When planning out new features, it’s vital that every new feature works with the standardised concepts in the system so that it brings maximum benefit to our clients. It also needs to continue to work in the same way you’d expect from other areas of the system, building on the foundations of the system from both a functionality and user interface perspective. Take cross-selling, for example. We use standard concepts to make sure that the system can handle a number of cross-selling scenarios, based on how different venues achieve this. We've also designed this so that it works 'out of the box' with minimal set-up required, when other systems might require significant investment in customisation or web development to achieve a similar goal.

Planning how new features will work is like designing a huge jigsaw. For instance, we're currently planning some changes to our pricing and accounting functionality, although there are all sorts of different ways that different organisations want to set this up. The work we're doing in this area has involved gathering a number of scenarios from current users and potential users to design a solution that will fit all of them, whilst still being simple enough for users to configure easily.

Stay fluid and responsive

Our roadmap is fluid; it’s never set in stone, because we need to be agile enough to adapt to the changing technology landscape. To this end we work on a 7 week release cycle, as we believe in delivering continuous improvements to the system rather than infrequent step changes. This approach means we can be much quicker and more flexible to respond to the needs of our users. It also maximises our development capacity, allowing us to deliver a significant volume of new features and improvements every year. Sometimes, when we want to modify or extend existing features, this involves carefully working out how we can upgrade existing data to make sure that it will still work. Yet as we look to the future, we are confident that we have the most scalable platform in the market.

Whilst we only ‘ink in’ (i.e. commit) to the features we’re going to develop at the beginning of the release cycle, we have a robust roadmap that we have planned out for the next 12 months. The subsequent releases are ‘pencilled in’, allowing us to re-prioritise as we need, dependent on the requirements of our users, the wider sector and the changing nature of technology. Additionally, the reason we don’t commit to fixed dates against the 12 month roadmap is because sometimes we find that features are more complex once we start developing them and therefore take more time. Because we're creating new features that cater for new needs, we're often exploring uncharted territory in our development. When this is the case, we can only accurately know how long things will take once the R&D element of it has been completed.

Underpromise, overdeliver

We realise that the sector has often been let down by suppliers over-promising functionality and then either delivering an inadequate solution or not delivering something at all. We work to a mantra of ‘underpromise, overdeliver’ – we never want to be in a position where we have promised a client some functionality that we can’t deliver on. If we don't make our functionality deliver as widely as possible then we'll probably need to either adapt it or redo it completely in the future, both of which can be painful processes that we want to avoid.

It’s vitally important to us that we get our product development right, so that all of our users can reap the maximum benefit from our new features.

Are you a Spektrix user, with some more questions about our product development? Get in touch with us on to learn more about how we work. We’ll be writing a second blog post on this topic soon too, looking at how we write specifications for new releases, how we brief them into development, as well as how we handle testing, beta releases and QA.