BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Visual Portfolio Management: Collaboratively Aligning Your Company

Visual Portfolio Management: Collaboratively Aligning Your Company

Lire ce contenu en français

Bookmarks

Mass adoption of agile – its practices, its techniques, and to some degrees its values – has brought huge tactical advantages to many companies. Speed, flexibility, and fast feedback can benefit any company.

To exploit these advantages, companies need to work on the right things. The power of agile thinking does not provide value without purpose and vision. A company still must use the power in the right way. And agile provides no direction for this.

Imagine a company’s capabilities to be a vector that defines its operative power. Agile helps the length (strength) of the vector only. What the company produces or offers, what it must create itself, is the direction of the vector.

Companies need to excel in at least two types of work: finding the right problems to solve and solving those problems efficiently. Doing the right things right is what we call effectiveness, while doing (any) things right is merely efficiency. Agile at its core addresses the latter. When a company improves its problem-solving capabilities (efficiency), its problem-finding (effectiveness) capabilities may be pushed to the background. In agile transformations especially, it is important to keep the balance between these two types of work. Companies often struggle with that balance.

Making the differences in types of work and their purposes explicit may help a company to understand some of agile’s consequences as well as mitigate the risk of imbalance. The three-horizons model looks at the purpose, nature of work, and methods, and can be used to bring about such an understanding. Visual portfolio management can integrate the different types of work into a coherent system.

The three-horizons model: a useful categorization of thinking modes

The McKinsey firm long ago popularized the three-horizons model, which Geoffrey Moore used in his book Escape Velocity. The model explains how companies need to work to ensure sustainable growth and avoid effects like those Clayton Christensen described in The Innovator’s Dilemma.

Christensen explores how companies that begin as innovators typically stagnate. These companies start with either a product or process innovation, quickly capturing market share from others. But they stop innovating, instead relying on and exploiting the same products, services, or business models. This leads to stagnation in growth, revenue, and margins, while other innovators come along and out-innovate the original innovator, now a slow behemoth, and capture its market share.

If the stagnant company cannot change course, it will disappear. Even once it recognizes the danger, it may be too late for a big, slow company to learn and change.

To be able to escape that deadlock, companies need to work on many levels and thus with many different types of work to generate sustainable business.

Table 1 - The three-horizons model as adapted by Geoffrey Moore.

The three-horizons model describes the different levels a company needs to work on and their purposes:

Horizon 1: Take care of the current business, generating money out of the product today.

Horizon 2: Take care of where money will come from in one to three years, generating future growth.

Horizon 3: Work on visions and options to grow beyond that time, capturing options for future growth.

Horizon 1: Generate today’s cash flow

Horizon 1 is concerned about earning money today. The task is to continuously improve an existing, profitable product today and in the near future, especially its market fit and quality in an evolutionary process of continuous improvement. This means that the mind set in Horizon 1 needs to be that of production: things need to work, quality needs to be high, the system needs to be stable, and errors are called exceptions because they should not happen.

Horizon 1 is about building as well as we can what we know we have to build. In Horizon 1, the work is largely about the known. We maintain the product so that current users stay happy and committed to our product. We know the current pain points and how to handle them. The best sources for this kind of knowledge are the people in close contact with our customers, like our sales people or customer support. We can file and map the near-future requirements of our product, and prioritize, develop, publish, and evaluate them forever. This is what agile perfectly addresses. Agile helps us to build what we know we need to build and to prompt faster and better feedback on it.

The tools of Horizon 1 are the tools of agile, such as Scrum and Kanban. These tools improve the speed and flexibility of delivery while maintaining quality as well as increasing feedback. Six sigma is another method that focuses on the quality and reliability of delivery in production. One needs to be aware, though, that the object of introspection, improvement, and innovation in these methods is the process, not the product.

This is the tactical advantage that agile delivers, and the force that we can exploit to deliver better products faster. We have to keep in mind, though, that the boundary condition for Horizon 1 is that we already know what we need to do.

Horizon 2: Generate future (high-growth) business

The purpose of Horizon 2 is to enable future growth. It does not help to keep riding our existing offering. We need to solve new problems for new people. We will have to convince people of the value of our new solutions and turn them into future customers.

First, we need to find the right problems. Horizon 2 is mostly concerned with our known unknowns and unknown unknowns.

