In the excitement of brainstorming new ideas—both formally and informally—for your custom software system, it’s easy to fall into the trap of adding too much too fast to your product roadmap. While it may seem counter-intuitive on the
surface—after all, more is better, right? Not necessarily. In truth, one of the secrets to a successful custom software project is knowing when to say no.
The decisions you make about which features and functionality to include should be focused on the value each one brings to your users and to your business. If a feature doesn’t add enough value, don’t spend resources building it ahead of features
that do.
Learning to say no will result in a better, more resilient, and more user-friendly software system.
What to Do with New Ideas
Even though you document the product roadmap at the beginning of a project, adjustments and new ideas will inevitably pop up throughout the process. That’s one of the advantages of using scrum—you can do something with those new ideas as they come up.
When new ideas come to light during development, you should evaluate their value and document them somewhere. Here are categories you can use to determine when (and whether) a new idea makes it to the development backlog to be worked on.
Now – Add the feature and its requirements to the backlog according to its priority compared to other items and schedule it in an upcoming sprint.
Later – Document the idea and put it in the project backlog with other “nice to have” items that aren’t built into the sprint plan yet, but that will be evaluated down the road.
Maybe Never – You can document the idea, mark it low priority, and put it in the project backlog or you can just decide it doesn’t add enough value to warrant its inclusion in your backlog at all.
Who Says No?
Ideally when a new idea comes up, the team discusses it as a group and decides its potential value. But ultimately, the product owner (PO) is charged with managing the backlog and the items in it. Or, in our case, this responsibility falls on the product
owners—plural.
Each of our projects has a Far Reach PO and a client PO who work together to determine priority, plan backlog items into sprints, and build out acceptance criteria for each feature and story. So as new ideas come up, the product owners look at them in
comparison to other backlog items and document them accordingly, if at all.
Reasons to Say No
There are infinite reasons to say “no” or “not now” to a feature during the custom software development process. Here are some of the ones we run into a lot.
Timeline
Based on when you’re planning to launch, and how much wiggle room there is, some new ideas will make it into the minimum viable product (MVP) and some won’t. If you add features to the roadmap without removing any, your timeline will be extended, so those features need to be worth it to justify the extra time.
Budget
If you had a limitless budget, you could build all the features you wanted! But we’ve never run across a client with an endless budget, so you’ll probably have to say no to some features. Read more about how and why software costs change, and how you can adapt. And, by the way, just because you can afford to add features doesn’t mean you should.
Selfishness
No matter how much you set out to focus on the users and building the system for them, it’s easy to fall back into thinking about how the system benefits you and your business. When a new idea comes up that benefits your business but not necessarily
your users, that doesn’t mean it’s not valuable. You just need to prioritize it accordingly.
Business Value
You may come up with the coolest idea in the world for your system. But if the feature is cool but doesn’t add business value to you and/or your users, then the decision to file the new idea in the “later” category probably makes a lot
of sense.
Validation
An idea may sound amazing to your team, but if the idea isn’t validated because it hasn’t been part of any user research yet, building it could be costly and delay higher-priority work. When you file something in the “later” category,
you can (and should) conduct user research to validate or disprove the idea before building. I can’t stress this point enough. Taking the time to validate our assumptions about what we think users want is one of the most effective ways to save
money and add value.
Just Say No
It requires discipline to say no. New ideas are exciting and sometimes it’s tempting to just forge ahead right away, consequences be damned. But in pausing, taking time to consider the business value, doing any necessary validation, and prioritizing
accordingly, you can be confident that you’re always working on the highest-priority items and adding the most value for your users and your business.