How New Feature Requests Should Be Handled by a Development Team

Published on March 10, 2023

Building a new digital tool is exciting, and it can be easy for inspiration to strike during development that leaves you wanting to add features that weren’t planned for at the onset of the project.

Say you’re building a custom scheduling portal and two months into the build, you decide you want your users to be able to search and filter for shifts that best fit their schedule.

Maybe you’re building a wellness app, and you hear feedback from potential users they’d like to be able to message their coaches, when a chat feature wasn’t something you had planned.

Or during the build of your employee intranet website, stakeholders feel the site should integrate with the company’s Microsoft Office Suite of products.

Scope changes happen quite frequently when building digital products.

In fact, we’d be hard-pressed to tell you about a project where nothing changed from the initial scope outline to the product’s launch, so it’s important to know you’re working with a development partner who will help you determine if unplanned features are a necessity for your current build or if they can be tabled for the next version.

What’s so bad about hearing “yes” to my every feature request during development?

While working with a digital product team who says “Yes!” to your every request might sound great, it can be a red flag of things to come, and they build upon each other:

• If your software development team is saying “yes” to every request of yours, they’re probably saying “yes” to all their other clients’ requests as well, leading to overcommitting and underdelivering.
• One code change can impact code everywhere.
• More time is allocated to the project to build the new request and fix any other impacted code, extending your timeline to completion.
• More time = more money, increasing your overall spend on the project.

Think of it like building a house: blueprints are drawn, materials are ordered, and contractors are scheduled. Halfway through the build, you decide you want the kitchen sink placed against the window, not in the center island, so you can look outside as you wash dishes.

Changing where the sink goes mid-build may not seem like a big request, but it has an impact on the plumbing that’s already been put in. Before your builder agrees to the change, you would expect them to discuss with you the implications this change will have on your budget and move-in date.

Similar groundwork is laid at the start of building a digital product: the main features and functions are drawn up, then costs are outlined and timelines are set based on those determinations.

Adding a feature or functionality change, like allowing users to upload a photo or video, halfway through development might not seem like a big change, but it has implications on the code and infrastructure already in place.

How should scope changes during digital product development be communicated?

A good digital product development partner will help you weigh the value of implementing a new feature against the impact on your product’s launch date and project spend.

Most of the companies and teams we build website and apps for aren’t technical. Without a technical perspective, they have no idea which feature changes constitute a game-changing request and which ones are an easy lift.

This is why building trust between a client and a software development team is critical because a simple “yes” or “no” answer isn’t helpful. The best answers go something like this:

“Here are the technical, monetary, and schedule implications of doing this now versus tabling this feature for a later version.”

Clear communication and explanations will make a feature request discussion more useful and guide the client toward understanding its impact on the overall project.

How do you make sure your digital product team isn’t just a “yes” team?

When you’re first starting out with a software development agency, it’s important to know they’ll be the type of partner who will help you stick to your scope, meet deadlines, and not blow up your budget, yet also help you meet your project’s overall goals when change inevitably happens.

Before any work takes place, ask them questions like:

• How do you organize what’s being built and when?
• How are new feature requests handled mid-development?
• Where does the priority of our work fall in relation to other clients?
• How often is communication expected? (Weekly/daily meetings, email updates, etc.)

In addition, speaking with current and former clients of a digital product development agency will give you a good idea of the team’s ability to communicate the pros and cons of feature changes, as well as insider information on communication frequency, quality of deliverables, and much more.

---

One sure way to vet a digital product development team is by asking them our aptly named “22 Questions to Ask a Development Team,” a free resource we put together to help companies find the right tech partner for their project. You can find it on our resource page at https://jmg.mn/resources.