How to Use Impact Mapping in IT Projects: Setting Goals, Choosing Solutions, and Building an Effective Product Strategy
28.12.2019 Do you think the success of any e-Commerce project depends on developers? Let's get acquainted with unit economics and learn more about the data-driven approach to decision-making.
Clients often approach developers as if they were magicians, hoping they will create a miracle IT product.
It will solve every problem: bring in crowds of customers, increase sales, and cut costs.
But without the client's own effort and without precise financial calculations, this is impossible.
Do clients evaluate the economic impact of implementing each feature?
Are developers given only tasks that will definitely produce results?
Practice shows that the client does do some planning, but the backlog of tasks assigned to developers rarely aligns with business goals and objectives, and is revised even less often. After months of development without understanding the economic impact, it is easy to end up with negative results and exceed budgets.
Another problem is conflicts of interest between departments.
For the team to work effectively and the project to reach its goals faster, some backlog items must have the highest priority and others a lower one.
If different departments on the client's side do not understand that their tasks are being postponed in favor of other tasks for a fair reason, a lot of speculation and conflict arises.
This article looks at how to approach planning and development management while taking the listed problems into account.
Edward Deming formulated the PDCA continuous quality management model: plan-do-check-act. The PDCA cycle is closely linked to the Agile philosophy and also encourages us to work in short iterations, stay closely connected to reality, and check each time whether we are moving in the right direction.
and a unit calculator as one of the practical tools of DDDM (data-driven decision making). Impact Mapping The Impact Mapping method helps clearly define project goals in line with the goals of the business as a whole. To do this, you need to build a mind map answering four key questions.
Why? Why is this product needed? What business problem should it solve?
Who? Who can influence achieving this goal?
How? What can it do?
What? What specific steps should the responsible person take within their tasks? Example of how the Impact Mapping method works
1. Excess functionality C
Make the value of each action visible. If there is no value, then it is an unnecessary solution and should be rejected.
Misalignment of actions, lack of control and coordination within the client's company. To answer the question "who?", you need to identify everyone who influences the solution to the problem. Managers from production and sales, marketers and logistics specialists, and any other employees who can affect the product being developed and the final achievement of goals, should at least meet and discuss all tasks. Each person's area of responsibility will be recorded in the impact map.
This makes it easier to track the execution of decisions. What happens if you skip this step is explained in the next case study. We built a B2B portal for a wholesale food supplier. The client described the functionality they wanted, but it turned out that in real life everything works differently than in their imagination. This was discovered only when one of the departments tested the product, although no one thought it necessary to involve them in creating the technical specification (a separate question is why they needed a technical specification at all).
The project launch had to be postponed.
It is hard to compare different options. For each goal in Impact Mapping, all possible ways to achieve that goal are grouped together. After analyzing and comparing their effectiveness against specific KPI/OKR, we can be confident that our decision is the right one, with no agonizing over the choice.
It is hard to plan development time and budget. This is probably the most common fear clients have about agile development methodologies. But when all actions are broken into steps, planning becomes much easier, right? If you work in short iterations (for example, two weeks), follow the PDCA cycle, regularly compare your actions with your goals, and quickly make adjustments when there are deviations, it is easier to succeed than with a one-year or five-year planning horizon.
The main result of using impact maps is a clear solution to the customer's business problems, not features for the sake of features.
Suppose a client comes to an IT company: the owner of a large online store for clothing and shoes, requesting an urgent website redesign. Project managers cannot accept a task phrased like that, because it does not fit a data-driven approach to management decisions. First, they need to ask "why?" and define the project goal, then quantify it and express it numerically.
Otherwise, it will be impossible to evaluate the results and draw conclusions ("we did a good job, we achieved the goal"
or "we failed to reach the goal, let's think about why and how to fix it.") For example, after a joint discussion, it may turn out that the client's business goal is to increase sales by 1.5% over the next three months. Project managers need to make
together with the client, and the picture may look like this: there are four ways to achieve a 1.5% increase in sales.
The Impact Mapping method can also be used for B2B portals, for example to assess the share of orders placed through the portal (ideally 100%).
For a CRM/BPM system, the target metric may be the percentage of users working in CRM out of the total number of employees. In the case of our client, who wanted a redesign, the question arises: maybe a redesign is not needed at all?
To find out, we will compare all solution options and choose the most beneficial one.
A useful method for this comparison is unit economics.
It also helps check how your values align with real actions.
Let's take a closer look at a very useful tool:
which we always use for e-Commerce projects ourselves and recommend everyone use before starting a development task.
Every action, meaning the development of each piece of functionality, should ideally be tied to some project value.
A green button or a new design must somehow improve project metrics and pay off somehow.
If development is not tied to business value, the cost of development will seem very high to the client. Unit economics clearly shows the profitability of each change in the project or of the project as a whole: how much the business earns or loses from each order, each user, and each end customer.
For this, it is convenient to use a unit calculator in the form of an Excel spreadsheet.
Let's look at the simplest version of such a calculator (in reality, unit economics has many more influencing factors and much more complex formulas, but this example will help us grasp the main calculation principles).
Example of a simple unit calculator. In this table, we change the values in the input cells (user or lead traffic, conversion, number of paying customers, revenue per paying customer, average customer spend, cost per sale or commission, number of purchases per paying customer) to see how the value in the dependent cell changes (gross profit, or revenue). You can add any factors specific to your business as input cells.
For example, different sales channels, the cost of acquiring new users, changes in logistics costs, and so on. In some cases, when we receive tasks from clients, we suggest they first use a unit calculator to assess what impact the implementation of a new feature will have and how revenue will change. Why do we do this?
We cannot afford work that goes nowhere; the shortage of skilled developers and the market's constant demand for improvements mean that the project backlog is always larger than the team can realistically deliver. The features the client wants to implement need to be prioritized, and some should be rejected altogether.
We are currently working on an e-commerce project for a major jewelry brand.
Payments for orders in their online store are processed on the bank's website.
The client wants to redesign the checkout and add a payment form directly on the website.
To take on this task, the project manager needs to align its value with the project's ultimate business goals.
The main problem may be the lack of analytics.
What should you do if no one has ever tracked what percentage of potential buyers drop off at the payment step?
Does paying through a bank's website really hurt sales?
If the difference in conversion is zero or insignificant, then changing the payment form will bring no benefit, while during that time we will not be able to build some other, more important functionality.
The effect may be exactly the opposite: customers may hesitate to pay immediately on the site, which would reduce sales.
Without analytics for the before state, it is impossible to tell whether the after state will be better or worse. In this example, web analytics must be connected first to gather data for a sound decision.
If we see that the problem really exists, we will change the payment method using the PDCA cycle: plan, change, measure, and if the result is unsatisfactory, roll it back.
1. If the feature proposed by the client has no significant role, having this information can help the client reprioritize the backlog.
If the unit calculator shows that even a 0.01% change in conversion will produce a significant financial result, improvements should start with the narrowest points in the sales funnel.
But conversion is far from always the main factor.
Sometimes it is better to first work on retention or provide the project with quality traffic, and only then return to feature development.
When ordering development, clients are usually enthusiastic.
They feel that now there will finally be that magical pill that solves their problems.
They focus on IT, forgetting about conversion and profitability.
After working with IIDF (the Internet Initiatives Development Fund), we learned firmly that it is essential to draw up
and unit economics for each project must be calculated before work begins. Then, when implementing any changes, they should be constantly reviewed and recalculated. Ideally, the client should do this. But we sometimes see development decisions being made without specific numbers, and in such cases we are ready to help with consulting.
This is how we develop a data-driven approach to management decision-making for our clients, and the results are encouraging: bad features have been reduced to zero, clients' business goals are achieved quickly, which is reflected in a high NPS for our projects as well (over the past two months, the team received the maximum 10 points twice).