Table 2 - Design as a problem solver.

To find new problems for new customers and generate future revenue, we need to fill a gap between what is and what will be. We have to come up with offerings we do not know of yet that will provide value to customers. We can define a problem as a perceived gap between the current status (here, our present product) and an ideal future status. The focus is on discovery. Finding and solving the problems and needs of relevant customers is basically a design task.

While the work is to discover customer needs, neither can customers formulate their needs nor is it their task. The job is to extrapolate from what we know and use that as a guide to new product visions. This means we operate with little knowledge and high uncertainty. Here, every bit of information is highly valuable, and we can cheaply gain information by running cheap tests. In his landmark book The Design of Business, Roger L. Martin calls this the knowledge work that takes place in the early stages of the “knowledge funnel”. It is when we discover new problems and validate them as relevant.

Table 3 – Roger L. Martin’s knowledge funnel.

Exploration means that we do not yet even know where to dig for the treasure. We are working in the domain of unknown unknowns. We start with as little as a hunch and gradually earn our way forward to solution models for the problem. We do this carefully because we are working on new things in new contexts of which we have little knowledge. The prime task is to gain knowledge as quickly as possible (but not too quickly – validity is king) and as cheaply as possible. Every little bit of information is highly valuable in a state of high uncertainty.

In the world of startups and new products, the fastest learner wins so the task is not to build a perfect product as quickly as possible but to find a valid solution to the problem we discover. Nor is the task to produce sustainable quality right away. Scaling and mass production (and writing production code!) can only follow relentless manual, heuristic iterations of market and customer research, design work, and the required prototypes.

The tools of Horizon 2 are research and design, which lead us to an understanding of new domains and territory. The core of Horizon 2 is market and user research. With user research especially, we gain qualitative knowledge about our users and partners. Analyzing these qualitative insights helps us to understand where customers are happy or unhappy and where we can better support them. User research answers three questions: what do customers need, what do customers want, and does the product work? We need to learn what our customers want and need in Horizon 2. From these insights, we perform heuristic searches for solution prototypes in the form of business-model canvases, product prototypes, and so on.

A3 thinking and (lean) business-model canvas

A3 thinking and the business-model canvas are visual tools that support the understanding of problems and definition of problem statements in teams. A3 is one of the key ingredients of Toyota’s culture of continuous improvement. As continuous improvement means continuous problem solving, a common language and method for understanding, discussing, and defining problems had to be found. Here is a good introduction to A3 thinking in more depth.

Alexander Osterwalder’s Business Model Canvas and Ash Maurya’s Lean Canvas do the same with a focus on business models. They are basically stripped down versions of the Toyota A3. In a business-model canvas, you describe the value to be provided to the customer (the problem to be solved), what needs to be done to get there, who is needed to do it, which specific customer segment is addressed, which partners are needed, how much money we need to spend, and how much profit we expect to make. On top of that, the canvas describes the mechanics of how the business model works and how the actors interact. You can read more on this here.

The Value Proposition Canvas is a newer tool by Alexander Osterwalder that focuses more on the middle of the original canvas. It details what value will be provided and how it fits a problem the customer has. More can be read here or watched in this short video.

The nature of work in Horizon 2 is therefore heavily defined by design work in which opening and closing phases closely following one another. The work is highly non-linear, in that work does not always move forward but also often retraces its steps backwards, especially when we’ve followed the wrong path.

The discipline of design thinking explicitly supports this kind of work, being a mash-up of research and ideation techniques. Design thinking is a process that starts with understanding a context, reaching a standpoint, and finally creating a solution in the form of a prototype. If we don’t get far enough in a certain phase, we assume that we did not learn enough in a previous phase, and we need to backtrack.

Design Thinking

“Where you innovate, how you innovate, and what you innovate are design problems." – Tim Brown, CEO of IDEO

“When people talk about innovation in this decade, they really mean design.” – Bruce Nussbaum (2005)

Design thinking is a method that deals with extracting the essence of what design is – the journey from identification of relevant problems to their solutions – and applying it to any problem. The method is a collection of tools and practices sorted around a loosely coupled, non-linear process.

