How to make an impact with software

If you have ever worked in software product development you have probably asked yourself (or been asked by software engineers) the following questions:

• What is the strategy for the product?
• What is the link between user stories and the business goal?

The tactical view

Software development teams usually focus on the tactical view, looking at the user journey and feature descriptions. Then teams will break down the work backlog into epics and user stories, working on acceptance criteria and examples, prioritising work, planning releases and iterations. Then teams have daily coordination stand-up meetings, an iteration review session, and a retrospective meeting.

The greatest effort focuses on optimising the process of solution delivery, starting from requirements clarification and ending with product rollout. Even the fact that teams are often looking for feedback from the Product Owner and adjusting the backlog of work to reflect it, people tend to ask what is the strategy.

The big picture

As a software engineer and then an architect, I worked on a product that supported business operations where unpredictable things often happened. I could observe how people worked on a daily basis and see the problems they faced whenever a system outage occurred. When I was troubleshooting issues on-site for the customer, or negotiating a technical solution, I learned a lot about the business itself. I knew exactly:

- Who was going to use our software and why

- What features they would need and

- How it was going to change their work.

I was highly motivated to create the best experience for the end user and this gave me a lot of job satisfaction. I built strong relationships with customers and was constantly in contact with them. And I kept the big picture in mind. Seeing the big picture places everything in context, which is good for solution quality and job satisfaction.

How does dev effort correspond to the goals?

When I decided to make the move from a technical role to that of software development manager I realized that my teams were focusing on deliverables, not knowing how business goals corresponded to their daily work. Sometimes they didn’t know who exactly would be using the software and how it would change their behavior.

The same problem of a missing context applies to the most of teams I worked with.

The strategic view

Usually, teams know the goal and their work backlog but struggle to link the two together. Impact Mapping by Gojko Adzic can help here. It is a strategic planning technique which structures discussion between technical and non-technical people to align them with an understanding of the product strategy.

This model helps to improve the questions asked about the:

· Goal. Why is the solution needed?

Each goal needs to be S.M.A.R.T. (Specific, Measurable, Action-oriented, Realistic, Time-based).

· Actor. Who is going to use it?

The Actor(s) should be as specific as possible. Ask who will be impacted by the goal? Who are the consumers? What are the segments of users? Do they have different needs? Who can obstruct the goal? Who are the competitors?

· Impact. How should it work?

The Impact(s) tells us how actors’ behavior will change. If we have competitors, how are their business decisions going to change?

· Deliverable. What should it do?

What strategies can we use to support the required impacts?

Each time we link Goal to Actor, Actor to Impact and Impact to Deliverables, we are making a business assumption which needs to be validated. We only control deliverables and must measure the progress the team is making towards the goal, checking how deliverables are making an impact on the actors. We can expect that some ideas or assumptions will be wrong and that the approach will need to be adjusted.

Example

Since an example always helps to understand the situation better, below is an impact map with an annual goal to “increase net revenue by 10%”. I’m sharing very generic data to make it easy to understand. In a real situation, Actors should be as specific as possible. The same is true of impact and deliverables.

Each time we make a business assumption, we need to agree with all stakeholders as to how we are going to measure our return on investment. Always measure impact and remove features from the software that were bad ideas. It does not make sense to keep everything and increase the cost of maintenance and regression testing.

Conclusions

Impact mapping by Gojko Adzic is a visual method that helps to set a context for software engineers. It is a way to structure the conversation between technical and non-technical people on a common understanding of the goal and big picture, aligning ideas, identifying business assumptions, improving planning and prioritisation, and motivating teams, since the work itself should give the greatest job satisfaction.

At the same time, the most important decision is to decide how you make decisions, how you measure whether the goal was achieved or whether you need to modify the approach and remove bad ideas or features from the product.