Engage your stakeholders to build useful software
How to create a shared understanding with your stakeholders and optimize your collaboration.
Engage, don’t try to manage
Stakeholders are not mythical beings that care only about their agenda and send random requirements that even they are unsure of.
They are part of the team that is responsible to deliver value and keep the organization afloat and thriving. They have vast business knowledge that you need to gain access to in order to better understand business needs, processes, and limitations.
So, you meet in order to collaborate and create value for the organization and its customers/users. You try to do this either via software or by updating your processes, or both. Often, they have their kick-ass ideas that often are translated into software requirements and perhaps UI suggestions, “you know what would make the users really happy? A blue button there! I love the color blue!”.
It is imperative that you remain calm and focused. Remember that these people want the best for the organization as well. Their intentions are good. It’s just that they do not know how building software works. You do. It’s your job. And it’s part of your job, do educate them about it, and set realistic expectations.
Talk is easy! How do you do this?
If you feel like this, I’m with you. It is not easy, and, like most things in life, there is no one solution that is optimal for each occasion.
Here is a story from the last time our team attempted something like this. We visited the company’s headquarters in Dubai. We had arranged a series of meetings, interviews, and contextual inquiries with key stakeholders and users.
Our CTO had arranged a meeting with C-level executives and key stakeholders (some were actual users of the systems we are designing for).
We started this meeting by setting the foundations and then built from there.
A foundation to build upon
There are three areas at play that we must consider. Business, Technology, and Design.
If we only focus on Business and Design, we most probably end up with things that aren’t technologically feasible.
If we only focus on Business and Technology, we will be creating things that no one wants and is able to use.
If we only focus on Technology and Design, then this is our hobby.
We explained that in order to create useful tools and processes, we must hit the sweet spot at the intersection of Business, Technology, and Design. In any other case, we would be wasting resources.
We kept mentioning that we must focus on outcomes, not output. Outcomes linked to KPIs the organization cares for. Build the right things. The ones that will bring value and will move the needle.
Want to know more about why outcomes outweigh output? Check out this cool presentation from John Pagonis.
Who does what?
We, the visiting IT crew (PO & UX), represent the Technology and Design areas. We know how these work and it’s our job to utilize our knowledge to create useful tools for the organization.
What we do not know, is the Business, the nitty-gritty. The day to day struggles and goals. It is them, the Stakeholders that know about this, and, we need their help in order for us to be able to help them back! Don’t get me wrong, POs know a lot about the business side and, UXers will do as well, the more they interact with stakeholders and users. We used this trick to prime them to be more open to talking with us and, make sure that we don’t look like we believe we know everything.
We need some of their time to make sure we understand them correctly and we will be solving the right problems for them. The way we do this is through research. Interviews, contextual inquiries, usability studies, etc.
Expectations VS reality
To help them understand why we work like this, we’ve shown them the following example of expectations VS reality in software, for an imaginative three-month project.
We explained the issues that arise if we don’t communicate often, test regularly, and, ship at the end of the project.
Gaps in understanding, new knowledge, and changes in the ecosystem in which the company operates can lead us to end up with a suboptimal tool, a ton of wasted money and them having to work with something that doesn't solve their problems.
Remind them of the complexity
Another tool we utilized, was a map of the company’s departments, their relationships, flows, and dependencies. All these, in combination with the internal and external systems, used, our suppliers and clients, offer a visual of the complexity we have to handle in each step so that the system doesn't break apart.
This helped us communicate that even the smallest request might have “tentacles” that aren’t visible and needs to be treated carefully.
How we work and why
Next, we communicated our processes, at a high level, and the key benefit for each one.
We began by explaining our UX process and set expectations of how often we will be talking to them and test things with people from their department.
We explained how each research method works (at a high level) and the value it brings.
Next, we discussed how we work as a SCRUM team.
Our team works in two-week sprints. We do the planning at the start, and no new item is added to our backlog until the next sprint. So unless there is a killer bug in production, all other requests will be parked for further prioritization on the upcoming sprints.
At this point, we adjusted the three-month project example to show how something like this will work and set their expectations.
Even we begin the project with the same gaps in understanding as in previous examples (which is highly unlikely due to initial research and workshops with users and stakeholders), testing weekly and releasing biweekly, will help us course-correct and always moving towards a more desired state. Even if something that we thought of as a constant, changes, we will be able to adjust to this.
We work this way so that we can make sure we:
- •Solve the right problems
- •Create usable solutions
- •Adapt to their needs
- •Prioritise goals & resources
- •Learn faster what works & what doesn’t
“There’s always more to build than we have time or resources to do so ,always.”
So far so good
Till now we have discussed the importance of collaboration, research, and the way we work. We have set expectations on multiple steps, and we’ve built the foundation for our common understanding and healthy collaboration.
What next?
At this point, we dropped the idea that for all the reasons we discussed earlier, we would like them to help us help them! We want to build better tools through collaboration.
To do this, we asked them (stakeholders and/or people in their departments) to spend 4 hours per week helping us with UX research. Either contextual inquiries, interviews, usability studies, etc.
Four hours per week? Are you mad?
This could sound too much, especially on occasions that everyone is working like crazy.
We’ve showcased the importance of research before, but we needed something to help them get over this new shock. This should be something expressed in their language.
Enter the ROI example
To do this, we’ll use the previously mentioned three-month project (13 weeks), and $1000 as an example salary for our calculations.
So, for 4 hours per week, 520 hours in 13 weeks, the investment for UX research is $300. This is how much time we will require from people in order to do our research and testing.
Let’s say that from this, we manage to make a task 30 seconds faster (at that point, this was a rather pessimistic example). This task, is being performed 20 times per day, which eventually saves a total of 10.56 hours in 13 weeks. This will result in $61 savings!
Yet, this task, is performed by all 60 employees of that department. Which in fact, will have an ROI of $3,660 over 13 weeks. Another $3,660 in the next 13 weeks and so on.
For a pessimistic example, we would need to invest $300 in order to save $3,660. This is over 24 times the investment. Not bad, eh?
Keep in mind that this is a pessimistic example and is focused only on the time-on-task metric. There are many more we can improve.
Now, it is important to communicate the truth, so you should explain to your stakeholders that they will not see this amount in the bank account, as they will continue to pay the salaries of employees. What happens here is, that these employees, will spend their time doing something more valuable for the company.
It is important to close the presentation with something they understand and that will stick. Talking ROI and numbers help a lot when talking with executives.
So, is everyone a UX enthusiast in your organization now?
Nope. Not even close.
Most people in the room probably didn’t get all the nitty-gritty of the presentation. But that is OK and should be expected.
Yet, we managed to get our message across to a couple of key stakeholders and execs. This resulted in buy-in for what we actually needed. They became facilitators -instead of gatekeepers.
This is a huge win and its effects will be multiplied by each useful feature you release. These people will become UX ambassadors in the organization as they’ve experienced the benefits first hand!
Conclusion & takeaways?
Engage your stakeholders, don’t try to manage them
You are part of the same team and you want to improve the position of the organization. Find a common ground and build there.
Educate, explain, listen & learn
You have complimentary knowledge. Use this to inform your decisions and you will create better solutions on every iteration.
Point to shared goals & KPIs
When in conflict, point to something you agree is a goal, a KPI, and link this to your point to communicate. Do the same thing to curb your ego and make better decisions.
Outcomes over output
Focus on the value you provide and not how much software you release. No one uses what you build just for the sake of it. They use it to meet a need of theirs.
Evidence over opinions
When faced by HIPPOs just point to the previous step and back your proposals with data and insights. This way it is not your opinion against theirs.
This will take time and mistakes will happen. Keep at it, stay patient and celebrate each small win
This is a big project that will lead to increased UX maturity for the organization. This is not a single “battle”. You will need to do this many times until it’s part of the organization’s culture. Yet, do not let this discourage you. Stay patient, identify each win and opportunity, and celebrate these!
There is no solution-fits-all
This is a case study of what worked for us so far. This doesn’t mean you should follow each step to the letter. Keep what works for you and add your own things. Adjust, iterate and you will improve upon each iteration.
You’ve made it this far, cheers!
I’m happy that you’ve made it to the end of this part of the story!
I’m equally curious to know your thoughts and feedback. Have you tried something similar? Do you have other ways of doing this? What works best for you?
P.s. Having a PO that understands UX is a huge facilitator and I’m lucky to work with one of them. They are a rare species!
