Usually, we need to do something - actively - to improve our DAMs. Review processes, train users, upgrade systems, or fund updates. Sometimes, though, the answer is to say no.
No to adding new areas of content
No to rolling out to more regions
No to integrating APIs
No to expanding the user base
No to promising features not already in scope
No to including new teams
I’m a firm believer (on paper, I will be silently screaming in my head) that “No is a complete sentence,” but unless you have no stakeholders, you may want to back up your decision with evidence. In each of the examples above, can you think of reasons why the right answer is no? People pleasing in the moment can mean long-term failure of the project as a whole. If you feel confident in the direction the DAM is heading, there will be times when changes in scope, audience, content structure, or strategy will derail that direction.
You could also simply not have the support needed to take on more. If you are on a lean team, saying yes to anything will mean either less time to focus on the current priorities or burned-out DAM pros. If the new feature is valuable, it should be valued. Maybe your no would disappear if the resources needed to do it well are provided along with the request. If the new feature will improve the experience, ask yourself why you are still hesitant. Have you been promised ongoing help only to have it disappear once the shiny new thing is live? Has this stakeholder minimized the change management or project scope in the past? Have similar upgrades meant legacy content needs attention? Think through the impact and share your concerns to see if you can get to yes.
Still no? Even the review process might highlight ways to improve your DAM in the meantime until their request would be the right decision. We don’t want to be stagnant due to fear or irrelevant due to lack of integrations. But not all change is positive and you can feel confident saying no when you rely on your expertise and experience.