Here's how you can manage clients with unrealistic expectations in mobile technology projects.

I am going to take a slightly different approach to this challenge of unrealistic customer expectations. First, let's definite "unrealistic." In general terms, this usually relates to either (a) functionality, or (b) deliverables and schedule. In either case, start by sitting down with the customer and asking them to explain the thinking behind their requirements - what is driving their urgency around specific functionality, or a targeted delivery date. Once you understand the motivation and driving force behind what is being asked for, then - and only then - can you expect to reset and manage the customer's expectations by helping them find a path to success.

Establish clear project boundaries, maintain transparent communication with regular updates and provide practical alternatives while educating the client on industry standards and achievable solutions to manage unrealistic expectations.

I second Tom's perspective. More than usually, understanding the requirement and their expectation and the reasons behind the requirement gives us a perspective that we didnt understand in the first place. Set the realistic expectation on can-do and cannot-do with logical reasoning helps. There are only two outcomes - one the customer gets the team's inputs or vice versa. Post which work can be based on the agreements.

Unrealistic expectations— that itself clarifies misunderstandings to begin with. Are those expectations are with respect to functionality or time to deliver or cost associated? First step is to clearly articulate the business problem to address and obtain consensus. Present the facts in a well structured manner ( not to offend stakeholders here). Take it from there

Initial Meetings are of utmost importance. Setting the tone right from the very get go, understanding their expectations and explain what is achievable within the given constraints (time, budget, technology). Also, educating the clients in terms of the constraints, limitations of current mobile technology, Clearly defining the project scope. Also, concise and absolute project status updates.

Customers typically formulate their needs into requirements making assumptions on what the correct solution to their needs are. Listen carefully to the customer, ask questions to understand what their true needs are rather than the requirements they state to you and then propose an alternative that is feasible and meets most of their needs if not all.

Establecer Límites con el Cliente Es fundamental definir límites claros desde el inicio de la relación con el cliente. Ser honesto sobre las posibilidades dentro del presupuesto y el cronograma establecido es clave. Si las demandas exceden estos parámetros, explicar las razones y sugerir alternativas viables es esencial. Esto ayuda a prevenir la expansión incontrolada del alcance del proyecto, evitando retrasos y sobrecostos.

Setting boundaries with new clients is very difficult in smaller organizations that rely on the word of mouth to customers. It is hard to tell them "No" for one project that could impact other potential projects down the road. The best way to set boundaries is to be clear. Request critical criteria from the customer and then be very clear on whether you can meet that criterion or not. Example: someone wants a product that is outside the capabilities of your company production range. If you tell them yes, to making this product, you will have to invest/outsource/or trial and error until you can make it. Those are additional costs to the business that need to be factored in the communicated price. It is not a no, but a yes, with amendments.

To set the boundaries, it is quite important to get the requests coming from the different departments involved in the project. Mostly, the technical depts. of customer faces you in the meetings and the approach coming from the business side can be missed.

In my experience you need to segment what type of "unrealistic expectation" it is. e.g.: 1. Is it outside of the original scope? 2. Does it require too many working days vs. what was agreed upon? 3. Do they want features that aren't technically possible? 4. Are they raising requirements that are prohibited due to Government regulation or Apple/Google's appstore regulation? etc... Good communication with the client is important. Issues 1+2 can be solved commercially, if it's an important client I would go the extra mile to overdeliver, or negotiate an additional budget. For issues 3+4, a deep understanding of the client's real needs or motivation can lead to finding workarounds or other ways to achieve the same goals.

This might be the single most important step in successful projects (mobile technology or any other). Plus you can establish yourself as a partner instead of being seen as just a vendor/consultant. Remember over-communication is a lot better than not-communicating.

**Desvendando os meandros do desenvolvimento móvel** O desenvolvimento de aplicativos móveis é um processo complexo, com diversas etapas e desafios. É fundamental que os clientes compreendam os meandros desse processo para que possam tomar decisões informadas e realistas sobre seus projetos.

