What is a Product Owner?

I see so much confusion around the role of Product Owner. A lot of the reason is that Scrum does not really specify anything except how a group of people will work together to achieve a purpose. All the roles are poorly defined. This was to provide maximum flexibility to allow Scrum to be applied to any kind of work. But it has led to a lot of confusion.

We can tease out what a Product Owner is by looking at the responsibilities of a Product Owner and compare them to other more well-defined roles.

Essentially, a Product Owner is responsible for the vision, goals, or direction of the team and the prioritizing of the work to achieve the vision, goals, or direction while maximizing value.

What does this look like in real life? Because of the Product Owner level of responsibility, a Product Owner looks most like a Product Manager.  Which will not help you figure out what a Product Owner does if you do not know what a Product Manager does! So let’s consider some scenarios.

Assume you have an idea for a product. This is something you are passionate about, so much so that you decide to create that product and get it to market. You do not know how to actually create the product, so you find a few people to come and work with you on the product. You all get together in your garage every day to work on the product.

You start by sharing your vision with the team. This is the problem you have seen, this is the product you envision, this is how the product will change the world. The team gets really excited. You have long conversations together about the product, how it might work, what it looks like.

You go off and do market research. What has already been done? What do people like about the other products, and what do they dislike? Meanwhile the team starts researching ideas for how to create this thing. You are in the garage together all day, talking with each other and sharing what you know. You tell the team what you are discovering about the product, the need, and the market. The team shares with you what they are finding out about potential solutions and what it will take technically to create this product.

Together you and the team come up with a list of things to work on. Some of the things are little tests of pieces of technology to see if they will do what is needed at a price that makes sense for your product. Some of the things are features you want to start showing to focus groups. The team gives you estimates of how much effort it will take to complete each work item. You take that information and what you know about the importance of each item and suggest to the team which items to work on first. They argue with you about a couple of them, but in the end, you all agree on the first work items that the team will implement.

Since you are in the garage with the team, they bring things for you to look at every day. This turned out really well, but this idea was a big mistake. What do you think of this design? You and the team talk all the time about what is working and what is not. You make adjustments to the list of work items based on what you are learning.

At some point, you have enough to share with some potential buyers of your product. You get feedback on what they like and what could be improved. You take that information back to the team and have great discussions about what you learned and how it will impact the design, implementation, or priorities of the product.

You are a Product Owner interacting with your team. It is your money funding the product, so you own the product vision, direction, and priorities. But you are always working with the team to shape that vision, direction, and priorities because they are the ones who know how to make your vision real.

Let’s take this a step further. You don’t have enough money to go to market, so you find some people to invest in your product. Now you have some additional responsibilities.

Most investors will not just give you money and walk away. You have frequent meetings with the investors, sharing with them what you are discovering about the market and what the team is learning about how to build the product. The investors talk with you about budget and what they see are important features of the product. While you are still responsible for the vision and the ultimate success of the product, you have to also take your investors concerns into account.

The important thing is YOU ARE STILL IN CHARGE! You are not a spokesperson for the investors, doing whatever they tell you to do, and passing that on to the team. But just as you had to modify your vision as you learned about implementation from the team, you also have to modify you vision to meet the realities of investors wanting a return on their investment. You just wanted a product; the investors also want to make money.

You have discussions with the team about costs. They may find a less expensive way to do something; you may rearrange the order of work to focus more on desirable but low-cost features, leaving expensive features for later after the product is making money.

Now you are probably thinking, this sounds really nice, but I work in a corporate environment. What does a Product Owner look like there?

It should be the same. Basically pick up that whole team I just described and put them in a corporate setting. Instead of investors, you have a VP with a budget they gave you to develop a product or service. If the company truly believes in the Product Owner role, then you should behave exactly as if you are that passionate person who believes so much in a product, that you spend your own money to develop it.

You sit with the team all the time.

You research the market, competitors, options, users, subject matter experts.

You talk with the team about how they would go about creating the solution. You ask the team for several ideas and the relative effort of implementing those ideas. You have conversations with your VP (investor) about the best way to spend the money. The VP leaves the final decision to you, knowing that you will spend the money in such a way as to get the most value.

