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.
![](https://novusnorth.com/wp-content/uploads/2022/02/article-dave-feb2022-site-support.png)
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.
“Business value comes from delivering customer value. ”
“Business value comes from delivering customer value”
By understanding your customer goals, you can:
- Understand what you need to do to change your customers behavior and achieve your business goals.
- 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.
“The goals you begin your initiative with are really a hypothesis and your initiative is a series of tests”
“The goals you begin your intiative with are really a hypothesis and your initiative is a series of tests”
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.
“The MMP is the smallest unit of functionality that enables you to measure outcomes against customer goals or business goals”
“The MMP is the smallest unit of functionality that enables you to measure outcomes against customer goals or business goals”
By substituting measurable for viable, we get back to Eric Ries’ definition of MVP as “That version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
By taking viability off the table, you’re now asking the question of what you can measure and focusing on creating a cadence that enables you to pull outcomes into your project lifecycle while it’s in flight. The objective here is to release measurable units of functionality frequently enough to get measurable outcomes. For some teams, this will be every two weeks, for others a monthly release cadence enables more feedback on a particular set of features. This is also a function of how efficient your team is at both measuring and acting on measurements. If you’re just starting off, consider beginning with a longer cycle and compressing the timeframe as you gain proficiency with this approach.
5. Act on your measured outcomes
At this point, your project is well underway. You have your business goals, your customer goals, a release cadence based on MMP, and you are measuring outcomes. This last piece is the critical piece. You’re learning how the product works with a set of users. Now you want to take those learnings, that data, and incorporate it into your backlog and sprint planning. You may find that your solution created so far is working just great. In this case, you can move on with the next items in the backlog. You may find that there are certain features that are underperforming or just plain aren’t working for your users. In this case, you’ll want to add a refactoring of the design or the feature to the backlog and include it in your grooming along with all the other stories. In the grooming and story prioritization, you should include a view on importance of stories to your customer and business goals as one of your evaluation criteria. By doing this, you’ve now got a project model that’s both creating new work, but also reacting to feedback from the field to improve features already released.
In Review
Achieving your business goals from digital experience programs consistently is a matter of a deliberate and informed process. It starts by articulating business goals and aligning them to customer goals. Those goals should be socialized with all participants in the program (stakeholders, leader, team members, and partners) to reinforce an understanding and come to alignment. A consistent release cadence centered around an MMP (Minimum Measureable Product) will provide valued and refined software to your audience frequently. You can then measure your product’s performance and bring these outcomes back into your project cadence.
This process will be a change for many teams, but it enables a outcome-oriented approach that can maximize the odds of success and achieving your business goals.
About The Experts
![Dave Cowing, CEO NovusNorth Dave Cowing, CEO NovusNorth](https://novusnorth.com/wp-content/uploads/2022/03/formal-dave-1.png)
Dave Cowing
Chief Executive Officer and Co-Founder of NovusNorth
NovusNorth is an outcome-oriented experience consultancy that drives business results by creating compelling experiences for customers and employees in the fintech and financial services industry. Dave has 30 years of experience helping companies ranging from Fortune 500 market leaders to disruptive startups with new ideas.
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.
![](https://novusnorth.com/wp-content/uploads/2022/02/article-dave-feb2022-site-support.png)
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.
“Business value comes from delivering customer value. ”
“Business value comes from delivering customer value”
By understanding your customer goals, you can:
- Understand what you need to do to change your customers behavior and achieve your business goals.
- 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.
“The goals you begin your initiative with are really a hypothesis and your initiative is a series of tests”
“The goals you begin your intiative with are really a hypothesis and your initiative is a series of tests”
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.
“The MMP is the smallest unit of functionality that enables you to measure outcomes against customer goals or business goals”
“The MMP is the smallest unit of functionality that enables you to measure outcomes against customer goals or business goals”
By substituting measurable for viable, we get back to Eric Ries’ definition of MVP as “That version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
By taking viability off the table, you’re now asking the question of what you can measure and focusing on creating a cadence that enables you to pull outcomes into your project lifecycle while it’s in flight. The objective here is to release measurable units of functionality frequently enough to get measurable outcomes. For some teams, this will be every two weeks, for others a monthly release cadence enables more feedback on a particular set of features. This is also a function of how efficient your team is at both measuring and acting on measurements. If you’re just starting off, consider beginning with a longer cycle and compressing the timeframe as you gain proficiency with this approach.
5. Act on your measured outcomes
At this point, your project is well underway. You have your business goals, your customer goals, a release cadence based on MMP, and you are measuring outcomes. This last piece is the critical piece. You’re learning how the product works with a set of users. Now you want to take those learnings, that data, and incorporate it into your backlog and sprint planning. You may find that your solution created so far is working just great. In this case, you can move on with the next items in the backlog. You may find that there are certain features that are underperforming or just plain aren’t working for your users. In this case, you’ll want to add a refactoring of the design or the feature to the backlog and include it in your grooming along with all the other stories. In the grooming and story prioritization, you should include a view on importance of stories to your customer and business goals as one of your evaluation criteria. By doing this, you’ve now got a project model that’s both creating new work, but also reacting to feedback from the field to improve features already released.
In Review
Achieving your business goals from digital experience programs consistently is a matter of a deliberate and informed process. It starts by articulating business goals and aligning them to customer goals. Those goals should be socialized with all participants in the program (stakeholders, leader, team members, and partners) to reinforce an understanding and come to alignment. A consistent release cadence centered around an MMP (Minimum Measureable Product) will provide valued and refined software to your audience frequently. You can then measure your product’s performance and bring these outcomes back into your project cadence.
This process will be a change for many teams, but it enables a outcome-oriented approach that can maximize the odds of success and achieving your business goals.
About The Experts
![Dave Cowing, CEO NovusNorth Dave Cowing, CEO NovusNorth](https://novusnorth.com/wp-content/uploads/2022/03/formal-dave-1.png)
Dave Cowing
Chief Executive Officer and Co-Founder of NovusNorth
NovusNorth is an outcome-oriented experience consultancy that drives business results by creating compelling experiences for customers and employees in the fintech and financial services industry. Dave has 30 years of experience helping companies ranging from Fortune 500 market leaders to disruptive startups with new ideas.
Let’s Talk!
Trying to find your new north? Get in touch to find out how we can work together to achieve the business outcomes you need.
Our Latest Insights
Founder and CEO, Rich Cancro, shares how AdvisorEngine applies their guiding principles of Personal, Scientific and Beautiful to create a world-class wealth management platform for Registered Independent Advisors.
By NovusNorth
A high-level over view of our financial services experience and capabilities. We deliver digital experiences. World class experiences that drive business outcomes for the financial services industry.
By NovusNorth
We will be showcasing our team’s experience in designing and building platforms spanning the value chain in structured finance and capital markets from onboarding and account opening to funding, securitization, trading, portfolio management, administration, servicing and trust/custody.
By NovusNorth