• Stop and reconfirm your ideal customer for this product.
• Identify the specific features and functionality needed for you to begin making money with the product. Consider both customer facing functionality and back-end functionality needed to support those features, and tackle them first.
• Diligently hone this list of features to the bare minimum.
• Focus on completing the bare minimum features before adding “nice to have” features. Then, once you have your ideal customer using your product and paying you money for it, the “nice to have” features can be added.
• Revisit and update this list as changes are discovered during the development and testing process.
• Be willing to say “No” to some requests if they are not needed right away.
• Always have open communication to present information and address issues immediately when the budget and timeline are impacted.

• What is the cost of this change in both time and money?
• Is this change worth the cost?
• What is the cost of delaying this change?
• Is the product still usable without this change?
• Will the product still meet the customer needs without this change?
• Will this change make the project better for the customer in the long run?
• What feature can be removed from the scope to add in this one, so you remain on time and budget?
• Does this change make the product more scalable, stable, flexible for future enhancements? If so, how important are those factors right now?

NOTE 1: If you do have to say “No, not right now,” stand firm in that response and add the requested item to the product backlog for future consideration and prioritization. Saying “No” with a solid reason then caving in to pressure to absorb the requested change damages trust between you and the team.

NOTE 2: Consider what will likely happen if the budget and timeline are not adjusted while adding the requested work. In this case, the late decision will likely result in increased stress and frustration for everyone and potentially a product that may not align with the best practices due to time constraints. Giving in to pressure to add in the additional work after you’ve firmly said “No, not right now” also leaves the impression that you can and will change your mind with enough pressure. This can make the team, whether in-house or outsourced, uneasy.

STORY TO CONSIDER: I once worked for a client where I fell into the pattern of saying yes to small requests. During our regular product demos, the client often requested minimal changes. These changes were often only a few hours of work. I almost always said, “Sure, we can make that change”. Before long, I realized I had added days, which turned into weeks, of work for my team. Inadvertently I had trained the client that if they asked for something that seemed small, they would get it right away. I kept telling myself that I was serving the client well because I gave them what they wanted, meeting their product needs. In reality, they didn’t need most of the requested minor changes at that time. Had I instead captured those requests in a backlog and prioritized the backlog with the client, my team would have had been able to stay on schedule and meet the initial budget. While the client liked the small items we kept adding to the product, they did not appreciate us missing our deadlines and exceeding our project budget.