Your project sponsor wants unnecessary features in the app. How do you stay true to the app's purpose?

I would explain and approach them by advising we should first develop the features that would aggregate value to our product, and after these were added and we have enough data collected to understand the user behavior we could add non-essentials based on the information we had.

Maintain the app's focus by having an open conversation with the project sponsor, highlighting the importance of the app's core objectives and user requirements. Propose prioritizing essential features in phases, with non-essential additions considered for future updates based on user feedback and app performance.

Documented user requirements define the scope of the project. Adding features will likely extend the completion date, more resources, or both. When using a commercial, off-the-shelf product, adding features could render the feature or the app unusable at the next upgrade. During one student information system implementation at a small graduate school, I informed the group that we were so disorganized that none of our policies and procedures could be classified as "best practices" so it was better for us to adapt to a robust product than to tweak it endlessly to accommodate our quirks.

I agree and think with any changes the business value should also be defined. This will help determine if any change is worth the effort and the cost as well as priority.

To stay true to the app's purpose, clearly communicate the core objectives and value of the app to the sponsor. Present data and user feedback to support the importance of focusing on essential features. Suggest a phased approach where unnecessary features can be considered for future updates, ensuring the current development remains aligned with the app's primary goals.

The starting point is to communicate from a point of facts not opinion.For the application,being able to present the main traffic drivers to the application.Being able to decipher and profiency in presenting them to the sponser can be useful.Not to shoot down but also to offer alternatives as well working hand in hand with the sponser.Above all else staying true to the original project objectives.

If the sponsor is willing to bear the additional cost, then you will likely just have to do it. Be as transparent as you can about the time and costs involved with the feature. Document the delivery delays and any other slips, so that you can CYA.

I think sometimes users are so set on an idea they don’t look at other alternatives that might solve their problems better. If options are available and has better benefits then they should be discussed with the sponsor. If they disagree then develop what they want. A quick call might save time and money.

I was once told that we needed to change our student information system because students were having trouble using it. When I asked for statistics, I was told that 4 students out of 400 had trouble, and they were assisted through the system by a human being. A 1 percent problem was not sufficient to throw out the whole system and spend another $500K plus two years to implement. Try to get some statistical validation to justify the requested change or feature. As neutrally as possible, do a cost-benefit analysis, and present it to the decision makers so they understand the extra cost to provide the change or feature.