Impact Mapping - how can a dev team stop doing what they need and start doing what they need?

A report from last year’s conference of systems and business analysis specialists - Analyst Days 2013 from a senior analyst at the St. Petersburg office of DELL - Dmitry Petrashev

On the report page you can find a presentation and a video, and here is the text ...
')



Introduction
Good day everyone. My name is Petrashev Dmitry . I am a senior analyst in the St. Petersburg office of the company Dell. Today I would like to talk about this approach to strategic planning as Impact Mapping :

1. I'll tell you what he is,
2. Let me explain why we are interested in them and decided to implement in our company,
3. I will share the experience of implementation and what came out of it.

Immediately I will make a remark that the company is grocery and in my story there may be a lot of our specifics. But it should be clarified that the approach itself is versatile enough to be applied in customized development and in any specific scenarios.

So, why I think that the development team is not always in our case doing what is needed and where Impact Mapping is.



Interaction of business and R & D
In our company, “what exactly is needed” is determined by a specially trained person who is responsible for the product strategy - the product manager .

• He determines what strategic business goals are in front of the product, compares them with where the entire company is heading, communicates with key and representative customers, and so on.
• Knowing the business goals, the product manager creates a list of necessary changes for the next release and, through analytics, transmits them to the team.

The development team lives in the twelve time zones from it, which implements the necessary features and basically neither by sleep nor by spirit why changes are required such. Backlog for them is just a shopping list, for which they sent to the store. What exactly will they cook, as a rule, do not know.
So, what well-known problems are growing because of this gap in communications.



Problems
1. Since the decision on what changes are needed in a product to achieve a business goal, is made solely by the product manager, these decisions are not always effective and justified.
2. A team that does not understand where the product is seeking is not motivated to make it better. They just close the features, no more.
3. It is extremely difficult to explain to the team exactly how the feature should be implemented and why exactly in this order, without knowing the initial goal.
4. We develop the occupational disease of any product manager. They just love closer to the release date to expand the requirements of various free in their opinion trifles. All these “minor edits” are hard-cut from the backlog simply because we don’t know if they are really important.

We have previously tried to solve these problems in various ways.
1. We had a document with marketing requirements - MRD. Gradually died out. Perhaps, as a tribute to the transition to agile, where it is customary to talk more than write.
2. There were “themes” = themes that were supposed to describe the release and set the general trend of all changes in one paragraph. Also did not go.
Impact mapping became for us another attempt to clarify where the product moves and how we, as a development team, contribute to this.



Impact mapping
Impact mapping is an approach to strategic planning that allows you to build a logical chain of business objectives in the head of the product manager to the product changes necessary to achieve the goals.

The name of the approach (impact - impact) is determined by the fact that we are trying to understand: who and what effect on our goal can have, and only then decide what needs to be changed in the product for this.

At the exit, we get a mind map, which in the process of discussion is drawn together by the business and representatives of the dev teams. No multipage documents, only one well-structured scheme.

Preparing a map requires answering four simple questions.



Step 1. Why - why
First you need to answer the question why - why
1. Why do we release this version of the product,
2. Why we believe that something needs to be changed in the product
In this step, we define the goal. The goal naturally has to be smart (SMART):
1. Specific,
2. Measured,
3. Action oriented,
4. Achievable in a reasonable amount of time.

The answer to the question “Why” is (should be) with our product manager, but his goal hardly meets the criteria. Over this goal will have more work.

A good goal is a problem that needs to be solved, not a ready-made solution.



Step 2. Who - Who
Next answer the question Who? - who? The main task is to determine the circle of interested (or not) persons.
1. Who can help us with the goal?
2. Who can interfere?

At this step, it is important to consider all the people involved, not just the users. All who can influence the result should get on our map. Products do not work in a vacuum, and product use affects not only end users.

In our case, it turned out to be other teams with which we integrate, and marketing, and even the top managers of the company.



Step 3. How - How?
1. We answer the question for each person involved - how should we change (influence) the behavior of this actor so that he will help us achieve the goal?
2. Determine the impact on users and other actors.

This is perhaps the only “question” of the entire impact mapping approach, which needs clarification with an example.

We had a project before which the goal was set - “to increase the number of users who want to continue to deal with the product after the trial period”:

An impact was formulated - “shorten time to value”, i.e. reduce the time it takes for the user to understand what opportunities the product provides him, what problems he solves (starting from the moment when the user opens the autorun).

Ideally formulated impact - simple and directly affecting the goal.

In fact, a huge number of changes were made to the documentation, setup, GUI, and so on.



Step 4. What - What?
The last question for building a map is what? .. It is at this stage that features appear.
It should be understood that it is not always necessary to make changes in the product and develop something to provide the impact we need. Sometimes it is enough to change the documentation, for example. Or another example - to attract users, features are not always needed, an alternative solution may be marketing activity and advertising campaigns.