You have the autonomy and the authority to make the decisions that lead to the highest value product that you can deliver within the budget allowed. You do this after having conversations and considering the needs of the VP, users, other stakeholders, and the team. Your VP/investor and your team trust you to identify the highest value items. You trust the team to implement the solution effectively, efficiently, and with high quality. You trust the VP/investor to give you the best information about corporate direction and priorities.

That is a real Agile Product Owner.

If you have your VP /investor telling you what to do, then you are in a command and control environment. You are essentially working as a Senior Business Analyst, passing commands from your stakeholder to the team. If an Enterprise Architecture team is telling the team how to create the solution (instead of having conversations with the team about possibilities), you are not in an Agile environment. If a committee of subject matter experts is evaluating solutions without involving you, then telling you what solution they picked for your team to implement, they are not treating you as a Product Owner. You are in a command and control environment.

Agile is about conversations. It is about empowering people to be part of the solution.  It is about trust.

Launch of Geri’s Latest Book

Did you get your free Bonus Materials for my new book “Why Agile is Failing at Large Companies (and what you can do so it won’t fail at yours)”?

Visit the book website at http://agileisfailing.com and click the BONUS Materials link on the upper right of the page.

You can also add your email to my notification list. You will get notices when I post new bonus material, hold webinars, speak in public, or publish another book.

Thanks to everyone who is supporting the launch of my book. I am most grateful.

Scrum Roles – One Liners

Scrum Master – enable the scrum team to work as efficiently and effectively as possible

Product Owner – ensure there is a steady stream of well-defined valuable work available for the scrum team to work on

Team Member – work together to deliver high-quality production ready results at a steady, sustainable pace

Business Transformation Digest: December 11, 2015

As I create these digests, I keep seeing business transformation basically being described as a move to the cloud and mobile. I like that this article from Gulf News Technology reminds us that moving to cloud is just replacing one technology with another. True business transformation has to include people and business process changes to reap the full benefits.  A lightweight article but a good reminder:

Driving Business Transformation Through Cloud Services

Don Tennant at IT Business Edge discusses the need for reducing legacy investment and starting to spend money “stepping up” to modern technologies with João Baptista, president of Eastern, Central, and Southern Europe operations at CGI, Montreal, Canada.

Saving IT Budgets from the Legacy Quagmire

CGI’s research and whitepaper “Keeping Up versus Stepping Up” can be found here:  Keeping Up versus Stepping Up

BuiltIn Austin offers ten bold predictions for what digital transformation will mean over the next five years.

Leading Digital Business Transformation in 2016

An article in this week’s Harvard Business Review about how to help people open up when talking to you really caught my eye. If part of your business transformation is to encourage honest, transparent communication, an important part of that is how to influence people to want to do that. Non-verbal cues can help the people you are talking with open up or shut down.

Nonverbal Cues

My offering this week addresses the tendency to jump in and just do it. While a lot of up-front planning may be counter-productive (no plan survives contact with reality), some up-front planning can save you a lot of grief. I address specifically Agile transformations, but the same mindset applies to any business transformation.

http://www.tomandgeriscrum.com/2015/12/07/why-starting-an-agile-transformation-by-hiring-coaches-is-bad-idea/

Why Starting an Agile Transformation by Hiring Coaches is Bad Idea

I see so many Agile transformations go like this.

“We want to be Agile. Put out an ad for Scrum coaches (or XP coaches)!”

The next thing is that a bunch of coaches are brought in from many different places, each with their own ideas, and they start working with teams. The result is generally chaos, confusion, fear, uncertainty, and doubt.

As time goes on, issues get worked out, teams show they are doing Scrum (or XP), and the coaches move on to the next engagement. Then the teams start backsliding, returning to how they worked before the Agile coaches arrived.

Why?

To bring about lasting change in an organization requires far more than coaching individuals and teams. While needing to know a new skill is important, it is only one factor in bringing about change, and it is the weakest way to influence change.  This is not where a business transformation should start.

To enact real change requires you to start with a clear, measurable, compelling goal. Without this, there is no purpose to coaching since we do not know what we are coaching toward. Note that “We are implementing Agile” is not clear, measurable, or compelling.

Consider WHY you want to make a change. What do you expect becoming Agile will do for your company? How will employees’ lives be better after the change? Why will this be better for your customers?  Good marketers know that the most powerful question to answer is WIIFM (What’s In It For Me). Everyone impacted by your change needs to know what is in it for them personally. This is how you make your goal compelling.

