Enterprise mobile apps have moved from ‘nice to have’ to ‘mission critical’ tools for many organisations in the recent times. A recent study has found that demand for custom apps that allows employees to be more productive is on the rise. However, the process of deploying a mobile app for an enterprise is not only hard to navigate, but also taxing on the finances. "Organisations spend countless hours and a fortune working on the design, user experience, development, testing, infrastructure and finally training; only to realise that the seeds of the apps have sprouted weeds instead of fruits — and by this, I mean ‘low adoption’." ‘Adoption’ is the word that haunts most of the organisations when it comes to enterprise apps. As a product owner myself, after our product went live; with the roll out plan heavy on internal marketing (right from marketing videos, posters, surveys and town-hall meetings to other engagement activities) and dedicated trainings (pit stops, classroom trainings, refresher trainings and tutorial videos), I waited patiently to see the fruits of the effort the team had put in. I’ll be honest — at first, I was definitely not disappointed. The increasing adoption rate was really satisfying to see. But soon enough I realised that the beautiful graph of adoption was what we can call a ‘Typical Adoption’. To give you a background, we had tried to follow almost all the best practices available for creating the good enterprise app. ‘Involve ends users upfront’ — check, ‘quick and multiple feedback loops’ — check, we even worked hard to get our internal marketing and training tactics right. As you get the point — I was pretty puzzled on why the adoption was taking a hit. So with a mind full of questions, I got down to do some industry research on adoption of enterprise apps. So I decided to charge and chart out a strategy to analyse and fix the 'typical adoption' problem for enterprise apps. Step 1 - Analytics - Measuring the results Everyone needs analytics. When it comes to adoption of mobile apps, analytics should be the basis of every decision taken — right from strategic to tactical. "Trying to improve adoption rate is like changing wheels of a moving car so that the car runs faster, and analytics would help you point out which wheels to change." The metrics you would want to measure would differ based on the type of app you are dealing with. Holistically, there are two categories of apps — engagement driven and transaction driven. For our case in point, we would consider that the app is transaction driven. Primarily, we need to look at two main buckets of data — performance and usage (no brainer). However, getting the data categorised as per metrics is only the start. After we have the data in place, comes the herculean task — making sense of the data! And the best way to do this, as per what I did, is through segmentation approach. The first level is to identify the ‘Repeating customers’ versus the ‘One time customers’. You’ll be able to get this information via the retention and churn data. The reason why it is of utmost importance to get these two segments right is because you’ll have to analyse and handle these two segments in a very different manner. For repeating customers, you want to know why they came back to use your app, and for one time users — why then they didn’t. The next step is to look for patterns within the segments. In my case, I was able to identify specific personas using the demographic information of the users and team structure. Step 2 - Asking the Users - Survey & Interviews In our case, gathering feedback is like killing two birds with one stone. First, it would give us actionable insights which would help us on our quest for higher adoption, and secondly talking to the users and taking their feedback makes them feel that you care enough to consider their views. This will increase the feeling of ownership and could win you with some internal advocates of the app. We need different sets of information from the personas identified, and hence the best way is to design different short surveys based on the personas. The survey should not be very long and the user should be able to complete in 1 to 3 minutes. Any longer and you might lose their attention. Surveys should be designed keeping in mind the potential problems users might be facing. This would streamline the thought process of the users and help you gather structured data rather than haphazard feedback with no actionable insights. Once you have the survey data, analyse the responses to identify the top users who gave clear and useful feedback. These are the users with whom you want to discuss more and pick their brains for insights. Set up interviews (ideal length  –  30 minutes) and gather detailed feedback. Step 3 - Identify the problem Now that you have all the data you need, it’s time for the moment of truth. This is where you map your findings, look for patterns and deduce potential reasons for the low adoption. From my experience, there are 4 potential reasons why enterprise mobile apps fail. 1. Users ear disruption of existing processes Change management is hard. People don't like changes - unless something is really broken. While this may be one of the hardest issue to solve, it is definitely possible. Here are some suggestions to ease out the transition - Communicate the benefits of the change clearly. This should be the core theme of your internal marketing. Have a robust support initiative. The end users should never feel stranded with a pile of issues with the new system. Use the top-down approach. A subtle push and guidance from management will reinforce the trust of the end users in your product. 2. Users don't feel confident enough to use new technology for important processes. (Fear of screwing up) Considering everything you do is related to technology in some way or the other, you would probably not face this problem. But my project has a very specific segment of users who weren’t comfortable using tablet devices. They preferred paper over a tablet, and that was one of the culprits. So here are some of the approaches we took to mitigate the issue – One on one training sessions with the users. Users from this segment don’t usually come out and ask questions in group trainings (due to the fear of feeling stupid), leaving them with unanswered questions and hence leading to low or no adoption. Tip  –  include role plays during the training. I would be repeating myself, but there is no replacement for a good support initiative. Make sure you are always reachable and in their radar. 3. (The most dreaded one) Priorities of the users versus value proposition "Fun fact — end users do not have spare time. So if your product demands them to spend time which doesn’t result in time saved down the line, it is very unlikely that they would keep using the tool. Thus, leading to the downward spiral in adoption rates." While your product may still have a strong value proposition, that might not be what your end users are looking for. In most cases, this issue should not happen if you have done your UX study right. But sometimes the processes are so complex (specially in financial institutions), that a digital clone of a manual process may end up being more taxing for the users. While there might be way to coax your users to adopt your product even in this situation, I would recommend the hard way – going back to the drawing board. 4. Users aren't aware of the capabilities of the product. Alas, while we thought we had a failsafe training plan in place  –  we realised many of our users weren’t aware of what all they can do with the app. However, this issue is relatively easy to solve. Here are some tips on how you can do it better – Opt for short videos which the users can refer to at their own time. Make a FAQ page for the app on the internet. If your company has already jumped in the chat bot bandwagon – that is also a good idea.

