Summary: Goals are slippery beasts. Not only do you need to help the team articulate what their goals are, you have to help them differentiate between goals and objectives, the direction and the feature or service.
When you start a project, everyone in the room already knows what their goals are. Three problems exist:
- They can't articulate their goals, so they cant make decisions against them, or
- They know they know their goals, but haven't shared them, so they have no way of knowing if they're all working towards the same goals, or
- They've articulated and shared their goals, but not everyone understands or agrees with the goals.
Whenever I run strategy workshops, I start with goals, first. Collecting goals is as simple as asking someone what their goal is.
Unfortunately, some goals and a good team won't get you anywhere. This is why this series began with a look at the strategic landscape. We started this series on UX Strategy by defining strategy as getting from your current state to your future state. Second, we talked about the factors that push your organization to change, drivers. Then we talked about factors that prevent your organization from changing: technological, cultural, process, and people barriers.
The current state, future state, drivers, and barriers, these represent the context that frames your strategy. Goals connect it all together.
In a post about his UX Strategy Blueprint, James Kalbach defines strategy as being "about uncovering the key challenges in a situation and devising a way of coordinating effort to overcome them for a desired outcome." James is talking about barriers, goals, and future states. In James's words, your goals are an "interlocking set of choices that aligns activity and shows causality: if we do this, then we expect to see that."
A large retail chain I've worked with wanted a customer portal for business customers. That's not a goal. That's a service offering: we will have a portal for business customers. They had two goals:
- make it easier for customers to do business with them, and
- provide more personalized marketing to customers.
Doing this and expecting that applies to specific activities. If we build a customer portal, users will use it to self-service. You need to document this assumption, but that's more tactical, more of an objective, something concrete to achieve.
A goal is directional. If we improve customer service (the goal), our users will be more engaged (future state). The goal doesn't say how the goal will be accomplished (a customer portal). It merely states that in order to reach the future state, you are going to head in this direction.
The service offering, or feature, answers the question: How? How will we improve customer service? We will build a portal with self-service features. To fulfill the goal and reach the future state, we will build a customer portal. In pursuing their goals, they want to offer the service of a customer portal.
Some more example goals:
- Make it easier to enjoy music (iPod)
- Make it easier to collaborate (Sharepoint)
- Make it easier to market across channels (Sitecore)
You'll notice that none of these goals prescribe how something will happen, only that you want it to happen. They're the direction you will go in. Not what will exist when you get there.
Driving goals, the strategic landscape
Just a quick reminder about the context around the goals.
Goals exist for a reason. This reason for the goal is the driver. Sometimes it's a top-down directive from the CEO, their vision for where the company should go. Other times, competitors drive you. Maybe they will eat your market share if you don't change. Whatever it is, there's always a reason for the goal.
Similarly, something is stopping you from achieving your goals. These reasons are the barriers we identified in the previous post. Barriers block you from accomplishing your goal. You have to overcome those barriers in order to follow your goal and transform from your current state to your future state.
Often, when you ask someone about their goal, they respond with a feature: we want to build a customer portal. When they articulate their goal as a feature, ask "why?". Why do they want to build a customer portal? The answer to why they want to create a service or feature is usually the goal. If its not, then ask why again. And again. You will dig down to the goal.
In organizations with a more mature process, they may have defined a project's goals. In these cases, you spend less time identifying and collecting goals, and focus on evaluating and validating the goals with the project team.
That makes it sound easy, but helping a team evaluate their goals is where the heavy lifting occurs. It requires you've identified a reasonable number of goals and that you have identified the right kinds of goals. In the next two pieces in this series, we'll explore both of these ideas:
- How to differentiate between organizational goals and project goals
- How to align diverse stakeholder groups around a limited set of achievable goals
It's not as easy as just collecting a list of goals from your team. Each level of your organization works towards a different set of goals. In the next piece, we examine how to differentiate the different types of goals and help your team focus in on the project goals.
Expand your knowledge
I'm a huge fan of the way a book can explore a topic in depth. If you'd like to learn more, try one of these books. (As a bonus, this site earns a modest pittance when you do.)