In short…no. Or, not easily. Or…not very well. A stakeholder is not a user. To satisfy a user need you need to focus on the user. By definition, a stakeholder is not a user. They might be able to help but they cannot offer the insight vital to UX success.
In the corporate learning world, stakeholders have a powerful position in most projects. Often they have the most powerful seat at a small table (along with subject matter experts who should not do UX either). Still, they are not users.
Stakeholders are very good at describing what they want users to want. This does not qualify them to define what users actually want, however. Unless they have evidence. Evidence direct from users. Very often they do not.
Before I suffer the slings of accusation about a closed mind, let me expand my thinking. A stakeholder has a vital role in defining a business problem or need. Something that needs to be improved, stopped, or started. Business requirements. These are the stuff of the stakeholder. The business metrics that need to change need to be described and analysed to scope a response. A learning project rarely starts without these inputs. There are enlightened stakeholders with supporting evidence and user insight. This is great and useful grist to the mill of UX testing. It is not the full UX answer though. That must come from users.
Insight on user needs can come from many sources, including: talking to them, surveying them, studying use of products and tools, product usage analysis, social media, feedback links, feedback mail. The significant point (for me) is that it should be unmediated and direct to the product owner. Interpretation and response to user data is what product owners are for. The best of the can translate this into stakeholder friendly stories and evidence.
Last week, during a UX workshop I was facilitating, we talked about “the head office bubble”. A central learning team, talking to fellow head office stakeholders about how best to design a digital learning experience is a familiar scene. Add some more corporate subject matter experts and an elegant, self-affirming bubble is easy to create. We are all hard-working and well-meaning but with no user voice it is not a full conversation.
MR Digital & Learning 
I absolutely agree with this. During a “lessons learned” meeting for a previous project, I spent 4 hours in a room talking about data collection, change control processes and intra-project communication.
The value for me came when one senior stakeholder raised a concern that some members of the team (and I fully acknowledge that I fall in to this trap) expressed their personal opinion as being representative of what the “users” wanted.
This made me reflect on the fact that while I see my role as being that of an “end user advocate” on any project, I don’t spend enough time actually talking to them. Instead, I make assumptions that confirm my own views.
So why do I still do this? The main reason, I think, is the fear of getting an answer you don’t want. That in itself is not a bad thing – as learning professionals we all develop a thick skin. Where it’s bad is that you then have to report that back to the project team, who will from that point on consider you to be a blocker – endangering both timelines and scope.
For me, this discussion needs to happen much earlier in projects and UX, training, comms, change management need to have access to the users much earlier on in the process than generally happens. That way, the user feedback can actually be included in the initial planning.
However, this is unlikely as long as change is driven from the top, i.e. not by users (or consumers of whatever change is planned). The people who drive – and pay for – projects, do not have the same objectives as the users. So if a user wants something done in a particular way, but this adds cost or time to the achievement of the stakeholder objectives, it’s likely to be rejected.
Or more likely, listed in the risk register as a “training issue” and kicked in to the long grass.
Good point James. If user needs are not explicitly considered from the outset, they can make a very inconvenient addition when a project is up and running. More user evidence is needed in those early planning documents – somehow…