At design thinking’s core is also the insight that finding and solving problems is best done in a collaborative, interdisciplinary team. Interdisciplinary teams support a larger variety of viewpoints and thus a broader base of insight and solutions. To support collaboration, design thinking is heavily based on a culture of making, which makes haptic prototypes one of its core ingredients and deliverables of the solution-oriented phases.

The process itself (there are many different flavors, of course) leads through the following phases:

Empathize (or understand): The goal of this phase is to understand the users’ needs and problems through user research in many forms, the most prominent being observation and interviews.

Define: From the observations, frame a problem to clarify what needs to be solved. This is important because problems framed too small result in only shallow solutions and those framed too widely may possibly result in no solution at all. As collaboration is at the heart of design thinking, it is important to work out a problem statement that is easy to understand across the team and that inspires and motivates the workers.

Ideate: Work on ideas that solve the problem. There are several methods for ideation like brainstorming or a design studio. All of them start with producing as many ideas as possible and then filtering them until the most valid ideas remain to be worked on in the next phase.

Prototype: Build prototypes for the best ideas. Build the prototypes in iterations. Prototyping should start quick and dirty first and grow more high-fidelity during the iterations. Prototypes are the central means of discussion and decision in design thinking, as they enable us to discuss and decide on concrete things rather than abstract ideas or PowerPoint presentations.

Test: Each iteration of a prototype is tested with users/customers. Gather feedback and compare the impact to the expected outcome. The feedback suggests improvements of the prototype and helps you to decide whether or not to follow the direction of that prototype further and possibly to go back to an earlier phase of the process to get more insight and deliver deeper, better solutions.

These phases are not strictly followed in the described sequence but may be used as required. Often, it is necessary to backtrack to an earlier phase to deepen understanding. The most prominent actors in design thinking are the d.school (Institute of Design) at Stanford University, HPI (the Hasso-Plattner-Institut) at the University of Potsdam in Germany, and the IDEO design agency.

During the different phases, we use techniques like user interviews and user observation to understand the user. These methods help us to get out of the rut and to analyze a problem from an outside (or customer) perspective rather than our own. With the information and inspiration gained from understanding the users’ problems, lives, and behavior, we proceed to a standpoint from which we will view the problem and think of solutions in the customer context. In design thinking, this is called ideation.

Overall, the process of iterating from a problem hunch to solution candidates leads us through sequences of diverging and converging phases. Lean-startup techniques, following the scientific method, help us to go through the sequences faster and thus to learn quicker.

Hirotaka Takeuchi and Ikujiro Nonaka call this “The New New Product Development Game” in their legendary paper of that title (and from which the name “Scrum” was later taken). They called it a game because they thought that the rules are less those of a process and more those of a team game. It is interesting how much the authors knew about this in 1986 – whereas many companies today have no idea how to work in Horizon 2.

Horizon 2 is about finding new problems with a designer’s mindset and designer tools like design thinking. We try to enhance focus without killing creativity by applying lean-startup methods to design thinking.

Horizon 3: Generate options for future growth

Horizon 3 is mainly concerned with the development of future trends in our market and technology, and attempts to roughly anticipate what we will have to do to catch one of those waves. The aim of Horizon 3 is to enable future growth.

Humans are bad at predicting the future, which means we mainly work with hunches and intuition in Horizon 3. All we do here is invest in options for future growth. That means we do not heavily invest in concrete products but we hire the right people so that we don’t miss opportunities.

Here is an example. If we believe that IT will trend towards micro-services, we know that we will later require specialists in API development – and now is the time to prepare and look for them. It does not mean that we need to rebuild our application backbone right now – but if we must, we will be able to.

Horizon 3 work means trying to glimpse the future and trying to prepare for it so that we will not miss opportunities for growth. It is highly speculative work with even more uncertainty and less concrete knowledge than in Horizon 2.

The tools of Horizon 3 are more lightweight than those of Horizon 2. We use a subset of the lightest tools. Toyota’s A3, (lean) business-model canvases, value-proposition canvases, and value-stream mapping are tools to help us to visualize and communicate our understanding of problems we discover, how the world would look if we solve them, and what’s in it for us.

Conflicts among horizons

