We’re all on the same side here…aren’t we?
In a previous post, I told you a story about me screwing up — and how I lived to tell the tale 😉
A big part of that failure was not doing the work upfront to learn all I could about all the players involved in the project and the product. I never looked past my initial contact, who was the head of Product Marketing. And as you saw, I got all sorts of unpleasant surprises later on down the road as a result.
Who you have in the room in the beginning and throughout the project matters a great deal, because in every organization there are internal struggles that you know nothing about.
Every single person at the table — especially if they work for different departments and have different job roles — automatically have very different goals. They have different and sometimes competing ideas about what success is (or isn’t).
And a lot of times, those ideas are directly related to their job, their position, their responsibilities. Their convictions and opinions are born from the pressure that they’re under to perform. So stakeholder arguments about what to do, how to do it and why it matters are inevitable, but they’re also incredibly valuable — if you have the patience and courage to (1) allow them to happen and (2) guide them when they do.
Now, there’s only so much you can do without treading into territory where you’re not welcome. But you want to do everything in your power to get those people in the room, to hear them out. To learn who’s on what side and why.
If they’re going to have arguments, you want them to happen in front of you because you need to see them. You need to read the terrain. You need to know what’s going on, what forces are acting on the possible outcome of your work.
If you don’t do this, you get yourself in a very precarious position later on, as I did. So instead, you should always ask, “what other departments are involved in this? Can we get them in this meeting or the next meeting?”
The answer may be no, of course. But I think it’s still a valuable question to ask because a lot of times the exchange will go something like this:
STAKEHOLDER: “Why do you feel like they need to be there?”
YOU: “Well, they’re responsible for X, right? That makes me think the outcome affects their world (in this way). Do you think their input might improve our chances of success?”
STAKEHOLDER: “Yeah, you know…I didn’t think of that, but you might have a point. Maybe they should be in this meeting.”
It’s not always this easy, but I think you have to try and expose this stuff. Not just for your own sake but for the sake of success for all parties. To make sure you all go down a path where your stated desired outcome — and the project requirements that map to it — are relevant, important and achievable.
You have to get comfortable taking traditionally disparate parts of the upfront budgeting, scoping and requirements processes — and all the strategic activities that happen during a project — and focus them all through the lens of UX. That’s a tall order, but it’s also more than possible.
I say that because I’ve done it, and over the past 26+ years I’ve watched numerous enterprise product teams learn to do the same. Not coincidentally, all of these methods are covered in detail in my UX Requirements Made Simple course.
It’s part of my NEW online school, the UX 365 Academy.
Check out UX 365 and UX Requirements Made Simple >
I created that course out of a very selfish need to end miscommunication; I needed tools I could use to teach teams and stakeholders to work together differently. I needed some concrete ways to show them that they were actually on the same side — but were doing a really terrible job communicating with each other.
I needed practical methods that Design & Dev teams could use to show stakeholders they were on their side.
I wanted the training sessions to make it painfully clear to all parties that what you do at the outset of the project plants the seeds for either success or failure. You’re making a choice, consciously or not, about which you’re going to grow.
And once you do that, there’s no going back — so you had better choose wisely.
GIVE GOOD UX!
— Joe
P.S. You can check out the UX Requirements Made Simple course at my UX 365 Academy. It covers everything I know about encouraging collaboration between project teams and stakeholders — and ensuring they’re all focused on asking the right questions, solving the right problems, and building something of measurable value.