Throughout the years, many people have learnt to implement agile but are still struggling with how to run big transformation programs. Many big organisations take initiatives building a central team of coaches for transforming the whole organisation into agile, but there are some mistakes that should be avoided. While working with big organisations as a member of an agile transformation team, I have learnt some anti-patterns that I am going to elaborate in this article. This is the first article in the series to cover mainly seven anti-patterns: One size fits all. Too long preparation time All at once Ignorance of supporting environment Ignorance of technical practices Vendor management and distribute team excuses Agile as a delivery engine In this article I am explaining the first anti-pattern: One size fits all Each product is different from another in terms of complexity, team structure and vendor association. How then, do standardisation of tools and practices work? This is one of the most common anti-patterns of agile transformation programs. Many organisations try to standardise agile practices, tools, and behaviours. In my experience, I have seen people recommending, or worse, forcing teams to use enterprise-level best practices or tools. There is no best-practice, because the best practice does not leave a room for improvement; which is against the agile principle of continuous improvement. Secondly, recommending standard practices defeats the purpose of flexibility in agile, which was the original reason of not making agile frameworks prescriptive. For instance, there are many big organisations that write their own agile methodology and prescribe all the practices, tools and how to implement them. Also, they call it “<company name> + Agile Methodology”. Often this appears to be a compromised version of agile. Similarly, organisations choose one standard agile tool for all teams without knowing if it would be comfortable and suitable for teams. The most common pattern is using one electronic tool for all teams that use Kanban. However, there are better tools available to serve the purpose. For example, recommending Atlassian Jira in the whole organization can lead problems for kanban teams. Instead, they might use Swift Kanban or Trello which are a better fit for Kanban. The more alarming situation is when the teams are co-located and can use physical boards, but are forced to use the electronic tool because it is a recommended standard enterprise level tool. Why is Standardisation Harmful? As every human being is different and forcing them to behave, talk and work in the same way can be counter-productive. Having a standard agile methodology in every situation proves to be harmful. I have seen support teams struggle with fixed iterations, novice teams struggle with a continuous flow of work and support functions struggle with writing user stories. Hence, standardisation only leads to frustration in people and compromise in business benefits. It mostly happens when people focus more on practices rather than on values and principles. Moreover, not having trust on teams for experimentation and not letting them choose their own suitable way of working can harm productivity. Custom Fit  As you might be convinced by now, “one size fits all” does not work. What is then the solution? The answer is “custom fit”. The first step is to understand the context of the team, product nature, people, and business expectations. Then, choose your framework, set of practices and principles accordingly. Try and continuously learn from your mistakes. This way, the method will evolve over the period of time and you will find the “suitable model” for you. Don’t stop improving! Please share your experiences. Do you use standard tools and practices? Are they working for you? Have you evolved your method over the period of time? Stay Curious! Coming Soon: Second anti-pattern – Too long preparation time.

