Let’s do a quick status check…

Are your customer experience projects achieving your business goals?

• Do you identify business goals when you launch a project?
• Do you communicate your business goals?
• Do all team members know and understand them?
• Do you align your business goals to your customers’ goals?

If you are, fantastic! You’re ahead of the competition!

For most companies, goals live in the board room. They are created there where projects are funded, and outcomes are found at the end of the project to justify the money spent. Rarely, do project teams understand the business goals and even more rarely do they use these goals to make front-line decisions on the project. Without a deliberate tie from goals to decisions, the outcomes will miss expectations, take extra effort to achieve, or both.

In our experience, there are five foundational steps to align action to goals and to maximize the opportunity for success in a deliberate way. In this article, we’ll take you through these steps, share tips on how to achieve them and share stories from the field.

What are the 5 Foundational Steps?

1. Define Your Business Goals

Many projects define success as completing code writing, launching a product, or achieving approval of the platform. None of these deliver any business value in and of themselves. At the outset of a project, you should start by identifying business objectives. As part of an initiative funding cycle, target metrics may have been identified as part of the business case. If you have a business case, phenomenal, you’re off to a great start. But you should still critically evaluate the goals to ensure they’re both detailed enough and meaningful. The SMART framework, OKR and Lean Canvas are all good options to use when articulating business goals. If you don’t have a business case, the beginning of your project is the perfect time to define your business goals for the initiative.

When defining your desired business goals, there are a few things to consider.

First, are the goals specific enough and detailed enough? Are the goals measurable? If a goal is high level, for example, increasing revenue, spend some time decomposing it to better understand the intent. Rather than increase revenue, your goal might be increase revenue by improving subscription renewals for enterprise customers. This goal gets to the specific driver of revenue, as well as the target customer segment.

Next, can you measure the goal and does it have a specific target. With our prior example, we may want to set the goal as increasing customer renewals by 5% in the specified customer base. This is important as it ties to the business case and enables you to articulate the ROI of your initiative.

One area of pushback I get is that these are internal goals and don’t reflect the customer or the market. My response is that an understanding of both the customer needs and the market should go into the decision to fund an initiative and be a driver of the goals. In short, projects should be an outcome of a strategy that includes the lenses of the customer, the market and the long-term vision of the organization.

2. Socialize your business goals

Now that you have your business goals articulated, it’s critical that they’re shared with the entire team. This includes not just executives and key stakeholders, but most importantly the execution team. Socializing goals is critical to empower the team with ownership of the goals. Whether this team be internal or external, they are all making hundreds, if not thousands of decisions on everything from design to architecture, to code quality. Understanding the specific business goals, better equips the entire team to make these decisions.

When visiting NAB in Melbourne, Australia a few years ago, we observed projects teams posting their business goals on the wall around a team room, alongside journey maps, wireframes and other project tools. Prominently posting project goals keeps these top of mind as team members are making decisions and helps the project remain focused as they navigate due dates, deliverables and milestones.

3. Understand your customer’s goals

Business goals are great, but they are internal. And, yes, this is true even if you used an understanding of customer needs to create your business goals. Business value comes from delivering customer value. This means that you’ve made the customer’s life better, their work easier, their insights greater and you’ve done it in a way that’s enjoyable (or at least not a grind). Step 3 is to understand your customers goals and align them to your business goals.

By understanding your customer goals, you can:

1. Understand what you need to do to change your customers behavior and achieve your business goals.
2. Develop a better sense of how realistic your business goals really are (if your customer base doesn’t want your product, achieving renewals may be a challenging goal).

Ideally you can align your customers goals to your business goals. For example, if your business goal is to increase renewals by 5% for enterprise customers, you’ll want to understand the drivers of loyalty, how that market makes renewal decisions and what their alternatives are (There are some differences in B2B vs. B2C here where the buyer and the user may be different people with different agendas, but that’s a topic for another discussion). You may find that the customer’s goal is to perform a task rapidly or is more interested in quality of the data. These insights allow you to create customer goals and tie them to business goals. They are also the basis for how you create solutions within the project to meet those needs. It’s this tying of business goals to customer goals to solutions that creates traceability and enables a team to make decisions on priorities, designs, architectures, content, and everything that goes on within a project. Now the team has a straight line of sight from solution back to business goals.

One thing that’s important to be aware of here is to treat business goals (and customer goals) as hypotheses.  As you continue to discover more, both through research with customers as well as measuring outcomes, the new data may lead to the need to reformulate your goals hypothesis.  This is relatively easy with small goals and customer goals.  You can simply realign your projects to your improved understanding of the situation.  With bigger discoveries (at the extreme, you discover that no customer really wants your product), you’d have a more strategic discussion with the business.  The earlier and more often you test and measure your hypothesis, the better your outcomes will be.  I’ve seen some businesses and executives who are more open to this conversation and can digest what it means and either redirect the project or business strategy.  Others are less amenable to this conversation.

4. Measure your outcomes

In theory, this next step is obvious.  You need to measure the performance of your project and compare it to your customer goals and your business goals.  The challenge here is often how measurable your goals were in the first place.  Beyond that is the fact that data often takes time.  Ideally, you’d be able to take that data and use it to adjust the path of your project.  But if it takes 2,4,6 months to collect data, you may have finished the work, or at least be on to other parts of it.

Defining your MMP (Minimum Measurable Product)

This is where teams should strive to think differently about how they deliver.  Most project teams today utilize some variant of Agile, with the goal of delivering more efficiently and less wastefully.  One of the tragedies of agile is how one of its core tenants, the Minimum Viable Product (MVP), has turned into debates on getting as much into the MVP.  It’s a fight over what Viable actually means, with many stakeholders pushing more functionality into an MVP than is really necessary to get feedback.  Here I propose a different tact.  You want to get software into the hands of users as early and as frequently as possible.  You do this to get feedback on how it works (against the goals) in addition to how well your team is solutioning in response to the feedback.  Here, I’d propose a different metric.  Rather than MVP, I encourage teams to think about the Minimum Measurable Product (MMP).  The MMP is the smallest unit of functionality that enables you to measure outcomes against customer goals or business goals.