Stakeholders are real people involved in or affected by the project. Personas are analytical tools for representing users who will eventually use the product. Both matter — and confusing them leads to work that satisfies the business but frustrates the actual user.
Stakeholders: BABOK categorizes them by role — business sponsor, end user, subject matter expert, regulator, implementation SME. The key analytical tool is the stakeholder matrix: influence vs. interest. High influence, high interest → actively involve. High influence, low interest → keep informed. Low influence, high interest → keep updated. Low influence, low interest → monitor.
The mistake is treating all stakeholders the same. Pulling a high-influence, low-interest executive into every refinement meeting wastes their time and creates noise. Not keeping them informed at the right cadence loses their sponsorship.
Personas: A persona is a fictional but research-grounded representation of a user segment. It gives the team a shared mental model to reason from.
"By creating a clear and detailed persona, the analyst reduces the likelihood that user needs will be overlooked or replaced by the personal preferences of team members who imagine themselves as the users." — from User Stories notes
The practical test: "Would Maya (a time-pressured accountant) use this feature?" is more actionable than "would some users like this?" A persona name turns an abstract group into someone the team can argue about concretely.
On the Uvents project, we had three user segments with genuinely different goals. Without personas, every feature discussion defaulted to "what does the average user want?" — which described nobody. Defining the segments gave us a prioritization framework.
Exam tip: CBAP stakeholder questions often test engagement approach. A stakeholder with high influence but low interest should be kept informed, not deeply involved. Pushing information to them is the correct approach — not pulling them into every session.