The designer came back and asked exasperatedly, “What do I do with this?” He was looking at a research report that was meticulously done, but that did not help translate into something that could inform ideas on a solution or even physical designs. I often get asked by clients, “How do you get from research to design?” I admit it’s not an obvious transition. You learn something about someone, designers go back to their desks, and all of a sudden you have a specific solution. How do we know that creation was founded on what we learned? It is a concern where we as researchers have to look at our own work and ask — are we serving designers with what they need in order to do their jobs? Are we speaking on behalf of the user in a way that will encourage creativity, possibility, vision? When our research does not bridge the gap between knowledge and creation, our research is useless. UX Research is meant to engage, inspire, and ultimately mobilize those who use it. This goes all the way back to when we embark on research and all the way to how we structure and communicate our findings. How can we make sure that research informs design? Ask the designer what he/she needs to know to do their job. I know it seems obvious, and sometimes the researcher IS the designer, and they still miss it. Even with designers, they may mentally disconnect the research activities from their design activities. I create objectives before I create any materials in the research, and those objectives are informed by what I want to know about the user and what the designer and developer want to know about the user. Ask yourself — “Does this get me closer to a solution if I know this?” One flaw that I see in analyzing data is that you analyze it and then you. report. everything. Not all information is useful. What information pushes the narrative of the user in a way where you can understand what goals they have, what type of solution they need, what user flows are necessary, what features are relevant, and what content is important at what time? These are all questions a designer is worrying about. If the information is “nice to know” but doesn’t inform them on this, you’ve wasted their time. Create an empathetic story. A big part of design thinking is having empathy for your users. This is powerfully relayed in the way that you explain and contextualize your research. Who are your users? The quickest way to predict what someone will do in a hypothetical situation is to understand about their motivations, attitudes, emotions, and their triggers(events that get them thinking about something your client is probably interested in). Paint a picture of them on that level, and people will be able to empathize because motivations can be shared, how we enact them in different context, cultures, etc. can be different. I walk clients through an “emotional user journey”, a journey that shows not only what they do but how they feel at each point in time and why. It helps clients experience the ecosystem they may be stepping into on a gut level. Highlight solvable problems. In design thinking, we want to create statements of possibility, an open invitation to consider alternatives. “How Might We… improve the way we track people’s time so that time sheets aren’t so painful to fill out?” “How Might We… reimagine a toothbrush so that users can reduce their environmental impact?” Our research should help inform these ideation questions. Represent the user. Research is a process often with documents to consolidate learnings but it shouldn’t stop at the document. Reports, personas, user journeys, etc. distill the rich information you have experienced in this process. If the researcher IS the designer, that’s amazing. Then the user lives on in the designer in a primary form. If the designer is NOT the researcher, the user lives on in the designer’s memory of the presentation and interpretation of the report — a secondary form. If this is the case, the researcher should be providing advice, reviewing, or co-creating with the designer. Research is not a powerful design tool unless you approach it knowing what it will be used for. Why should businesses care that we approach research right? Research gives us confidence that we are looking at the right problems. All good projects must start with truly addressing real problems — otherwise, you’re wasting a lot of money on creating something that is solving a problem no one had. Subsequently, how do we know we are meeting the needs of our users? Research helps businesses establish a baseline for success metrics. Good initial research helps us measure our return on investment. Why should designers care that we approach research right? Research should be one of the most impactful tools in a designer’s toolkit. Research ensures decisions are focused and informed. It keeps stakeholders and designers honest about the design decisions they make (or argue over) because the rationale from the research should back it up. Research at the beginning isn’t the end-all-be-all. It’s an informed starting point. As we progress, we learn more. But it provides more confident user assumptions to start with. Designs can create targeted user tests (does our design solve the problems we revealed in the research?) so that we can continually clarify what we know and whether or not we are on the right track. Research is okay when it addresses gaps in our knowledge: “I want to know you”. Research is a powerful tool when it bridges the gap between knowledge and possibility: “I want to know you so that I can help you.”

