How do you manage conflicting expectations between software engineers and non-technical product owners?

Co-creation is the key here. Regular communication and refinement workshop with engineers give clarity. My requirement description along with tester defined Acceptance criteria helps for clarity. I am around often to see Dev demo and give feedback which I made a consistent norm. This helps.

I regularly engaged with engineers to understand their work environment. Just as product managers empathize with customers, it’s equally important to empathize with engineers. I also provide engineers with detailed information about the customers, including their behaviors, environments, and how the system should assist them. As a product manager, I recognize the importance of quality in ensuring users can use the product without frustration and effectively solve their problems. I gain insights into performance and user experience from a technical perspective with the help of engineers.

Product owners need to be crystal clear about the personas and scenarios that must be addressed by the software. In Microsoft Office, we practiced Scenario-Focused Engineering (SFE) in which we wrote detailed user stories which focused on specific user personas and detailed the tasks they would need to perform using the software, and specifically WHY they needed to do the things, and WHAT the outcome should be. Today, we tend to focus on Agile user stories, but the basics are the same: - Specific customer persona - Detailed WHY statement - Specific user intent and outcome

Managing conflicting expectations between software engineers and non-technical product owners requires clear communication and collaboration. Start by facilitating regular meetings where both sides can discuss their needs and constraints openly. Use visuals, such as mockups or prototypes, to bridge the gap between technical and non-technical perspectives. Set realistic milestones and prioritize features based on business value and technical feasibility. Foster an environment of mutual respect and understanding, encouraging both parties to align on goals and compromises. Document agreements and decisions to keep everyone on the same page throughout the development process.

Prioritization frameworks have their value; however, when product owners and developers are fully aligned with the final purpose and vision of the software, ideas and discussions will fluidly gravitate toward what truly matters. In such cases, prioritization becomes more intuitive because every decision will be rooted in a common shared understanding of the end goal.

A one-page spec is a great way to encapsulate the Goals and Non Goals of a software project. Goals are anything the software needs to do, or anything it needs to NOT do. Non-goals are things that users might expect that we are not planning to do. For example, a task list might have the following Goals: - MUST HAVE the ability to add/remove/ re-order tasks - SHOULD HAVE the ability to mark/unmark a task as done It might additionally have these non-goals: - require 2fa to access the task list - ability to create more than one task list per user Non goals are things that we might build if they come easily, but they are not required i order to deliver the current iteration A one-pager should also document key assumptions.

Whether or not a project explicitly uses the SCRUM framework, it can be useful to have a daily (or other cadence) Scrum meeting. Scrum meetings should follow the rule of chickens and pigs. - "Pigs" are committed to deliverables and state what they have done, what they'll do next, and what they are blocked on - "Chickens" are stakeholders with no deliverables (e.g. product owners) and should not speak during standup. They should be there to answer questions and clarify things that are unclear to the "pigs"

Transparency Creates Behavior! Making expectations clear and surfacing metrics that are important to the project helps determine what the dev team will focus on. If what's important is transparent to all, then everyone's behavior will pivot to meeting those expectations.

Here's a plug for my talk and training course "The Five Disciplines," which lays out commonsense principles to follow when having difficult conversations.

Create a diagrammatic representation of business processes .... To do so you can use any shape and notations or you can take help of formal UML notations. Creating a mind map of the whole business as well as individual process is also very helpful to translate business in to code These techniques will avoid conflicts between non technical client and technical team Because the pictures are understandable by each stakeholder And says thousands of words