Now that you have your goal, what are the things today that are preventing you from being where you want to be?  To answer this question, it can be helpful to consider an influencer framework.

There are many influencers of behavior at any company. The team at VitalSmarts described 6 categories of influencers in their book “Influencer” by Grenny, Patterson, Maxfield, McMillan, and Switzler. Start with the 6 categories and find what things in each category are preventing you from achieving your goal.

These categories are:

  • Personal motivation – what is motivating individuals to not make change.
  • Personal ability – what skills are they lacking that they need in order to make change
  • Social motivation – what is their community saying that opposes the change
  • Social ability – what assistance is lacking in the community that someone needs in order to change
  • Structural motivation – how are we rewarding people for staying with the old way of doing things (metrics, money, praise, promotions)
  • Structural ability – how are the physical space, business structures, and business processes preventing people from making change

I think there is another category to consider as well, and that is what behaviors are the managers and executives modeling? People watch successful people and copy them. If the managers and executives are acting opposite to the new way of being, it will be hard to get anyone to change. People will do what you do much more than they will do what you say. Actions do speak louder than words.

Social influence is by far the strongest influencer and should be addressed long before coaching of individuals and teams is considered. Who are the people that others look up to? How can you convince them to champion the change to Agile? Besides talking, what programs can you set up, set as peer mentoring, an Agile community, or a Scrum Master guild that will show people that their social community supports the change?

Structural influence is also much stronger than individual skill or motivation. Many in the Agile community are aware of the importance of physical space to Agile adoption. But if the business processes, metrics, and rewards are for behavior counter to Agile, then coaching individuals and teams in Scrum and XP practices is a waste of time and money. Change of the cultural and physical environment must come before considering bringing in coaches for the teams.

Executives have tremendous power to influence change and so helping executives model the desired behavioral changes will have a strong impact on an individual’s willingness to change.

Now executives are not going to be doing XP practices, and probably not most of the Scrum practices. But what they can do is model fundamental behaviors that Agile depends on such as honest and transparent communication, using failure to learn (instead of punish), working collaboratively with their peers, and recognizing that they do not have to be right all the time, they need to know how to quickly correct their course when wrong.

Modeling these behaviors sends a powerful message to the organization that everyone should behave the same.  While training is good, reinforcement with executive coaching on these leadership skills will help executives maintain the new behaviors.

With all that in place, most individuals and teams will quickly pick up the basics of Scrum, XP, or other Agile practices. You can send them to outside classes or offer training inside your company.  There will likely be a need for some team coaching for a month or so to support the team as they begin applying the new practices.

As more teams take the training and adopt the practices, the need for Scrum or XP coaches goes away. What you need after that are not generic Scrum or XP coaches but rather experts in the specific areas where teams are struggling.

Are teams having trouble forming? You need an expert on team formation to come in for a short engagement to find out what they are missing and point them on the right path. Teams do not understand pairing? Find someone with extensive experience using pairing in their work and bring them in for a short engagement to find out the problem and help the teams overcome it. Having trouble with retrospectives (this is common over time)? Bring in someone who has many years experience perfecting the art of the retrospective to help the teams learn new and better ways to conduct them.

You do not need long term “Agile” coaches. You need to use the 6+1 areas of influence to create a culture where behaving in an Agile manner is the most natural thing to do. You need people to be good at coaching each other.  Then, as teams grow in knowledge and experience with Agile, you may need targeted coaching by experts to help teams with specific issues.

If you are finding a need for a lot of Scrum or XP coaches over many years, look at the 6+1 areas of influence and find out what you are putting in the way that is preventing your teams from maintaining the Agile practices they learned.

Business Transformation Digest: December 5, 2015

Telling your story in your marketplace is really important for finding and engaging with your customers. The ideas in this article apply just as much to telling a story internally about your business transformation. A compelling story will get people excited and motivated about the changes you bring to your company.  Read this article and think about how you could use the ideas to market inside your own company to promote your initiatives:

Storytelling in Business: Lessons for Brands of All Sizes

This article from Knowledge Path reminds us that we have to look inside our own company to find opportunities for improvement. Instead of just maintaining the status quo, we should have processes in place for continuous improvement.

Business Transformation: Questioning the Status Quo for Positive Change

Another little gem from IT Pro Portal summarizes a recent survey of IT frontline workers around the world conducted by BPI Network. It points out the problems with business transformations and offers some tips for a successful process. The article includes a link to the original paper.