Stages of building a map
1. Determine the goal, not forgetting the requirements of SMART,
2. Choose a metric by which we will look as far as we are closer to the goal,
3. We define intermediate stages to achieve the goal (milestones),
4. We draw the backbone of the card, answering four key questions - why + who + how + what,
5. We are looking for possible alternatives, and it is desirable to focus not on features, but on roles (who?) And on how to influence them,
6. We determine the priority directions on the map,
7. As we move forward, we do not forget to make sure that we are really moving towards the goal in the most efficient way possible.



Map example
The example is honestly borrowed from the book, which will be mentioned closer to the end of the report.
1. An online game that aims to expand to 1 million players (the intermediate stage will grow 2 times from 400 to 800k players),
2. Several roles are highlighted, it is clearly visible that not only players, but also advertisers, such as
3. On each of the branches, several impacts are highlighted,
4. Features explicitly correspond to the goal. Remember our problems? Here we clearly see what we are doing, and why, moreover, we see several alternative options for moving towards the goal.
5. Asterisks on the branches of the map indicate priority directions,
6. Map branches easily fall on user story histories (As a ... I want to ... So that ...).



Implementing Impact Mapping in Dell
I acted as the initiator, therefore, first of all, the whole implementation was divided into stages.

The time for stage 1 was determined by the stars, but as it turned out, the end of the current release, the time when you need to start figuring out the tasks for the next version is the best time to start switching to new rails.

I started by selling the idea of ​​impact mapping to the product manager and explained to him why we need to live in a new way. We discussed what problems we, as a team, usually face, why we feel a lack of understanding where the product is going and why it is bad.

For our PMA, this dialogue was a surprise. However, he did not deny the obvious.

So, I presented the idea of ​​impact mapping and strongly chewed that the result is achieved by joint efforts and that we do not suggest that he again begin to write single-page MRDs individually.

After that, I began to slowly pull out from PMA the goal for the upcoming release, on which we already had a list of features for discussion
1. the most difficult thing here was to force the manager to set a specific goal, which would be measurable and achieved in a limited period of time,
2. from an hour-long assembly, we only butted for forty minutes around the target until we chose something similar to the truth,
3. I was once again convinced that the presence of thoughts in the head of the product manager does not necessarily mean that he can articulate it clearly.

At the end of the first meeting, we shared our impressions and agreed
1. think again about the goals (including in the longer term)
2. after a week to get together again to try to draw a map

For that week, while our product manager naturally didn’t think about goals, I prepared for the next meeting. I had a draft goal, there was an understanding that our manager would hardly agree to process everything that we had previously entered into backlog under zero. So I had to make some reverse engineering backlog and prepare the first version of the card for the upcoming release myself:
1. Roles were identified fairly quickly.
2. necessary effects too
3. but not all features were able to associate with the goal. Looking ahead, I will say that as a result, most of the "illogical features" were cut,

The resulting draft was presented to the product manager.
1. We discussed what did not fit into the goal and killed these features / stories
2. We discussed what else can be done in the framework of those roles that have already been identified,
3. There were several new roles for which there was no need to do anything on the side of the product, but to provide the necessary materials (marketing, presales),

Surprisingly, our product manager took an extremely active part in finalizing the map, which was being drawn before his eyes. Thanks to him, a large number of branches, not related to changes in the product, appeared on the map.

By the final stage of the implementation of impact mapping on our products, we will begin through the release, when the planning of the composition of features for the version will be initially outlined with the help of impact mapping.

So far, we have just felt how successful the first attempts will be.



Reviews within the company
1. The product manager expressed that he had already been stuffed with various near-Scramov methodologies many times, but this approach does not bother him and he likes it very much (of course, the map is in the area of ​​responsibility of analysts and is drawn by them).
2. The team has shown a good interest in what happened. They especially liked the fact that they listened to their opinions, and that they could offer a feature that was reasonable from the point of view of a business goal.
3. The team received a compass, with which it is easier to carry out sprint planning and minimize disputes around the sequence of stories and details of their implementation.
4. Our managers were happy that now, in order to understand the results of planning release, it is not necessary to conduct a general planning, but just look at the map. The discussion is quite easily transferred offline.
5. Everyone liked that not only the team’s activities sprouted onto the map, but also the activity that was previously shady (marketing work, pushing the product at the business level).
6. The analyst uses a map on each call according to the current state of affairs (current state call), which passes every week and passes along the key branches of the map. Now the focus is to keep more questions.



In order to get more information about this approach, the book of the same name Gojko Ajic is highly recommended.

PS At the next conference now receiving reports. So we are waiting for interesting posts!