by Faraz Javed, Senior Full Stack Software Engineer at eddress
Deciding whether to add new features can be a painstaking process for software engineers. Customers often make suggestions, but their ideas can fall short of the mark.
Added to this, you need to weigh the business value of new features against the complexity of implementing them. There’s always a tradeoff between cost, quality, and speed. And all this needs to be done without complete information.
Can you relate?
In this article, we discuss our approach to creating new application features. We cover how we prioritize ideas and why we believe some implementations are more important than others.
Adding a new feature: the process
Adding a new feature is actually a lot of fun. It gives us a chance to work creatively and make our clients happy.
The new feature’s birth
The app feature development process can begin in two different forms: with the client’s request, or generally from our product team. Indeed, we have a dedicated team that draws a product roadmap in alignment with studies and market research, which provides our partners with a set of features that would be ideal to develop over the course of 2 years.
On the other hand, If we receive a special request from the customer end, they will send their suggestions to their Account Manager who then forwards them to our backend team.
Assess the business case
No matter the process in which the feature has been communicated, we assess what we call “the business case”. The purpose of this is to figure out why we should implement a particular feature at this particular time. What value does it add to our client’s customers and their business as a whole?
If the value proposition isn’t there, we scrap it. There’s no point wasting our partner’s money. This policy marks us apart from most software developers. We don’t just take company cash to satisfy sales requests. Instead, we provide a partner-based, consultative approach, telling clients whether features add value or not.
For example, a feature that increases bulk orders is a win-win. It’s great for customers because it helps them access cheaper prices. And it is good for businesses because they can ship higher volumes and clear their inventories.
Evaluate the new feature’s priority
Next, we consider whether the new feature is a priority so we can organize teams accordingly. If it is, we consider it for immediate development. But if there are more urgent projects waiting in the wings, we prioritize those instead. We build new features that are necessary to the development of the client’s business and the value of their customers having access to it immediately.
To do this, we engage in “what if & then” sessions (a coder’s dream). Here, we run through all the possible alternatives to installing a new feature and how they might pan out.
No suggestions go ignored. But we do prioritize. Features that meet our guiding principles go to the top of the list, while those that don’t are put on the back burner.
In many cases, certain features are more important than others at particular stages of a business. For example, it makes sense to introduce discount pricing features after integrating payment methods.
There may also be strategic reasons for implementing a suggestion sooner rather than later. Perhaps a competitor is bringing a new feature to market and you want to beat them to it. Or maybe technology is about to change, and you want to be a first-mover.
Features that promote sales directly should also go to the top of the list in our view. Going back to the above example, we prioritized the development of the bulk discount feature because it had the potential to increase volumes. Customers would get money off with larger purchases, and companies could move more stock. Therefore, it made sense to implement that feature.
Begin design and prototype
Once we have a clear picture of what we need to do, we then start designing the solution. Customer feedback is an important part of the process for us. We share our best recommendations on how we envision the new feature and get additional information on what they want it to feel like. It’s a two-way process, like any partnership.
After collecting this information, we explore several implementation options, keeping the brand’s identity in mind. Features need to be easy to use but also recognizable.
Write the code
Next, comes coding. To do this effectively, we divide up the work into chunks. Multiple teams carry out different tasks to improve efficiency.
Throughout the experience, we keep our clients in the loop. For example, we show them our progress and give them various demos. They then provide feedback and tell us if we are going in their desired direction.
Our discount feature is a good example of this in practice. During development, we shared our progress with our clients. They then provided us with their insights which in turn allowed us to save time for both eddress and our partner.
Test the code
Next comes testing. Here, our quality assurance team ensures that the new feature does what we planned it to do.
They begin by testing the feature specifically. Then they test whether it works in the context of the whole application.
If they give us the thumbs up, the feature is ready to go live.
Deployment
For us, deployment begins with releasing the new feature to a small group of users. This way, we can test stability and performance.
Then, if the risk looks manageable, we roll it out to more customers. This way, we can address both immediate and scale-related issues.
We implement three different approaches for rolling out new features at scale for clients:
- Operating System-Based: Only rolling out on iOS and Android
- Version-based: Only enabling features on a specific version of the app
- Operation-based: Independent activation of new features, based on client requirements
Evaluation
The last step is evaluation. In this step, we ask ourselves what we learned from the experience. Was it worth implementing the new feature? Or should we have taken a different tack? All takeouts are well examined and serve as benchmarks for upcoming ones.
So, there you have it: a complete rundown of the journey we go on when creating new application features. For us, it’s all about taking a partnership approach, understanding our client’s needs, and being with them every step of the way. And that is what it should all be about.