It all started with an idea that came about during a conversation I had with my boss, Nadege Bide, when we had just finished a project for a banking client in 2017. During our dinner to celebrate the completion of the project, we were discussing how we could apply the functionality of some aspects of our new product into UX practices. I immediately saw an opportunity coupled with a clear vision to make a promising new project. Enthusiastically I manifested my desire to transform the idea into a reality and sooner that I knew, I got the approval to work in the project envisioned. “The idea of the project was to help UX designers with qualitative user research. A project that I named RestitUX.” Alongside other talented Palowans I was able lead the project of RestitUX from inception to MVP, relying on prior research to come up with the following product:   The Product PALO IT to present its interview research and speech-to-text technologies internally. The main features of the MVP includes: Create questions based on objectives: User needs addressed: This gives guidance to anyone who wants to do interviews (UX, PO… and even marketing or sales people) and make sure that every question asked will respond to an objective of the research. Conduct interviews with speech-to-text transcription and tags: User needs addressed: Allows users to index and structure information as they conduct the interview to save time during the analysis. While we usually encourage at least two people when conducting interviews, at PALO IT, it might not always be possible. Edit text and selection of the most important content to export it in a .txt file: User needs addressed: Based on our participant feedback , one insight we found during our research phase was the desire to be able to easily analyse each interview. The functionality of highlighting text allows the user to be able to see the information that interests them with minimum effort. Transcribing a recorded interview: User need addressed: Users that do exploratory user-research prefer not to write questions beforehand and ask questions in a more spontaneous way. For this kind of interviews, the users can input a recorded file to get it transcribed from speech-to-text and have the tool analyse it.   How We Made It 1. User research phase In order to make a product that addresses its users needs and desires, I was given the opportunity to lead a formal user research where I interviewed  different designers of PALO IT’s design team from across our international offices (Singapore, Hong Kong, Mexico, Paris…). I got the opportunity to interact with designers from different backgrounds and experience levels to understand and define a strategy that ultimately creates the most inclusive design possible for our target audience. We wanted our targeted users to be able to express the way they work, their pain points, their habits, etc.. The challenge was not bias my research or findings, in order to do so, I took note of all the important feedback from the participants to later define the most important solutions in speedboat workshop with some of the other colleagues from PALO. The idea was to put myself in our client’s shoes, when they think they know their users by heart (which in most cases turns out they dont know them as well as they thought). (more on the speedboat workshop later down in the article). 2. Competitor analysis Part of the vision I had when I first started the project was based on an inspiration that came from a speech-to-text app called “cassette”, that I fell in love with during my Masters in UX design. Typically, at PALO IT, we usually conduct functional benchmarks of existing products to ensure that we are able to identify existing solutions in the market and build the best product possible. At the end, RestitUX is the result of a blend of two of my favorite apps I benchmarked. Existing Solutions Cassette: An app for user research that allows people to transcribe information from speech-to-text while using bookmarks to define key moments during the interview. I found the concept of the app great, even though I found it to be a bit too simple. Trint: Trint is a speech-to-text service that allows users to transcribe recorded interviews. Some colleagues at work had told me about this new service which had proven to be quite useful, but painfully expensive. Note: We are using functionalities of tools that already exist but enhanced with an improved user experience. The goal of the project was to create a tool that will make Palowans more productive without needing to outsource apps to work efficiently and effectively, such as leveraging on speech-to-text technologies.   3. Framing and ideation workshops: Doing ideation workshops and framing the perimeter of the project is a classic process we have at PALO IT – the ideas are gathered in 5 days within a Design sprint, sometimes along what we call the inception sprint. At PALO IT, we have a complete deck of “innovation games” we like to use, depending on the insights we got from the users. This time I used the famous speedboat innovation game which allows us to have a view of the pain points they encounter during their process as the anchors of the boat t and all the desires and opportunities as the sails of the boat. The goal is to later involve people being able to vote for the ideas they consider the most valuable to them. After that we then got to co-designing the customer journeys of the users (3 personas in total) 4. Prototyping, Testing, Repeating… PALO IT is a development company and I learned a lot about working in lean UX with developers to bring an idea to life with all the code infrastructure needed to function. For this I also learnt a few of the skills product owners use to collaborate with developers in order to create a product. As for a true agile product, we got to work on the MVP by prioritizing the backlog. In order to do that, we used classic Kanban and Scrum. For those who are not familiar with these Kanban method board is a board tracking the process flow while maintaining the number of work-in-progress activities. On the other hand, a Scrum board is a board tracking work in Sprints. A Sprint is a short, consistent and repetitive period of time (which is normally 2 weeks). You can find the detailed difference between the two > here <. As a product designer, I was asked to understand how to write good user stories. I got a better understanding of how to write user stories and how to use trello or other software such as pipepify to do such tasks. The normal way of creating a user story is in this manner: As <persona> I want <what?> So that <benefit for the user?>. Tip: When building a product that has many User stories, it’s a good idea to give them numbers such as US#31 (User Story #31) to be able to refer to them more easily when having discussions with the development team. If you want to learn more about it I highly recommend this tutorial .  5. Things I learned during the process: POC vs MVP During the production segment of restitUX, I realized that I was mixing the terms POC and MVP. Put simply: An MVP is a minimal form of your complete product that is tested with the end users/customers. Whereas a POC is a smaller project, typically used internally not publicly, to verify a certain concept or theory that may be achieved in development. During this project a combination of both was used. We used POCs in the form of SPIKES to validate the feasibility of my ideas and eventually create a functional tool that would be used internally in the form of an MVP. If the term SPIKE is not familiar to you, in agile software development, a spike is a story that cannot be estimated until a development team runs an investigation of the feasibility of this story.   6. Debugging and testing When it comes to debugging, this is the first time I have actually experienced this part of the process, I originally thought that the debugging was the job of the development team, but it is actually a third-party that should do the testing and debugging to make sure every possible manipulation within the tool is working in optimal shape. There are different types of automatic testing so that a software can grow in a scalable way such as Cucumber, a tool we use at PALO IT. Now restit UX is being used by our Palowans and iteration v2 will come soon from the user’s feedback! This is a good example of how we all work together on a daily basis to make our client’s user’s life easier…   Final Thoughts The value of being able to work in this project was the opportunity to follow the proper design process for the creation of a product (from idea to MVP) in Period of 4 months. PALO IT is company that has Coding and agile development embedded to its core. If you want to get to know how to work with developers in an agile framework, this makes a great base ground for upcoming designers who want to make the transition into product design where you get to see the whole cycle of a the creation of product. Transition into product design The project RestitUX has allowed me to do a transition from UX/UI design into the field of digital product design as I was able to learn how to lead the project from inception to MVP delivery. In Justin Edmund‘s words, “A product designer oversees product vision from a high level (how does this feature make sense for where we want to be in 6 months) to a low execution level (how does styling this button this way impact how the user flows through this function)”. I am glad I was able to officially make this transition, as it has always been my original intent ever since I started learning about digital design and marketing back in 2011, Smashing Magazine.