What’s Holding up the Transformation?

An article at Enterprise Irregulars summarizes a variety of research done by other companies that paints a pretty dismal picture of what business leaders think of the CIO and IT.  It clearly shows that CIOs (in general) have done a poor job building trusting relationships with their business counterparts and a poor job delivering business value. Food for thought:

What do Business People Think of their CIO?

My own offering this week concerns what makes a great leader of an empowered organization.

http://www.tomandgeriscrum.com/2015/11/30/if-it-is-not-command-and-control-what-does-the-executive-do/

Finally, some papers you can review in your “spare time”.  Cisco and IMD released the “Digital Vortex” report earlier this year, investigating “How Digital Disruption Is Redefining Industries”. If you have not looked through it yet, pick up a copy here:

Digital Vortex

After reading that, you might peruse the other 3 related documents they released in November:

Disruptor and Disrupted Strategy in the Digital Vortex

Competing in the Digital Vortex: Value Vampires and Value Vacancies

New Paths to Customer Value: Disruptive Business Models in the Digital Vortex

Business Transformation Digest: December 1, 2015

There have been so many good business transformation articles lately! And I missed sending out a digest on November 20. So this week I’m giving you a bonus digest to enjoy.

In this interview on ZDNet, David Bray and Corina DuBois share what they have learned about being successful change agents. I particularly liked this tip:

“Build consensus by listening to the narrative, build trust and reduce fear with consistent communication, and articulate a vision of the future that others will support and around which they will rally.”

Tips for Change Agents

Information Age has a thought-provoking article about challenges faced by Financial Services and Insurance Providers (FSP) when trying to support a more digital economy.  In particular, the author points out the difficulties of an Agile contracting model in a regulated environment and suggests the possibility of ‘contractualised Agile’ as an in-between model (a middle ground between working out the requirements as you go and determining all the requirements up front).

How FSPs can become true digital creatures

Forbes offers a look inside the IT transformation at BDP International which was done to support a larger digital transformation of the company.  The 6 tips include:  Run IT like a software shop, become an early adopter of new technologies, work with colleagues and customers as a true business leader, be fast and flexible, bring in new skills and talent to create a continuous learning environment, and engage with the broader community.

6 IT Transformation moves for a successful digital transformation

The blog Radius1 reminds executives that we cannot transform our organizations with our old thought patterns, which for executives generally means to be sure you are always right. To transform our organizations, we have to transform how we ourselves think and approach problem solving. We have to change from always being right, to being open-minded to finding out what is actually going on and eliciting input from others throughout the organization.

Meta Transformation – Change Your Thinking!

Finally this article from CIO.com minds us to avoid bimodal thinking when it comes to IT. Bimodal IT is where you split IT – one part does traditional IT and the other part does innovation. While this may fix some short term problems, there are many perils down this path.

Think multi-threaded not bimodal

If it is not Command and Control, What Does the Executive Do?

I had the good fortune recently to spend some time with a VP I know who is currently working for a very large company. This is someone I think is very effective – his organization runs well, his people are empowered and love working for him, and he is not spending all his time fighting fires. He has built 2 such organizations at his current company and was just assigned a new one. His previous organizations continue to run well without him (which is one of his personal tests for whether or not he has done a good job).

I really like, admire, and respect this VP (he is my role model for an executive) so I asked, “What do you do? How do you make all this work?” He was happy to share his thoughts with me. What follows combines things he told me and things I have observed over the years I have known him.

When I start with a new organization, I do not hit the ground running, ripping everything apart and rebuilding it. Rather, I wait at least 90 days until I am sure I understand what is going on before making any change. Often, I think I know early on what the needs are, but as I spend more time with people, I find my knowledge grows deeper. I often change my mind as to the best approach before the 90 days have passed.
I also spend time learning what my leader really wants. How can I personally support his or her goals? What does my organization need to do to support those goals?
The best use of my time is to keep an eye on 3 years out. I should not be involved in the day-to-day business. My directors should be working on the 1-3 year period. The front line managers should be looking at the next 1-13 months. The project managers and their teams worry about the day-to-day.  I have to trust my teams to do the job. I do not sweat the details.
I set the vision, strategy, and rules of engagement, then let my teams run. The know they can come to me any time with problems they cannot solve themselves. But they also know I expect them to solve the problems they can solve. I need to leverage relationships, influence, and my position to remove barriers for my teams so they can do what they need to do.
My job is to shake hands and kiss babies, to build those relationships with other executives. I also have to tell compelling stories. Statistics and reports are not compelling stories, people are. What are the people stories that will inspire and motivate my organization? Stories about us yes, but more importantly stories about our customers, the people we serve. If we do our jobs well, what will their lives look like in 3 years or even further out? What is that future we are looking toward?
I walk the floor at least an hour a week to give people the opportunity to reach out to me in a less formal manner. This is not to look over their shoulder, but rather to provide an opportunity for them to share with me whatever they want me to hear. I cannot rely on statistics; I need to spend time with the people behind the numbers. It is important that I really listen and provide a psychologically safe environment so they can share. It is about building trust with the people who work for me.
I look out for my people and they know it. I have put myself at risk to move the executives working for me to other organizations to build their careers. When they transition to a new area, I continue to meet with them one-on-one until they are really transitioned. I work with their new manager to share with him or her how I think these people need to develop.
If I do things right, if my teams are truly empowered, I work my way out of a job. The organization should be able to perform at a high level without me.

So what does this look like from below?  What is work like for people supporting such an executive?

Throughout the organization, everyone always know the goal and purpose of the organization. Communication through all levels of the organization is frequent and clear.  People are comfortable asking for clarification when they do not understand.
Doing something wrong is not bad. Continuing to do it wrong is bad. Failure is an opportunity for growth, and those who do not take that opportunity will be moved somewhere else.
Decisions are made close to the action. The person with the most knowledge is the person making the decision. People are not waiting for permission but doing what needs to be done to support the goal and purpose.
People working in this organization know they are expected to grow and learn.  There is no place to hide and get comfortable until you retire. Some people do not like that and move elsewhere.
People at all levels of this organization are comfortable proposing ways to work better or more efficiently. The person with the idea is generally the one tasked to try it out and report on the results.
Managers at all levels are expected to actively help their people develop professionally. This is part of how managers are rewarded.
Executives working for this VP know that he will pull them out of a fire, get them special opportunities, and always be available to lend an ear. He really works hard to help the people working for him progress in their careers.

By describing a clear purpose, encouraging and rewarding mastery, and granting a large degree of autonomy, in return this VP gets an empowered organization of enthusiastic and dedicated employees, and a tribe of executives who support him.

If you liked this article, you might also like this recent article in the Harvard Business Review:  What Amazing Bosses Do

Before Making the Plan, Describe Where You Are Going

All too often I am asked to help with a business change or transformation after it has started and is not going well. In almost all cases, a major reason it is not going well is no one described where they wanted to go, or if they did the destination was poorly defined.

These are not well-defined destinations:

  • “We want to be a more effective organization.”
  • “We want to be Agile.”
  • “We want to be collaborative with our customers.”
  • “We want to provide world-class support.”
  • “We want to be a Lean Startup kind of company.”
  • “We think we should be communicating better.”
  • “We are going to roll-out Scrum to the whole organization.”

In fact all of these statements are solutions for some perceived problem that is not described. Since we do not know what the problem is, we do not know if any of these is the right solution, nor will we know if the problem is solved.

I always ask WHY. Why do we want to do these things? What problem are we trying to solve? What challenge are we facing? What result will we get if we apply that solution?

Here are some examples of concrete problem descriptions that will allow us to determine a well-defined destination.

  • Our cycle time from proposed change to release is 6 months but the average in our industry is 3 months. We are losing business and our research suggests it is because we are often too late to market.
  • Our product sales are steadily decreasing compared to competitors. Feedback from our customers is that they find our product to be harder to use than similar products.
  • Our markets change quickly. We need decisions at least quarterly (monthly would be better) about product direction, but our leadership team takes 6-12 months to make a decision.
  • We are getting a lot of feedback on social media that our support team members are often not solving the customer’s problems.

Can you see that with a good description of the problem or challenge that describing a destination becomes much easier?

Once we have a clear description of the problem, we want to describe relatively short term goals. What can you do this quarter or by the end of the year? This will allow us to get feedback on whether or not the solution is working, and allows us to change the approach if it is not (or we discover the solution is not sustainable over the long term).

  • In 12 months we will reduce our cycle time from proposed change to release to a maximum of 5 months. Though it is infeasible to reduce the cycle time for everyone to less than that in a 12 month period, we will find one product where reducing the cycle time is likely to improve sales, and we will reduce the cycle time for that product to 3 months.
  • In 3 months we will release a new version of our product that fixes the top 3 usability problems.
  • We will select a product that is particularly market sensitive and work with the leadership team to get decisions quarterly throughout the coming fiscal year.
  • Every month in the coming fiscal year we will provide a solution to the current number 1 problem customer support has been unable to solve. By the end of the year we will have solutions to the top 12 problems. Either they are no longer problems or we have trained our support team members in how to solve them.

With a clear description of the problem or challenge, and a clear description of the destination, we have a way to measure if we got the results we were looking for. We still have to work out how to get from problem to destination, but once we know where we are going we can find a way to get there.

In order to get to a solution, we often have to do deeper analysis of the problem. This is because the problem that we see comes from some place in a overall process that may be quite large.  What part (or parts) of that larger process is causing the problem?

Let’s take the example of the cycle time from proposed change to release. Many people will assume it must be the implementation team that is not efficient. We can hire some coaches and teach them more efficient practices and that will solve the problem. But will it really?

We need to take a deeper look at the whole process. The implementation team is just one part of it. Is the problem convincing someone to fund the change? Is it how long it takes the delivery team to implement a solution? Is the problem how long it takes to release the solution once it has been implemented? Is there a quality issue?

This deeper analysis of the problem is very important or we risk applying the wrong solution. We waste time and money and still the problem is not solved.

At one company where I consulted in the past, my client had just this problem – the cycle time from proposed change to release was far longer than their industry average. They brought me in to help the delivery teams work more efficiently in order to reduce the cycle time.

I did some investigating and found that the delivery teams were already working very efficiently. The problem was in two other places. The first problem was that once a change was proposed, it took many months to get it approved and funded. That part of the process took as long as implementing the solution!  The second problem was that to release the change took many months. That part of the cycle was also as long as implementing the solution. The whole focus of the process improvement work had to change, and the nature of the solution had to change.

(If you are wondering what happened … changing the release process was a long, difficult effort because there were a lot of things causing the release process to be long, each of which had to change. It was done over a period of years and the overall cycle time was reduced a lot. Changing the funding process was not even addressed until the Board of Directors fired the CEO and there was a big shake up at the top of the company.  It was actually a pretty easy process to fix once there were people who wanted to fix it, and was done in a couple of months. And fixing that process had a much larger positive impact on the efficiency of the whole company.)

In conclusion: To be able to measure the effectiveness of a solution, we have to first clearly describe the problem we are trying to solve, then describe what things will be like when the problem is solved (the destination). We then do some deeper analysis to determine the actual source of the problem, and propose a solution to try. We apply the solution in a small way and measure to see if it is moving us toward our destination in a manner that is sustainable and able to be applied on a larger scale. If the answer is yes, we expand the solution to a larger part of the organization, and again measure the results. If the answer is no, we can try a different solution to see if it works better. We can also review our analysis to be sure we are solving the right problem.

Business Transformation Digest: November 29, 2015

An article this week in the Harvard Business Review discussed what is a great company culture. If you want to transform your company, you have to know where you are going, and being able to define the culture you want is a great place to start.  The author suggests that a company with a great culture maximizes good motives for working and minimizes bad motives for working. Good motives are play, purpose, and potential. Bad motives are emotional pressure, economic pressure, and inertia.

How company culture shapes employee motivation

From The Economist I learned about the changing corporate culture in South Korea. The leaders of the big corporations are finding that their younger employees are not interested in the traditional Korean corporate culture, so to retain that talent, companies are relaxing their demands on employees’ time. It will not happen overnight, but change is necessary.

Loosening Their Ties

This intriguing article from the blog Innovation Enterprise suggests how the CFO can be deeply involved in a business transformation effort.  Thought provoking ideas here.

CFO Role in business change and transformation

Is “Facebook at Work” the way to go for better workplace collaboration? The BBC explores this topic.

Online chatting at work gets thumbs up from bosses

Finally, my latest article reminds us that if we are going to do a business transformation we should have a goal in mind.  If you do not know where you are going, how will you know when you get there?

http://www.tomandgeriscrum.com/2015/11/30/before-making-the-plan-describe-where-you-are-going/