In our earlier article about managing stakeholder goals, we looked at the relationships between principal stakeholder goals and end-user stakeholder goals. We also showed a way to trace those dependencies. But that approach does not provide us with any insight about the alignment (or lack thereof) between differing goals. This article explores a means to visualize those relationships.
Principals and End Users
We identified four classes of stakeholders in our previous article on managing stakeholder goals.
- Principals – the business sponsors for a product or project. These folks have business goals they are trying to achieve. Your mission is to understand those goals. You also need to recognize that they may be moving targets, and be prepared to adapt to those changes. And we need to understand why they want what they want.
- End Users – the people who ultimately interact with the software. The best software development processes are focused on satisfying the end users. And a lot of authors are out there teaching us how to do that, although none perhaps as visibly as Alan Cooper.
- Partners – people who are neither principals nor end users. These are the folks who don’t directly benefit from your product, don’t use it directly, and didn’t help create it. But they are responsible for helping your product live, thrive, and interact with other products. Think IT people, keeping your system running, and keeping other systems talking to it.
- Insiders – the people who define the product. Your (internal) team. Not only product managers and developers, but business folks, marketers, testers, support staff, finance, etc. The people creating a product influence what ends up being created. And they are stakeholders in a narrow scope – they are affected by the creation and ongoing support of your product.
We alluded to the possibility that principals and end users have goals that may or may not be aligned with each other. When we manage those goals via traceability, we can clearly see when a user goal supports a principal goal. What we can’t see is the magnitude of alignment between the goals. We also have no insight into conflicting goals.
End User Goals
You can identify end user goals with the following approach:
- Identify the actors that interact with the software.
- Identify the personas that represent those actors – thus avoiding the elastic user syndrome.
- Develop an understanding of the personal goals of the personas – and by extension, the actors through ethnographic research.
Principal Goals
We write about goal-driven, or goal directed requirements a lot. With principal stakeholders, who are not direct users of the software, goals are usually related to the metrics by which they are judged. These are often metrics that tie to ROI for their employer, and focus on the principal’s sphere of influence. Examples might be reducing costs in their department, or growing market share.
Sometimes, the user’s goals are aligned with the principal’s goals, and sometimes they are not.
End User Goals
Imagine you’re working on a product for a call center. Following the example above, you identify one of the actors as a call center rep. You then study the reps and develop a persona that represents them effectively. You identify Fred Jackson as your persona
You spend time understanding the desires of that persona and you develop a set of personal goals. You relate those back to their job and find the following set of goals:
Fred wants to earn a bonus. In the call center, this translates into
- Reducing the time the rep spends on each support call.
- Reducing the percentage of “unsolved” calls that the rep has to escalate to a more experienced (tier 2) rep.
Fred also wants to earn a promotion from his current “tier 1” role to a “tier 2” role. Tier 2 reps only field the calls that the tier 1 reps can not solve. These reps earn more, and only work on the “hard” problems. This translates into
- Increasing the rep’s level of knowledge.
Principal Goals
With this understanding of the goals of the end user, you can now look at the goals of the principal. In our example, the principal is the manager of the call center – Jane. Jane’s performance is measured by looking at several operational measurements of the call center. Based on those measurements, Jane’s goals are as follows:
- Reduce Employee Training Costs (Low priority)
- Reduce Call Center Labor Costs (Medium priority)
- Increase the Satisfaction Rating found by third party surveyors of the callers (High priority)
- Reduce Call Center Overhead Costs (Medium priority)
In an ideal world, the prioritization will be based purely on ROI. In the real world, the priorities, in the opinion of this principal, will be aligned with the principal’s goals. And those goals are often reflective of how the principal’s performance is evaluated.
Goal Alignment
You can see some obvious alignment – reducing the time spent per call will reduce labor costs (either by handling more growth with fewer new hires, or by reducing the workforce, or by freeing up time for the reps so that they can invest it in other areas). What you can’t easily see is when the goals are unrelated – or when the goals are potentially conflicting.
You can create a grid that lists end user goals along the side, and principal goals across the top. Using the examples above, you would get a graph that looks like the following:
Each actor goal has a row in the table, and each principal goal has a column. The number in the intersection represents the alignment of the two goals. Positive numbers represent positive alignment, negative numbers reflect goals in opposition, and a zero indicates that the two goals are unrelated.
In the table above, the “Reduce Time Per Call” user goal is unrelated to the principal’s goals of reducing training costs and reducing overhead costs. The “Reduce Time Per Call” goal has a positive alignment with the goal of increasing customer satisfaction, and a strong alignment with the goal of reducing the labor costs for the department.
Opposing Goals
In the example above, the user goal of increasing knowledge is in opposition to the goal of reducing training costs.
This does not mean that one goal must be sacrificed for the other (although that might be what you decide to do). What it indicates is that the most obvious approaches to achieving the goals are in opposition. A negative number is, in effect, a call to arms to invent an approach that makes a positive alignment (killing two birds with one stone).
We’ve shown that personal goals can contribute to design decisions in the software development process. Your challenge is to come up with an approach that eliminates the negative relationship and creates a positive one. You have to make some of these decisions before completing the software requirements specification.
For example, you could choose to design software that walks reps through a decision tree when addressing a caller’s needs. You could include notes, background data, and statistics in the user interface that help a rep learn while doing. This will have little impact on the time it takes to resolve a call, without introducing extra training costs. This approach would turn the goals into complimentary goals.
What Do You Think?
What do you think about this approach?
While I like the correlation of a principal’s goals with that of the end users, I have two points of concern (probably ideas to be worked out rather than ultimate stumbling blocks):
1. In many cases, the principal’s interests will utterly trump that of the end users: the software will never be purchased for the end users if the principals are unsatisfied. The matrix you depict shows where there is alignment, which is good, but I’m wondering how to handle this dynamic.
2. Similarly, how might I correlate other data points? Specifically, I’m thinking about the “partner” category. If the partners are excited, they will drive substantial principal and end user enthusiasm (potentially). Three and four-dimensional matrices are probably too hard for most mortals to effectively correlate easily. :-)
Of these two, the first item concerns me more, but I mention the second because partners drive so much of the success of many software solutions, and are grossly underrepresented in many such discussions….
Ted – thanks for commenting – fantastic questions! And those questions are exactly why I am growing to like this model more and more. Without it, we would never ask the questions.
As to point #1: Principal goals trump end user goals.
First – I’ll say “not always” – a few companies that I’ve worked with have user-centric-design as a driver of how they deliver software. In those cases, circling back with principals to highlight the conflict can lead to adaptation of the principal’s goals (or priorities for the goals).
Second – I’ll say that you’re almost always right. Most of the companies I’ve worked with treat users as “little people” – I’m reminded of Mel Brooks’ History of the World, Part 1, where the King of France demonstrates his lack of interest in the peasants. However, I see this as a great opportunity. We’ve shown conflicting goals – that are only in conflict, given an obvious or default solution.
In the example in this article, a user goal of “increase level of knowledge” is only contrasting with the principal goal of “reduce training costs” when increasing the user’s knowledge requires additional spending on training. I see this as an opportunity to encourage the solution designers to come up with an innovative way to kill two birds with one stone – thereby re-aligning the goals. Or at least reducing or removing their incompatibilities.
Imagine a call center rep working his way through a scripted “debug flowchart” as part of handling a service call. Now imagine that instead of just showing the branches at each decision point, you show live statistics of “how many people took each branch?” and “what % of users / callers have this problem?” information. A couple queries and some UI treatment, and suddenly, the monotonous flow-chart becomes an interactive learning tool. The rep gains knowledge just by doing their job.
Another possibility – debugging steps are sometimes in a sequence because they have to be, and sometimes because they simply can’t be done simultaneously. If the flow chart (for the rep) were to show when steps are in an arbitrary sequence – and the flow chart also provided statistical data, the rep could possibly “jump ahead” in the script, leveraging her knowledge to reduce the time spent on the call.
Regardless of the situation, I think the “big mismatches” are great tools for pointing out where we should reinvent solutions, or rethink problems. It ends up being a tool that helps with alignment.
When we don’t have the opportunity to reinvent the solutions, and are forced to deliver something users won’t like but principals will, we have a head’s up. And we can use that information when developing a roll-out strategy, training materials, and any messaging.
Thanks again for commenting – you hit it spot on!
On the one hand…systems exist to create wealth . Always, in one form or another – although any half decent economist will tell you that wealth NEQ money. (See Adam Smith – although it usually is money) .
On the other hand, as a rather controversial economist said, ‘The origin of Wealth is in Labour.’ Systems are at their most effective when the principle and the end user are co-operating to meet the needs of both.
However, systems, like economies, are not always efficient. There are often (always?) inequalities within systems.
Thanks David, and welcome to Tyner Blain!
I agree with your statement. The question is, how does a product manager take that insight and make it actionable?
Well my best guess would be to look at enterprises where goals have been aligned vs enterprises where they haven’t and see if a financial case can be made that one type is better than the other. (You can also make non-financial cases – environmental; worker satisfaction – but, hey, let’s be realistic)
btw – I came across your post for work I’m doing for Chalmers University, Gothenburg. I’m a Human Factors specialist working in the field of Shipping. The same ideas apply to h/w as to s/w.
My intuition is that Swedish enterprises will naturally tend to be goal-aligned, (I’m Scottish) because of their industrial relations history. Scandinavian shipping companies are somewhat renowned for getting the job done while keeping the crews (reasonably) happy.