Impact Mapping - how can a dev team stop doing what they need and start doing what it needs? / Company Blog Testing Laboratory

Report from last year’s conference of system and business analysis specialists - Analyst Days 2013 from the senior analyst of the St. Petersburg office of DELL company - Dmitry Petrashev

On the report page you can find the presentation and video, and here the text ...




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

1. I’ll tell you what it is,
2. I’ll explain why we became interested in them and decided to introduce them in our company,
3. I will share the experience of implementation and what came of it.

I’ll immediately make a remark that we have a grocery company and in my story there will probably be a lot of our specificity. But it is worth explaining that the approach itself is universal enough to be applied both in custom development and in any specific scenarios.

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



Interaction between 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 .

• It determines what strategic business goals the product faces, compares them with where the whole company is moving, communicates with key and significant customers, and so on.
• Knowing the business goals, the product manager creates a list of necessary changes for the next release and through analytics passes them to the dev team.

In the twelve time zones from him lives a development team that implements the necessary features and basically neither by sleep nor by spirit why changes are required just like that. Backlog for them is just a list of purchases for which they sent to the store. What exactly will they cook, as a rule, they do not know.
So, what well-known problems are growing due to this communication gap.



Problems
1. Since the decision about what changes are needed in the product to achieve the 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 heading is not motivated to make it better. They just cover features, no more.
3. To explain to the team exactly how the feature should be implemented and why in this order, without knowing the original goal, is extremely difficult.
4. We develop an occupational disease for any product manager. They simply love closer to the release date to expand the requirements with various trivial things that are free in their opinion. All these “minor edits” are very difficult to get out of the backlog simply because we don’t know if they are really not 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 speak more than write.
2. There were “themes” = themes, which were supposed to describe the release and set the general trend of all changes in one paragraph. It didn't work either.
Impact mapping has become another attempt for us to clarify where the product is moving and how we, as a development team, contribute to this.



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

The name of the approach (impact - impact) is determined by what we are trying to understand: who and what kind of impact can have on our goal, and only then we 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 business and representatives of the virgins. No multi-page documents, only one well-structured scheme.

To prepare a map, you need to answer 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 do we think that something needs to be changed in the product
At this step, we determine the goal. The goal naturally should be smart (SMART):
1. Specific,
2. Measurable,
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 it is unlikely that his goal meets the criteria. We still have to work on this goal.

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



Step 2. Who - Who
Next answers the Who question? - who? The main task is to determine the circle of interested (or not so) people.
1. Who can help us achieve our goal?
2. Who can interfere?

At this step, it is important to consider all the persons involved, and not just users. Anyone who can influence the result should get on our card. 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 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 helps us to achieve the goal?
2. We determine the impact on users and other actors.

This is perhaps the only “question” from the entire impact mapping approach, which requires explanation by example.

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

impact was formulated - “shorten time to value”, i.e. to reduce the time period that the user needs to understand what opportunities the product provides him with, what problems he solves (starting from the moment 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.
You need to understand that it is not always necessary to make changes to the product and develop something to provide the desired impact. Sometimes it’s enough to change the documentation, for example. Or another example - to attract users, features are not always needed, an alternative solution could be marketing activity and advertising campaigns.



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



Sample map The
example is honestly borrowed from a book that will be mentioned near the end of the report.
1. An online game with the goal of expanding to 1 million players (the intermediate stage will grow 2 times from 400 to 800k players),
2. Several roles have been highlighted, not only the players, but also the advertisers, for example,
3 can help us achieve the goal . Each of the branches has several effects
4. Features explicitly correspond to the purpose. Remember our problems? Here we clearly see what we are doing, why, and moreover, we see several alternative options for moving towards the goal.
5. Asterisks on the map branches indicate priority directions,
6. Map branches easily fit on user stories (As a ... I want to ... So that ...).



Deploying Impact Mapping in Dell
I acted as the initiator, so first of all, the 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, this is the best time to start the transition to new rails.

I started by selling the idea of ​​impact mapping to the product manager and explaining to him why we need to live a new life. We discussed - what problems we, as a girl team, usually encounter, why we feel a lack of understanding - where the product is moving and why it is bad.

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

So, I introduced the idea of ​​impact mapping and strongly chewed that the result is achieved jointly and that we do not suggest that he again begin to write single-page MRDs alone.

After that, I began to slowly pull out a goal from PM for the upcoming release, according to which we already had a list of features for discussion
1. the most difficult thing here was to get the manager to set a specific goal, which would be measurable and achieved in a limited period of time,
2. from an hour-long meeting, we only butted around the goal for forty minutes until we chose something similar to the truth,
3 . 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. once again to think about goals (including in the longer term)
2. in a week to get together again in order to try to draw a map

For that week, while our product manager naturally did NOT think about goals, I prepared for the next meeting. I had a draft goal, there was an understanding that it is unlikely that our manager would agree to zero-process everything that we had previously entered in the backlog. Therefore, I had to do some reverse engineering of the backlog and prepare the first version of the map for the upcoming release myself:
1. Roles were identified quite quickly
2. Necessary effects too
3. But not all features were able to be connected with the goal. Looking ahead, I’ll say that as a result, most of the “illogical features” were cut out.

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

surprisingly our product The manager took an extremely active part in finalizing the map, which was being completed before his eyes. It was thanks to him that a large number of branches appeared on the map that were not related to changes in the product.

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

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



Reviews within the company
1. The product manager said that he had been stuffed with various near-Scrum methodologies many times, but this approach does not bother him and he really likes it (naturally, the map is in the analysts' area of ​​responsibility and is drawn by them).
2. The team showed a good interest in what happened. They especially liked that they listen to their opinion, and that they can offer a feature that is justified in terms of a business goal.
3. The team received a compass, with which it is easier to plan sprints and minimize disputes around the sequence of stories and the details of their implementation.
4. Our managers were happy that now to understand the results of release planning it is not necessary to carry out a general planning, but just look at the map. The discussion at the same time is quite easily transferred offline.
5. Everyone liked that not only the team’s activity sprouted onto the card, but also activity that had previously been shadow (marketing work, pushing the product at the business level).
6. The analyst uses the card on each call on the current state call, which runs every week and goes through the key branches of the card. Now it turns out to be in focus to keep more questions.



In order to get more information about this approach, the book of the same name by Goiko Adzic is highly recommended.

PS At the next conference is now still being received reports. So we are waiting for interesting messages!