As with any super-fantastic software company, we get requests for new features — be it added functionality, tweaking existing functionality, or as is the case with our new Payments feature — something that makes our client’s life a whole lot easier! But what REALLY happens when a client requests a feature? Does it go into a queue until they’re completed one-by-one using a FIFO approach? Do we pick and choose the best ones and forget the rest? Or do we hand them off to the “new guy” to take care of as part of their “initiation”? In this article we’re going to take a closer look at the life of a feature request here at Kashoo. And thanks to input from both our Development and Product Planning teams, we’ll demonstrate how a new feature is added to Kashoo — from soup to nuts. Our CTO, Chuck Clark, starts things off by detailing how we choose a feature: The Initial Request “First and foremost, Kashoo’s Development team reviews EVERY feature request we receive — be it from support cases with our Customer Success team or via feedback left on various software review sites. By listening to client feedback we’ve been able to enhance Kashoo with each update and new feature. Next, our Product Planning Team sits down to look at all potential feature requests. Some feature requests just don’t make the cut, and this could be a number of reasons, but typically it’s simply because the feature either exists in some form already, or the feature implementation wouldn’t be feasible with our existing framework. But for the feature requests that do make the cut, the team further examines them with the following in mind: Considerations Feature parity across platforms (web app, iPhone, iPad) Number of times a feature is requested (by different clients) Time to implement (development time, roll-out time) Required resources (manpower, support requirements) Cause/Effect analysis Potential roadblocks Vision of continuing to build out our foundation of an easy-to-use accounting software platform Once the team has selected a feature we then scope out the design.” Designing The first step in our design work involves Kashoo’s Product Guy, Amrik Randhawa, interviewing clients — usually clients who requested the feature. This helps our team gather more feedback, typically about use-case and design, but also to keep the dialogue doors open for when the feature is released. Who better to test a potential new feature than the client who suggested it?! Additionally, our development team creates storylines, as explained by Kashoo Code Monkey, Joel Andrews: “Oftentimes, we will write the stories in a barebones form (e.g. “As a Kashoo user, I want X so I can Y” ). So with our recent Payments feature, we had the request and coinciding story: As a Kashoo user with a business in Canada or the US, I want to be able to sign up my business for a new merchant account in my country’s currency so I can collect credit card payments using the same system that tracks my invoices and manages my business’ finances. Other developers get involved by writing a suite of Behaviour-Driven Development (BDD) “scenarios” that describe, step by step, how the feature/story should behave in response to certain stimuli (e.g. user interactions). Each story we use then progresses through an “In Progress” to “Ready for Testing” to “Done” stages.” Sounds like very scientific stuff, doesn’t it? After Design, it’s time for the team to put on their hard-hats and proceed with building. Building At this stage in the process our team targets a rough timeline for a release. While they’d love to come up with an exact date, it’s not something they can stick to due to unforeseen circumstances (new bugs, projects, impromptu Star Trek discussions). They also take time to figure out how the feature fits into our system, and if they can leverage any existing parts of the Kashoo infrastructure; ie: Can we use something we’ve already built or do we need to add something new? Our sky-diving developer, Dave Kichler, sheds some more light on the Building stage of the feature request: “The team writes code that both implements and tests the new behaviour of the feature. Once we’ve automated tests that cover the feature passing, we do a round of manual testing of the various scenarios just as a client would. If this all checks out and looks good, code changes are posted for the other developers on the team to review. Once the code is accepted, it becomes integrated into the master application and is now a candidate for a future release.” Releasing So how do we go about releasing a new feature? Do we just toss it out there and hope for the best? Of course not! Here’s some more input from Dave Kichler, along with the steps our team goes through for a release. “To clear the final hurdle and make the feature available to our clients, a release will be proposed for a given service or application. All pending release candidates (including bug fixes) are given another round of testing in our Staging environment before being cleared for final release into Production (the environment publicly available to the entire world).” Specific clients we’ve already spoken with may get a feature turned on so we can get feedback and see how they interact with it. This feedback is invaluable. “Beta” turned on for everyone, but we invite specific people to use it who we have usually identified in advance and most likely have spoken with. But it is discoverable by everyone. We try to look and see if the people who self-discover are able to successfully use the functionality. Public Release: Remove any “Beta” labeling and watch for challenges as the broader client-base starts using new feature. Public Launch: We write a blog, send an in-app chat announcement, and include it in our monthly newsletter. Address bugs and remove any potentially “confusing” aspects of new feature based on points 1 through 3 above. We love it when a plan comes together! In our most recent request-turned-feature, we received feedback from a client asking for a way to accept credit card payments in his existing accounting software (Kashoo) without all nightmares associated with setting up a merchant account. The above prompted Amrik (Kashoo’s Product Guy) to do some investigation into payment processors and we discovered WePay. From there it was further investigation by Amrik into how Kashoo could integrate with WePay: “When I discovered how easy it was to get a merchant account up and running without those “setup nightmares”, I knew we were on to something. From there, we got our Product Planning Team involved, scoped out the project and put it in “Beta”. We ran through storylines, rigorous testing, ran more tests, gathered feedback, tweaked the feature, tested some more, and finally; RELEASE! Now it’s a fully functioning Kashoo feature that allows clients to get paid quicker!” As you can see, a feature request does involve some heavy lifting and lots of nurturing. Feature requests aren’t as simple as adding some code here and there then releasing to clients. If we just rolled out any ole feature with complete disregard to our clients’ wants and needs, we’d be Microsoft — just kidding!
