For this chapter, we spoke with Ethan Blades from ServiceSmart, an application that helps car service centers track their automobiles more effectively.
Gunner Technology: It seemed like ServiceSmart was growing and improving every single week.
Ethan Blades: It was frankly incredible. We went from idea to launch to multiple, fairly major overhauls in the span of a couple of months. In the auto service industry your customers expect to work quickly – their car is their life in a lot of cases. So being able to have a similar arrangement with the development of this app was a true gift.
GT: I hadn’t really thought of that! Agile, in a lot of ways, which you’re well familiar with now, is sort of the project management analogue of ServiceSmart for car service.
EB: And that was the goal. We wanted a system where customers knew, every single step of the way, what had already been done with their car, what was currently being done with their car, and what would be done with their car in the future.
GT: That’s Agile in a nutshell.
EB: It is. And it helped our project tremendously. This was my first experience with Agile and seeing new stuff every week. Usually you just give your requirements to developers, they go off for a couple weeks or months, and come back and say, “Here.”
GT: Which isn’t the best.
EB: It’s the worst! Because there are always so many issues. And they’re issues that you could’ve caught and fixed while they were working on it. And some of it is minor and easy to fix, but a lot of times we’re talking about major changes. And that leads to cost overruns and missed deadlines.
GT: And nobody likes that – especially in the car service industry!
Gunner Technology is an Agile shop. Always has been. Always will be.
The reason we love Agile (and why you should too) is because it makes it so much simpler to update your idea. And in this age of rapid progress and constant change, the ability to update your idea is paramount. If you’re not keeping up, you’re falling behind. You can’t just ship it and be done like you used to be able to. Those days are long gone.
One of the biggest perks of using the Agile approach is that you’re constantly rolling out updates. At the end of each iteration (Agile’s term for a period of work, usually one or two weeks), you have a working piece of software that you can deploy live to production.
It also lets you handle necessary updates when your audience really starts to grow. You can easily push out changes or optimizations to handle the increased traffic. Your app will no longer be brittle – it’ll be ready to handle whatever gets thrown at it.
Another huge perk of going Agile is that everything is documented with user stories, which are little descriptions of pieces of functionality. For example, “As a member, I would like to upload a profile picture so that I can customize my home page.” (You always include the type of user, e.g. “member”, “admin”, what that user wants to do, and why they want to do it.)
With a huge backlog of user stories, you can easily handle user feedback, prioritize items, determine budgets based on timelines and the amount of work each user story will require, branch into separate teams to work on different pieces of functionality, and a whole host of other benefits. Agile really is the only way to go.
Feedback, both user-driven and automated, is critical for your application.
One thing your application has to do is capture bugs automatically. This means that whenever something goes wrong with your application due to an internal error, you should automatically record that issue with whatever project tracker you’re using. That way you keep on top of bugs and fix stuff immediately.
For user feedback, you should have a mechanism set up like Zendesk where users can let you know when something doesn’t work (or doesn’t work as intended or as they imagine it should). You can also use a simple Google Form as a low-budget feedback mechanism.
Feedback from users is crucial. It’s honestly more valuable than feedback from internal beta testers because the lack of familiarity with the product makes user feedback truer to the general experience. Often beta testers get too familiar with the product and your team doesn’t know how something isn’t working.
Plus general users have more direct requirements for how the application should work based on the model they build up in their mind. So instead of telling them how it should work, the imagine to themselves the optimal way your application should function, and if your app doesn’t meet those expectations, users will let you know about it.
And you should constantly ask for feedback from users to improve the final (or ongoing) version of your product. This might be directly asking for feedback or sending out a survey periodically. And you should make feedback mechanisms like Zendesk or your Google Form readily apparent to users so they know they can always get in touch with you with comments or complaints.
One thing to keep in mind with feedback, however, is that users aren’t always the best at communicating what they want. You often have to push them for specifics and to make sure you fully understand what they’re asking for.
Also, users can get frustrated, and a lot of times they’ll leave extremely negative feedback in the heat of the moment. You can’t necessarily take their anger at face value, but you also shouldn’t dismiss it because there might be something actionable therein.
Another issue you’ll encounter with user feedback is when that feedback doesn’t align with the ideas of investors. Investors often have incredibly strong opinions about the product and don’t want to hear about it when the users want something different. You’ve got to walk a fine line convincing investors that the users often know better than them what the app should do.
One piece of communication that’s especially important is communicating changes to the users. If you’re rolling out a huge update, you’ve got to have some sort of notification mechanism set up to let users know. You don’t just want to spring it on them and face tremendous backlash like Snapchat dealt with.