Inside Foundant – the Blog

From R&D – Through the Looking Glass

Remember your first flight? Whether or not we admit it, for most of us, it was probably interesting, if not exciting. And if the plane left on time, arrived on time, and your luggage made it, you were probably happy. The more often we fly, though, the more we notice little things that are annoying – lengthy check-in processes, less leg room, various surcharges, etc. The fact we usually can’t change these things only adds to our annoyance.

Working with technology in general and software in particular can be very similar. Initial experiences are interesting (remember the first time you browsed the internet, saw a favorite place on Google Earth, made a video call?), but the more experience you get, the more things you notice that are either missing or not working as you think they should.

As I’ve watched user participation in the community and talked to customer support and sales people here, I’ve gotten a sense of some challenges our users face when working with Foundant Grant Lifecycle Manager (GLM). Today, I want to take you “through the looking glass” so to speak, and give you some insight into our development process and discuss how you can impact our work on GLM.

In practice, the biggest challenge we and most other software development teams face is around process; specifically:
1. How to determine WHAT to build
2. How to ensure that what we build is RIGHT

Determining WHAT to build is challenging in large part because 1) there are a lot of stakeholders – sales, marketing, customers, customer support, and R&D itself; and 2) software is inherently abstract.  Unlike a bridge or a skyscraper, the model for software is virtually impossible to represent to users. Even people who work to define features have trouble understanding how seemingly innocuous changes can have complex impacts. In addition, for a lot of users, the most “concrete” part of software is the user interface (UI), and even experienced users can tend to think of the software as just the UI. The problem with this is obvious – a UI can look and behave correctly, but behind the scenes the software may be behaving in ways the user doesn’t expect and doesn’t discover until days or weeks later.

While I think in general we do a pretty good job of balancing the needs of various stakeholders, we are still making changes in how we determine WHAT to build. First, we are renewing our focus on Customer Experience (CX). Second, the Idea Lab and the community itself are forums for you to communicate your ideas and needs with each other and with us. The greater the participation, the easier it is for us to evaluate the input we get. For instance, if only one or two people post about a given idea, it’s hard for us to tell if they are a vocal minority advocating a feature for their specific situation, or if the idea has widespread, silent (and thus invisible) support.

Determining if something is RIGHT after it is built is complicated by a number of factors. In many cases, a number of features may have been combined into a single release. When many features have been built together, it’s possible they are interacting in unpredictable ways, which makes it even more challenging for testers to confirm that functionality is correct. Additionally, there are a variety of user types, and not all may have been considered when determining WHAT to build. While we may build exactly what was defined, when you start to use it, we may find out it is only right for a subset of users. Hopefully, ongoing Idea Lab discussions and continued involvement by all of you will help in this regard.

To do a better job of determining if what we’ve build is RIGHT, we are modifying our process to develop less, more quickly. Basically, this means that rather than trying to develop a lot of features in a bigger release, we’re working to develop just one or two features in smaller, more frequent releases. This approach helps in many ways. First, less development reduces the chances of unintended interactions, and it helps our testing effort focus on the things that have changed. Second, it makes it easier for you to give us feedback. Rather than being overwhelmed by a large (and more risky) release, you will be able to focus on just the changes we made. Third, it makes it easier for us to respond to your feedback more quickly, instead of trying to work it into a larger release that may be months away. Finally, this approach reduces the chance that we spend months working on something only to release it and find out it was wrong.

We’re committed to continually improving the quality we deliver to you, and as GLM serves more customers and becomes more feature-rich, we have to continually improve our processes as well. Your involvement in the community, conversations in the Idea Lab, and feedback are an important part of that improvement. We appreciate and look forward to your continued partnership as we move forward.