The purpose and tasks of the three horizons fundamentally differ. In most cases, this leads to conflict, with the biggest clash between Horizon 1 and Horizon 2. Where Horizon 1 is about the present – what we know and how to reliably build that with high levels of quality, repletion, and certainty – Horizon 2 is the opposite, when we work in high uncertainty and cannot yet afford high quality and repetition, as the goal is to learn. The virtues required of us completely change as we move into Horizon 2.

Where Horizon 1 specializes in quality and robustness, Horizon 2 is still looking for a solution and thus focuses on learning the context.

The context in which we work – certainty in Horizon 1 and high levels of doubt and uncertainty in Horizon 2 – directly implies a conflict of interest. In addition, the nature of knowing in Horizon 1 versus finding in Horizon 2 leads to cultural clashes in companies. The following example might illustrate that conflict.

Imagine a company that is about to develop new business ideas. Developers often want to take part in the early stages of idea development to at least prepare themselves for when new development work lands on their tables (a consequence of the experience of things being thrown over the fence in last minute). A strategy workshop might take place, to which developers are invited after feeling excluded for years. And often, the developers are the first ones to find the discussions on strategy boring, inefficient, and unclear. They’re not wrong. Developers are discovering the nature of the work in Horizon 2, in which it is exploratory, unclear, and vague by nature and thus feels ineffective to those used to the task of delivering working solutions.

This alone might not be a huge problem. It becomes important when a company does not make explicit which type of work is expected at what time. In the example, the developers do not feel uncomfortable because they cannot work like this. They watch the meeting sketch a new solution that they will soon have to deliver. They think in this meeting of how the platform they’ve helped to build, and the integrity and quality of which they must protect, could support the new requirements. Across the table, the strategists are happy playing games and imagining about what could be. It is important to make clear to everyone in which horizon they are working for each situation.

Drawing people who are used to working in Horizon 1 into Horizon 2 and vice versa is a good thing - but only if expectations are clear. If expectations are vague, conflict will arise between the visionary and the pragmatist. Both are needed but need to be protected from each other. The pragmatists will be unhappy under the visionaries’ conditions and vice versa.

The main problem is that companies naturally prefer certainty to uncertainty, clarity to vagueness, and small improvements to radically new things. That normally drives Horizon 2 work to the corners, and small but certain improvements win priority over vague but visionary bets of any size. In the long run, this prevailing mindset based in the production of Horizon 1, and the shunting aside of Horizon 2, leads to neglect of future opportunities as it defines a company’s culture.

A healthy company needs to balance the first two horizons as well as Horizon 3. No horizon is more important or more valuable than the others. All are needed and ideally build upon each other. A company equally needs both production and exploration mindsets. One of the main tasks of management is to support the right balance between horizons, and to let the work flourish within the different mindsets. And this is where visual portfolio management can help.

Visual portfolio management

Visual portfolio management helps to align projects and products across the whole company. We could call this horizontal alignment across the different departments.

We accomplish this by visualizing all work on existing products on a huge board, as shown in table 4. Each product, product idea, or feature is a row on the board and for each phase in its lifecycle, we have a column. Such a board provides a quick overview of what is going on across the company. It tremendously helps in discussing priorities across offerings in the context of our company’s capabilities and capacities. The main trick is to hold frequent, short meetings to pull decisions on the portfolio level from the stakeholders across the company. Short meetings allow many people to attend. Frequent meetings prompt quick decisions on the portfolio level. But more importantly, the high cadence of the meetings leads to higher levels of trust across the board.

Table 4 – A visual portfolio board.

When I introduce visual portfolio management, normally after a certain time (typically after three to six months), the stakeholders ask for more. By then, the operations to get projects done have so much improved that any lack of purpose, ambition, or strategy becomes apparent. Voices asking for a clear strategy get louder.

This is when it’s apparent that the company has been ineffective on the strategic level. While some workers might have ideas on strategy, most work on strategy has proceeded unplanned and more or less incidentally. Strategy has lost out to ideas that help immediately and promise money this quarter rather than next year – the root cause why companies have a hard time thinking about the future or allowing for anything that seems uncertain. In visual portfolio management, we counter this by making the work in the horizons visually explicit (table 5).

Table 5 - Three horizons mapped to a portfolio board.

