6 minutes read time
Like most SaaS companies, we use the Agile framework to develop features and release them into the wild.
We’ll get a customer request for an enhancement and it will go through to the Agile team, who will then decide whether or not we’ll build it.
If yes, we’ll include it in the backlog, formulate a sprint, test it, write up documentation, and release it into production.
But it’s not how we build the features that’s important, nor is it the speed to market, or the efficiency or our development team… it’s why we’re building them in the first place.
And sometimes even if you get the “why” right, you can still get it wrong in development… as our Head of Technology, Tom Peck, learned in 2018.
We chatted to Tom Peck, Head of Technology, to hear about some of WhosOnLocation’s ups and downs in Product Development.
TOM: It would probably be “Inter-Zone” (April, 2018).
As a bit of background, when we’re developing WhosOnLocation, we have to consider MLP (Minimum Likeable Product). What this means to us is that to release something that is bare bones it still has to be complete and be “liked” by our customers. It can’t be something half-baked. On the flip side, it shouldn’t be so over-engineered that the release is overly complex and people struggle with it.
“Our team were so focused on having their heads down making sure existing Kiosks continued unaffected by the release that we failed to see the complex beast that we had created.”
TOM: So yeah, unfortunately with our “Inter-Zone” release, we went down the over-engineered route. What started off as a simple improvement to Kiosks (to allow for people who are currently on-site to switch zones via an Inter-Zone Kiosk) ended up being a massive rebuild of Kiosks, a complex data migration and an introduction of sophisticated zone-based rules to the mix.
Funnily enough though, as time went on we started to realize that Inter-Zone actually fixed a lot of bugs. As with all software development companies, we have a backlog of bugs to address.
The development of [Inter-Zone] spanned many months, numerous sprints and multiple workshops. After the release, as we started working through the bug backlog, we found a number of them were no longer reproducible and were therefore “fixed by Inter-Zone”. This phrase has stuck with us with and become a meme for any bug that can no longer be reproduced – “perhaps it was fixed by Inter-Zone?!”
TOM: The Inter-Zone release was met with excitement but also some confusion by our existing customers. Not only had we introduced the concept of “Inter-Zone” we had also introduced the concept of zone-based rules – allowing a Kiosk to be configured with a specific set of questions based on the zone and location a guest was visiting. Our team were so focused on having their heads down making sure existing Kiosks continued unaffected by the release that we failed to see the complex beast that we had created.
Upon reflection and after receiving a number of struggling customer queries, we took a step back and with a few small tasks we were able to revise the setup and configuration process, greatly simplifying the interface.
TOM: I would actually have to say that our best feature so far has been Inter-Zone too. [Laughs]
TOM: Once we learned from the initial release and ironed out the issues, it’s actually been a really successful release. We knew our customers wanted it, and they were really excited when we initially released it. It was just too confusing. We can tell it’s working a million times better now by the number of queries and requests for support, and by the kinds of things our users are asking.
It’s also just objectively a much better user experience. We realized we had been looking at UX “frame-by-frame” rather than considering the user’s journey through the whole feature.
TOM: Several iterations later we definitely believe so! This is why we love what we do. We can release, take a step back, gather feedback, iterate, release again and repeat. You can’t get it right the first time, every time!
Ultimately, our product boils down to 3 key benefits for users…
And every feature we build must give the users value in at least one of those key areas.
For example, we have recently released ID Scanning. The benefits of this feature are:
If lots of people request a feature or product, that’s a really good indicator that a significant chunk of our customers will use it – the higher the benefit and customer demand, the higher priority.
Where we can, we’ll also include some customers in the process to get feedback on user experience as we go. Sometimes, if we’re considering building a big feature, we’ll survey our users before we begin the process to make sure we know what they want.
The success of a feature can be measured by the number of people using it, and the reported impact of the feature (direct from customers themselves!).
When possible, we’ll ask our users what kind of impact our product (or a recently released feature) has made for them.
“Using WhosOnLocation has saved me at least 4 hours a day, the ROI speaks for itself”
– Shanyn Fox, Facility Contract Coordinator, Gold Coast Private Hospital
On the flipside, if the feature has low usage or we’ve received complaints or questions from confused users, we know there’s still work to be done.
And as we’ve learned, listening and reworking can bring back almost any feature from the reject bin!
WhosOnLocation provides people presence management software that monitors the safe and secure movement of people through buildings and work sites. Our powerful, cloud-based solution unites visitor, contractor, employee, and emergency management, enabling organizations to secure their facilities and ensure the safety of every person on-site.
Armed with a rich, unified source of people presence information, our users are empowered to make more strategic, data- driven decisions that mitigate risk, reduce overhead costs, and streamline operations.
WhosOnLocation serves organizations in 35 countries around the world, and manages over 13 million secure movements through thousands of locations each year.