The first time I built an application was when I was moonlighting on database application development. In this case, the customer had space in their office where I worked. I could engage one of the users of the system any time and have them provide immediate, direct input as I went along. We rolled out the application and it proved nearly unusable. Because much of the design evolved organically focused on the details, the overall system proved unusable.
A lesson on context
I ended up discarding much of the work we had done and starting over. This time I now understood what the customer was trying to do. I also had seen firsthand how building features without a strong sense of context could create a system that was very difficult to use. I started to work in the off hours when the office was empty. Then every few days engaged directly with the customer. This ultimately proved successful.
My early programming experience in many ways mirrors that of the software industry. New methodologies have been developed to develop applications that respond to a customer requirements in a productive manner
The redesign of RSuite 4 provided the opportunity for us to also revise our product development methodology. We now use the Agile methodology with shorter design cycles and more frequent updates so that product development efforts are validated quickly.
Agile allows us to be more responsive to customers. Instead of developing for months or years before putting development in the hands of users, AGILE dictates shorter development cycles usually measured in weeks. Priorities can be shifted rapidly if needed. Unexpected issues that might derail the timeline in a long development cycle are now incorporated into the normal product engineering routine.
Before beginning the redesign we launched a new community support site for our customers. This site handles the traditional support issues and made it much easier for our customers and support agents to track and resolve issues. It also serves as a “database” that the product management and engineering teams can reference when prioritizing new development.
A corporate memory of customer issues provides a historical backdrop to better understand areas that challenge users. Active, unresolved issues can also be evaluated immediately. At times we will identify an issue that we are in a position to address quickly. Already we have made UI changes that may not have been formally brought to the team’s attention. Potential product improvements may be discovered whenever a customer contacts support to use a feature.
The support community also offers customers community forums. Documentation as well as formal and informal information about RSuite can be found in our forums. Some forums are entirely made up of official information from us. Other forums are dedicated for customers to make and comment on suggestions, request advice, or offer their feedback to other customers or us. There are forums for both end users as well as integrators and developers. Having this communication available is a valuable source of direct and indirect feedback for us.
Implementations of RSuite are also an important input into the product. We review implementations, conduct customer visits, and also host an annual conference so that we can maintain engagement with our customers and understand how they are using the product. Regular meetings occur between product management & engineering and the project managers. RSuite imposes no theoretical limitation on how the product can be extended. When we look at how solutions were implemented, we sometimes identify things that will help improve the efficiency of future projects. We can also verify our best practices are being followed and determine areas for improving communication.
Customer feedback is an important consideration in keeping RSuite’s evolution responsive to our customers’ needs. Users of software may have suggestions about a specific product modification or addition. Sometimes these suggestions can be implemented as requested. To be sure it is important that we also understand the motivation and requirements behind the request. We must then consider the best strategy to address that need. Sometimes that may not exactly match the initial request. But it will likely lead to a superior result if it is contextualized with a broader product vision.