Here is a small test: list all projects your company is currently working on and try to extrapolate how much better off you will be in one year's time if you successfully develop all these projects. If the answer is “just a little bit” (like I have often experienced in my work), it might be a good idea to drop a third of your projects and make space for some strategy work: explore how to improve what you offer your customers in the next year and beyond, in order to grow.

A board as shown in table 5 already improves our work, as we make explicit that we need to work in Horizon 2 and that we have to constantly deploy people to that work. Furthermore, the board helps us to resist the urge to draw people into Horizon 1 when things get hot. The visualization reminds us always to have people working on strategy.

But such a board is a little lie for two reasons. First, some work in Horizon 2 and Horizon 3 will never make it to development. The results of Horizon 2 and 3 are concepts, business models, and options, not products. Work in Horizon 3 enables models in Horizon 2. Horizon 2 work results in development of business models and products down the road in Horizon 1. But sometimes, as we learn during our strategic work, our product ideas are already ready for development.

Second, discussing Horizon 2 and Horizon 3 in the same meeting as Horizon 1 means their tasks will die a sad death as they can never deliver monetary value right away like the ones in Horizon 1 can. A presentation that delivers an option will always lose to a presentation that promises money next month.

Having separate boards for work on Horizon 1 and one for work on Horizon 2 and 3 can solve both problems. In my experience, it is also best to separate meetings that deal with these two sets of work. This leads to a pair of boards as shown in table 6.

Table 6 - Separation of Horizon 2 and Horizon 3 from Horizon 1’s production board.

Concrete ideas for solutions ready for development move to the Horizon 1 portfolio board (production) so that these products will be delivered as quickly as possible. The smaller strategy board will be monitored more loosely in a separate meeting, possibly with similar stakeholders but in a different context. The evaluation of these strategic ideas is based on potential and speed of learning and insight.

Visual portfolio management helps to align a company along the different dimensions of requirements, the strategic horizons of work, and the different natures of work required. It helps to make explicit the difference between the required types of work and to balance the amount of work being done in these areas to align forces across the company toward a unified goal or vision. The visualization helps to get rid of many cultural and process-related misunderstandings in a company and thus directly and easily addresses the company’s effectiveness.

Following these processes will result in a higher level of coherence across the company and helps to efficiently deliver the right products. This leads to a higher level of effectiveness, which finally leads to “doing the right things right.”

About the Author

Markus Andrezak is the founder of überproduct, a product consultancy in Berlin. He specializes in helping companies find and deliver products their clients really need and to align product strategy with the overall strategy. He is also an expert in innovation and Kanban. In 2012, he was nominated for the Brickell Key Award for his pioneering work in portfolio kanban, his first moves toward visual portfolio management. The practical results of his portfolio work as well as understanding the creation and delivery of products are now of the main pillars of his work in consulting and training. He is @markusandrezak on Twitter and is happy to receive your feedback.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Thoughts about Horizon 3

    by Andrew Campbell,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Markus, This is a very good article pulling together all sorts of different ideas. Thank you. My guess is that there is still work to do on Horizon 3. At the moment the tools and approach are too similar to Horizon 2... hence your suggestion that they share a portfolio box. But, the whole basis of the Horizon concept is that each requires a different mindset, different tools and, as a result, a different portfolio box.

    My own work, published in The Growth Gamble, suggests that Horizon 3 is only relevant within an existing business model. Once you start experimenting in Horizon 3 mode with ideas outside of the business models you know, your ability to judge good ideas from less good ideas is so low that the cost of the failures is higher than the benefits from the few success. This explains why corporate venturing units almost universally fail to create value.

  • Re: Thoughts about Horizon 3

    by Markus Andrezak,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Andrew,

    thanks - I am totally with you. The more I get into Horizon 3 work, the more I see what you say.

    Anyways: Here are two good horizon 3 question that help me quite a bit: "What would we need to do to totally disrupt the services and products we currently offer?" or "What would we need to do under the assumption that all our revenue channels won't deliver any more revenue tomorrow but that the actual work and services we provide still delivers value?"

    The first is more general, the second could be targeted to fond solutions for sectors such as publishing under the threat of the internet etc.

    My impression now is that, yes, judgement is hard and we might soon end up in Horizon 2 again, starting like this. But where I work like this, we deliver results, it seems.

    Thanks for your good comment and hint! I'll look up what you have published!

    Thx a lot again,

    Markus

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT