Software development aims to be a process, like building a bridge. First lay the foundation, then raise the supports, etc. Unlike building a bridge, however, there are no fixed goals by which to judge the product complete. Similarly, there are few fixed reusable components from which to build a new software bridge; we don’t have steel I-beams or specific recipes for concrete. Developers are renown for re-inventing components simply because the existing component didn’t quite work for their use case, and they could build something that solves the problem more efficiently. Nevertheless, software development needs to be a process to ensure that it bridges the customers’ problem gaps.
While software strives to be a process, it more closely resembles an art. Art dictates that in order for you to get better at it, you need to practice. You need to push out new products quickly and often, learning from failure and pressing on to learn and master your craft. Another similarity between art and software development is that success is entirely subjective. Just because one person finds a painting immaculate and sublime does not mean that the person standing immediately to their left feels the same way. In fact, they could fail to see the appeal. The same can be said for software. Just because a feature is designed to do something specific does not mean the feature is useful to everyone.
This is the duality of software development that has caused many software products to fail.
One solution to this problem is through iteration. Quickly fail and move on. If some people find value in a feature, keep that workflow but provide alternatives to others who are not finding value in your product yet. This is how software finds success and subsequently how customers find success.
Enter customer success. Customer success is a new field, and when something is new there are several opinions on how things should or could be done. This problem should sound familiar by now. With change expected in a new field, one question to ask is “how are your tools helping you to not just navigate this change, but adapt to it?”
The Right Process for the Job
With software development as both a process and an art, how do you blend these two seemingly perpendicular approaches to building a useful product? The answer is in Agile Development.
Agile Development is an iterative programming style that puts a time limit on software development. So a development team will have, say, two weeks to solve a problem, in part or whole, or exploit an opportunity. The list is developed through a combination of listening to our customers and to our own product roadmap. If we hear a customer say “I find myself looking for this information”, or “I really want to be able to track xyz”, then we know we have some work to do. At the end of the two weeks, development pauses and a product or feature is delivered. The key is in the next step of the process. After the product is delivered, we ask our customers if what we’ve developed meets their needs. To rephrase the question slightly, “will you, our customer, be successful or achieve value with what we’ve done?”
During the development iteration, we can be as artistic as we like in producing an outcome, but at the end of an iteration, the process dictates that we need to have met our goal. This allows us to adapt our product to the customers’ processes as changes in the field of customer success take hold.
Using this development process, Amity has successfully baked customer success into our product development lifecycle. If you’re a customer success manager, don’t you want to use a tool that makes your success not just its top priority, but a key criteria in declaring a new feature successful?
The Right Tools for the Job
While Amity’s software development process is designed with customer success in mind, there is also the lightly alluded to problem of common, reusable components. What is Amity doing to avoid re-inventing the wheel? That is a very good question and will be the subject of a future post.