We recently developed a novel capability for a software tool that I manage. Our first iteration of the capability was to incorporate a prototype developed by the customers. While this prototype addressed some pain points that users had with the legacy approaches, our development team was quick to identify new problems that this new approach can lead to. While this anticipation was reasonable, I did not agree with proceeding to solve problems that we anticipate. I suggested to gather more evidence, more signals on whether these anticipated issues will really be a problem for the users before jumping into the solution space. Few senior developers have disagreed with me and they suggested that we ask users for confirmation. I disagreed with that approach of gathering evidence also. I decided to address this tension by calling a meeting. I have asked the developers to come prepared with their proposed solution / feature design. I have prepared a detailed set of questions necessary to answer before making a go / no go decision on the feature prior to the meeting.

1. Does this approach handle all edge cases? How confident do you feel that this solution will scale to different customers?
2. Is there any technical conflict with the simple approach that we are taking at the moment, and this proposed feature? In other words, is this new feature an additional capability that can be built upon what we scoped already or will it require significant refactoring?
3. What are the additional UI/UX workflows, views that need to be built to allow users to interact with this feature?
4. What is the engineering cost of building this advanced feature, what would be the delivery date? I need to know this to assess if customers and/or funding org are willing to pay for this?   Finally I pointed out the fact that the users have domain knowledge that we lack. They can utilize their expertise to manage dependencies, and can develop strategies to overcome side effects. What is theoretically possible doesn’t always happen because of the restrictions of the domain. Developers agreed that we need more time to flesh out the advanced capability, it can be built upon what we are building at the moment and cost of engineering is unknown. Under these facts, the engineering team lead has decided to keep our focus on the simple solution to not risk our delivery deadline. It was valuable to have this discussion internally. Instead of cutting the discussion with an out of scope stance, it was valuable to give members of the team to express their idea in great detail. It helped me understand possible improvements we can achieve in the future, and it helped the team understand why not now. This interaction taught me to tackle conflict with open but structured discussion that makes the decision making more transparent and objective.