My experience in startups and PALO IT has taught me that Agile practices don’t only apply to software development teams. Agile represents a new way to increase the efficiency of your teams, respond to changing requirements, and deliver value to your clients. Agile only works for developers and software? It’s true that the Agile Manifesto was written for software development. However, the underlying “why” behind the values and principles of the Agile Manifesto is all about increasing adaptability and delivering valuable outcomes for your customers regardless of the domain. It allows companies to flourish in markets that are increasingly uncertain and complex. Agile helps businesses deliver instant value at scale. For organisations to survive the volatile market, they found it rational to embrace Agile. Today, there are over 70 different Agile practices, many of which are still evolving. In this article, I will seek to bust the myth that Agile is only for software development and explain how it can be applied to your non-software development teams. Make budgeting great again – The flexibility of Beyond Budgeting start! At the heart of traditional project management, the budgeting process and the budgeting mindset is still king. Organisations are used to drawing up quarterly budgets for five quarters, re-assessing it at the end of each quarter and make changes where needed. In order for organisations to become more responsive to the changing needs of the customers, the budgeting process must be addressed for organisations to become more Agile. As Bjarte Bogsnes has pointed out: “One of the most stubborn myths in traditional management is that the only way to manage cost is through detailed annual cost budgets, with a tight follow-up to ensure that no more is spent than is handed out”. The lack of flexibility can lead to wasted resources and effort if it no longer responds to the customer’s need. To bust this age-old myth, organisations can benefit from transitioning from a traditional budgeting process to Beyond Budgeting. Beyond Budgeting is the practice of creating shorter rolling budgets and reviewing them at regular intervals. Credit: Bjarte Bogsnes No matter what team you belong to, a company survives on delivering value to their clients. If your team is constantly looking to improve their work according to the customers need in shorter intervals, then the budgeting within the organization must match the strategic vision. Toyota – the car manufacturer, for example, made resources available just-in-time to meet each customer order. Beyond Budgeting allows more room for flexibility and improvement at shorter intervals. This process ensures your ideas responds quickly to customers idea and deliver value. By embracing Agile, it is not a call for companies to abandon the construction of a roadmap. It is still essential for companies to adhere the iterations to a long-term goal. For me, this goal should be accompanied by a cost-conscious mindset as well as making resources available as needed. Traditional budgeting in many ways has obstructed the nimbleness of companies. If other teams and projects can adopt Agile to become more efficient, it can lead to more valuable outcomes for the customers. Limiting work-in-progress (WIP) and maintain a consistent workflow Imagine chewing a piece of gum and watching TV at the same time, it’s easy to do both at the same time right? Now try to engage a conversation with someone and reading a book at the same time; it’s an impossible task to focus on both. The idea of “multi-tasking” has always been a buzzword in the business world. However, when we try to multitask, it diminishes our brain’s ability to focus and maintain attention on a single task. When we try to multitask too much, we won’t perform those tasks well, as our brain will try to take in too much information. This idea can similarly apply to the workflows of any non-software projects. Kanban methodology has taught us that we should limit our work-in-progress.Instead of juggling 10 tasks at the same time, it’s much more productive to focus on at most three tasks at hand. Credit: Roger Brown Any other teams should also possess a “stop starting, start finishing” mindset. According to the graph above, by distributing time on different projects, it’s actually reducing time in each project and creating waste that is not necessary for creating customer value. Jerry Weinberg, a computer scientist has shown that even if you account for a 10% penalty for each context switch, in reality the cost is even higher. Even as Agile preaches the positives of forming a cross-functional team, team members should not seek to multitask on different projects with a wide spectrum of context. For example, when a team member leaves to do work that is not related to the team’s work, the rest of the team has to compensate for the time lost as well as helping the returning member to catch up on the context in his/her absence. Through setting WIP limits, it helps teams to reduce context switching and avoid slowing down the team with an ever-expanding scope of work. This practice also reduces the number of mistakes committed by teams overloaded with tasks. Agile at work: the implementation of Agile Marketing To encourage non-software development teams to embrace Agile, it’s important to demonstrate the value and cultural changes that an Agile approach can deliver. I would seek to explain these valuable outcomes with the implementation of Agile Marketing. Agile Marketing can be defined as an Agile approach in which teams “identify and focus their collective efforts on high-value projects, complete those projects cooperatively, measure their impact, and then continuously and incrementally improve the results over time”. Since the approach embraces rapid iterations and data-driven decision making, it ensures your marketing investment is being optimised. Credit: Inbics To implement Agile Marketing, a marketing team should seek to develop flexible roadmaps of projects and tests instead of rigid upfront planning that is not adaptable to changing conditions. For example, a marketing team can release a part of a marketing campaign to selected users. Through this approach, the team can collect valuable data and user metrics to determine their likes and dislikes. The collection of this data will also help the marketing team to continuously improve their content. Agile Marketing embraces the visualisation of the team’s current workflow. The transparency of the project is amplified by increasing communication and honesty. Agile supports the team to collectively own the process of the project and encourage them to speak up and contribute to the project vision. With the aid of project management tools, stakeholders and team members can be aware of what’s going on at all times during the project lifecycle, including the team’s responsibilities and how money from clients is being spent. In addition, Agile Marketing serves as a risk buffer, as companies no longer have to pour in huge funds into a single marketing campaign that users may not be attracted to. As long as you can help your teams improve their communication and workflows, you are one step closer to Agile success. In reality, there is no one-size-fits-all approach to introduce Agile to your non-software development projects and teams. Final thoughts Most importantly, don’t be afraid to experiment with Agile. You should not coerce your team into an approach that does not fit their need. You should strive for continuous improvement, and never be complacent about adopting new ways to implement Agile with your non-software development projects and teams.

