You're working with a Product Engineering client. What are the most important things to keep in mind?

1. Understand customers requirements and convert them into technical specifications. 2. Get some Service level issues and return of Experience issue address them and add value to the product.

According to my practices, before communicating with the customer, I prefer to do background research on the customer if possible to have an idea of how to deal with the customer. Background research will give you an idea about the psychology, technical know-how, and budget idea as well! So here we go: 1. Background research 2. Understanding of the Problem from the Customer/Layman's point of view if the customer has already shared it with you. 3. Its good to have written communication as a proof, but for clear and precise understanding, prefer to have verbal communication.

Primeiramente avaliar o caso/problema que tem em m?os, analisar possíveis aplica??es, interferências, verificar aplicabilidade de possíveis solu??es e imprescindível, também analisar tecnicamente as op??es disponíveis.

Depending on complexity of project, transform customer requirements into an agreed specifications list - focus on any key parameters. From specifications, design and engineer an agreed solution - use experienced engineering disciplines (internal and external if necessary) to validate any statements made - assumptions should be clarified with customer sand adapt spec/solution as necessary. Agree, if possible, achievable timelines, milestones and deliverables which align with the customer budget and delivery requirement. Be prepared to stick to and defend what you believe your organisation/company can achieve within what has been agreed and be prepared to walk away from changes to timelines and costs you believe can NOT be achieved.

In order of importance: 1) (THE MOST IMPORTANT!) Clearly understand the ACTUAL customer' s need. Most of the time, customers come to us asking for something believing it's the solution of its issue. It's crucial to make a deep and accurate check to define the real need; once done that... 2) Propose an appropriate, LEAN and feasible solution 3) Understand the proper "technical language" to communicate clearly our vision of the current situation and our strategy to fix/improve it; it's essential to find a "common ground" to share ideas and doubts If those points are properly fulfilled, the rest of the project can run within a proper path and guideline

1. Establish transparent communication channels with clients for updates, feedback, and issue resolution. 2. Engage stakeholders including users, testers, developers, and designers to foster alignment and collaboration. 3. Utilize clear, concise language, avoiding jargon and ambiguity to ensure understanding. 4. Document communication and decisions systematically using email, chat, video calls, or project management software. 5. Prioritize active listening and responsiveness to address concerns and maintain project momentum.

Understand the obvious pain points but also the underlying , unseen pain points for which work arounds have been developed by individual users and not captured in formal processes.

Mostly, clients are not technically strong enough to explain the process which is subjected to design so engineers should have effective communication skills to address the problem with clients.

When engineering a product, it is critical to communicate effectively with the customers. Don't just imagine what you think their needs are. And don't just take their design suggestions at face value. There are needs behind their suggestions, so dig deeper and get to the pain they are experiencing that is driving their suggestions. These needs should then be prioritized and the top ones written into system requirements. Doing so will ensure that the final design is cost effective to develop, optimizes customer satisfaction, and reduces the chance for recalls or other quality issues.

There must be a clear standard of communication, execution deadline and points to be addressed, it is important at this stage to define the rules of the game and the objectives to be achieved, and I always use the APQP tool, which in addition to communicating everyone at the same level, informs how development is being conducted.

1. Employ agile methodologies like Scrum or Kanban for incremental and iterative value delivery. 2. Apply user-centered design principles such as empathy, ideation, prototyping, and testing for user-friendly products. 3. Implement code quality standards including readability, modularity, documentation, and testing for maintainability. 4. Utilize tools and frameworks like version control, automation, cloud computing, and data analytics to optimize workflow. 5. Embrace creativity, flexibility, and adaptability to tailor best practices to specific project needs and contexts.

These are some of the factors that I would keep in mind: 1. Clear Communication: Ensure open and transparent communication channels to understand their requirements thoroughly. 2. Problem-solving Approach: Address challenges proactively, offering innovative solutions to enhance product development. 3. Collaboration: Foster a collaborative environment, involving the client in decision-making processes to align goals effectively. 4. Quality Assurance: Implement rigorous testing procedures to guarantee the product meets high-quality standards and customer expectations. 5. Timely Delivery: Adhere to project timelines diligently, prioritizing deadlines to maintain client satisfaction and project efficiency.

At this point it is important to give the team freedom and create a multidisciplinary team, where with the defined product and process FMEA and APQP monitoring, it will provide direction for development, without losing the team's autonomy, maintaining motivation and freedom to innovate.

Managing expectations while working with a product engineering client is, I believe, the most important aspect to make the project a success. It is important to explain to the client why a feature will take an 'x' amount of time to build. The client should be made aware of the concept of technical debt while having products built by engineering teams. Further, the client should also be made to understand that design decisions also have technical costs which add up as the products grows. If the client understands that building products requires design decisions to be made, then his/her expectations become more realistic.

I suggest weekly meetings to highlight the evolution and constant revalidation of specific requirements, the approved design, the required quality and the status of development / implementation.

Manage through PDCA and make changes to the procedures in question, creating a culture of identifying the problem, solving it, detailing the solution and transmitting knowledge to other stages of other processes, whenever possible.