Welcome! Matt from Marketing here. This is a different type of post than we usually do, so I wanted to start by explaining what it's about - and why we decided to write it.
RocketRez prides itself on our process of continuous product innovation. A large part of our product roadmap is generated by ideas and requests that come from you, our customers. However, we realize that the work that happens between feature request and feature release is largely unseen. We want to pull back the curtain and give you a glimpse into our development process. The collaboration across departments, and with our customers, is what impresses me most about this company. It’s driven by a group of exceptional people that I get to work with each day.
Hopefully you see value in a deeper understanding of how you can help to improve our software, as we continue to solve complex business requirements for tours and attractions. We encourage all of you to keep sending us your great ideas and features!
I’ll let my colleagues take it from here.
The RocketRez Process for Building New Features
“Ideally how this happens is that a customer is in the thick of their day-to-day and working in a part of the system they’re very familiar with. They will come to us saying ‘this is great but is it possible to add this.’ New feature requests really come naturally from working in RocketRez - and there’s no shortage of ideas.”
“The key to setting a good foundation is to truly understand what a customer wants from the request. You start from the end goal, then imagine all the scenarios. How should the system behave if this happens or that happens? We need to figure out what we’re building and why.”
“One very important question we ask is ‘if we build this - does it improve the platform for everyone?' There are so many outside factors that need to be accounted for. It takes a degree of imagination to anticipate these real-world nuances. That’s why working with the client throughout the process is invaluable. Sometimes you’re using your common sense - and sometimes you really need to dig a bit deeper. Call it a mix of art and science [laughs].”
“Once this hits Tier 2, there’s an analysis process where we try to figure if there is already something in the system that could meet this need.”
“RocketRez is a very comprehensive product with lots of code. As we’ve grown, we’ve built our support teams to specialize in different product modules. In Tier 2, having a comprehensive knowledge of the system, often we can identify where an existing module will meet the customers' needs entirely. If that’s the case, it's more of a training exercise to show them how to do what they want.”
“In other cases, there is a very clear gap that we would have to build from scratch to fill. That’s when we call in our Product Manager, Mercedes Peters.”
“When something comes in, there’s an initial priority level that gets set on it. We decide if it's something that needs to be addressed right away - or something that we’re going to have to slot in among any number of competing projects that developers are in the middle of [laughs]. Although we make great efforts to accommodate all reasonable requests, the reality is there are only so many projects the team can take on before the quality of all projects starts to decrease. We’re really careful not to cross that threshold.”
“I have a questionnaire that I have the CSMs go through with customers. The idea is that the customer is trying to solve a problem, and it takes a bit of work to identify what the problem really is. What they propose as a feature request is what they think is the best and quickest solution to the problem – but we want to make sure we’re getting to the root rather than putting a band-aid on it. What do you feel is missing? Has your team been executing a workaround? Is this something that is a ‘nice-to-have' or is it something that is a key part of your operation? These are the types of things we’re trying to understand.”
“Feature requests come in very, very specific [laughs] but our customer base has lots of overlaps in their day-to-day operations. We take some time and think about the problem and if other customers may be experiencing this as well."
“From there, Jad takes over and we start to figure out what this would look like.”
“I talk with Mercedes about the requirements and usability. Ideally this fits nicely within the existing user interface, but quite often it may need a brand-new UI. We don’t involve developers early on so that we can get a chance to see how it looks and how it works first. I create an interactive prototype that you can click through. This is where you might go “Hey, why is this button even here?”
“We’re trying to get ahead of developer questions that relate to design. After I do the UI and we test the design and flow, we often get the customer involved for a walkthrough. We start by testing it with the Customer Success team because they usually have the best handle on what the customer wants.”
“At the start, we’re doing some back and forth trying to figure out how long it’s going to take.”
“When developers get to building, they have to identify not only what parts of the system they’re going to be changing, but what reach that’s going to have into the larger system. We always want to make sure we keep an eye on quality during these cases. We never want to deliver something that breaks another part of the application.”
“While developers are building, they are talking to our customers, Mercedes and Jad, and the customer support team – doing whatever they need to get the information to deliver the expected result. We iterate as we go along.”
“They document all this and then give me an estimate of how long they think it's going to take. From there I schedule it and Mercedes lets me know how that aligns with the current roadmap.”
“This step can be described as an audit of the design. My goal is to ensure that the design was translated well into development. Quite often the development team runs into issues as they are building that I haven’t specified how to handle, so they will handle them their way.”
“If they have added in an element or function that wasn’t in the original design, I will check if it works properly and make sure it’s user-friendly.”
“QA stands for Quality Assurance, and it involves all activities centered around implementing standards and procedures to ensure that the software meets all our customers' requirements before it’s released to the public. The QA department serves as a bridge between RocketRez and our customers - with the aim to prevent bugs from getting into production, deliver reliable software and ensure consistent user satisfaction. We currently adopt an agile approach to our software delivery - pushing new features to production on a rolling two-week schedule."
"Our ultimate goal is to fully automate our regression testing (editor's note: this is testing usability of software after changes have been made, to see if performance has regressed) - which we are well on our way to doing. This will allow us to complete the process much faster!"
What happens next
Once we have ensured all opinions have been considered and all functional pieces of the new feature have been tested, we roll it out for all RocketRez customers to use! Celebrations are short lived, however, as in reality there is an eighth and very important step, which is to review, to iterate and to improve on every feature we send to production.
Building the RocketRez platform is a process of continuous improvement. Once we roll out a new feature, we immediately collect additional feedback from customers, solve for unforeseen challenges, expand the functionality and scrutinize the ways we can make it easier to use. Executing this process to the best of our ability has a compounding effect over a period of years.
A great wall is built by laying one brick at a time. A world-class platform is built by releasing one feature at a time.
If you have an idea for a new RocketRez feature, submit a ticket to our team here!