How to foster mentorship in a team? The traditional way of helping someone improve in their work is to provide constructive feedback. i.e., you observe something, you tell the person “here is what I have observed, and I think you could improve by doing this…”. At PALO IT, we meet regularly to share and learn from each other. In our last team gathering, I suggested we try the Feedforward exercise inspired by Avraham Kluger, Organisational Consultant, and Marshall Goldsmith, Executive Coach. It is a technique to give and frame suggestions in a much more powerful and positive way than standard feedback. Let’s start! 1/ Introduce the exercise by saying something like: “We are going to do a Feedforward exercise where each of us is going to receive suggestions from the others. Each suggestion should be treated as a gift. A gift is something you receive, you don’t always like it but you always say thank you.” This way of introducing the exercise is to reinforce an attitude that should always prevail: respect each others’ ideas, don’t be judgmental and express yourself. 2/ Ask your team members to each think of one thing they want to improve. It can be anything. 3/ Form pairs. In each pair, team member A says “I want to improve…”. Team member B says “Then you could try to…”. 4/ Reverse roles. Team member B says “I want to improve…”. Team member A says “Then you could try to…”. 5/ Split and form new pairs. Continue until everyone has talked to everyone. At the end, I asked each team member to give me one word to express what they felt and the results were amazing: “Energised”, “Positive”, “Great”, “Inspired”. And they asked to do it again the next time we meet! The numerous benefits of this practice The “no judgement” style makes people feel comfortable on both sides, receiving and providing suggestions. Because the person receiving advice is choosing the topic, it is perceived in a much more positive way than typical feedback. We don’t focus on saying what is not done well up to now, but what you can start doing from this moment forward. Again reinforcing positive communication methods. Team members get advice from different people with different backgrounds and skills. Team members get to give advice even though they may be junior. It is a way to learn to be self-introspective regardless of experience, as well as gain confidence in expressing ideas. Everyone participates, but with an one-to-one approach. This puts less pressure on people who are shy. I recommend you, as a Leader, to also participate. It makes everyone feel on the same level. You will lead by example and of course you end up learning new things as well. Conclusion For all the reasons above, Feedforward is a much more positive exercise than giving feedback in a traditional manner. You can also use it for one-to-one sessions with your team members, however I think the group version is even more powerful. If you want to learn more about this Feedforward interpersonal improvement activity designed for team and organisations, I invite you to watch the following video: And you? Have you ever tried it yourself? I would love to hear about your experience!