Comparto con mis colegas que la comunicación es fundamental durante el proceso. Pero, ¿Qué sucede a partir de que hemos entregado el servicio o producto? La comunicación y acompañamiento posterior a la entrega es tan o más importante que la anterior. Con esta ayudamos a nuestros clientes (externos o internos) a adoptar los cambios con menos estrés y mejoramos la aceptación de estos cambios a mayor velocidad y menor fricción.

Restrições de plataforma:** Cada plataforma móvel, como iOS e Android, possui suas próprias características, diretrizes de design e limitações técnicas. O que funciona bem em uma plataforma pode não ser viável em outra. É importante considerar essas restrições ao planejar um aplicativo, para garantir que ele funcione de forma eficiente em todos os dispositivos e sistemas operacionais.

This is a critical part of managing client expectations. Clients ask for a specific solution not for the sake of it, but because they believe that it will help solve a business problem. Taking the effort to ask questions and understand their real problem is worth it, as more often than not, there are other ways to address their real problem. In a recent example, a client was expecting their mobile app to be updated with the information when a user shares a key with another person. The keys in this case were managed in Apple/Google wallets. In addition to explaining the limitation that stops us from doing this, we offered an alternative after understanding their business problem they were trying to solve.

**UI/UX Design:** A interface do usuário (UI) e a experiência do usuário (UX) são elementos cruciais para o sucesso de um aplicativo. Um design intuitivo e agradável torna o aplicativo mais fácil de usar e aumenta o engajamento dos usuários. No entanto, o design deve ser equilibrado com as funcionalidades e objetivos do aplicativo, para evitar sobrecarregar o usuário com informações desnecessárias.

In my experience you need to segment what type of "unrealistic expectation" it is. e.g.: 1. Is it outside of the original scope? 2. Does it require too many working days vs. what was agreed upon? 3. Do they want features that aren't technically possible? 4. Are they raising requirements that are prohibited due to Government regulation or Apple/Google's appstore regulation? etc... Good communication with the client is important. Issues 1+2 can be solved commercially, if it's an important client I would go the extra mile to overdeliver, or negotiate an additional budget. For issues 3+4, a deep understanding of the client's real needs or motivation can lead to finding workarounds or other ways to achieve the same goals.

He encontrado mejores resultados al plantear Productos Mínimos Sostenibles o Productos Mínimos Escalables, antes que MVPs. Dejamos de pensar en restricciones de tiempo y presupuesto (que siguen presentes) y enfocamos los esfuerzos en lograr beneficios tangibles del producto mínimo. Con este enfoque mantenemos la flexibilidad evolutiva, pero cada pieza que agregamos al producto en creación, la agregamos nos lleva a entregar valor en el corto plazo y alcanzar un estado temporal de "pausa, ajuste y escalamiento"... y así una vez y otra vez.

Produto Minimamente Viável (MVP):** O conceito de MVP é fundamental no desenvolvimento de aplicativos. Em vez de tentar construir um aplicativo completo de uma só vez, o MVP se concentra em desenvolver as funcionalidades essenciais que validam a ideia do aplicativo e atendem às necessidades básicas dos usuários. Isso permite lançar o aplicativo mais rapidamente, obter feedback dos usuários e iterar sobre o produto de forma mais eficiente.

A few suggestions: Document Everything - Written Agreements: Ensure all decisions, change requests, and approvals are documented in writing. This helps avoid misunderstandings and serves as a reference in case of disputes. Meeting Minutes: Keep detailed minutes of all meetings and share them with the client. This ensures everyone is on the same page. Fact-Based Discussions: Use data, facts, and logical reasoning to address unrealistic expectations. Avoid emotional arguments and focus on practical solutions. Professionalism: Maintain a professional demeanor even when disagreements arise. Focus on finding mutually acceptable solutions rather than assigning blame.

**Definindo expectativas realistas** Um dos maiores desafios no desenvolvimento de aplicativos é gerenciar as expectativas dos clientes. Muitos chegam com ideias ambiciosas e complexas, sem considerar as limitações técnicas e o tempo necessário para desenvolver um aplicativo de qualidade. É nosso papel como profissionais educá-los sobre o processo de desenvolvimento e definir expectativas realistas desde o início.