Mission & Strategy

In our previous article, we discussed the theory around the elaboration of strategic roadmaps. Nonetheless, there is still one question that remains:

How does this method prove to be efficient in putting the strategy and the goals on top and provide more importance to the outcome rather than the output?

In this article, we will show how strategic roadmaps apply in practice at Interhyp and what benefits we take from it. To illustrate this aspect, here is an example on how we approach a particular project on our team.

Our Mission in Digital Products and Technology

Our goal at Interhyp is to reach 20% marketshare: this is „Mission Zuhause“. As an active player to reach this goal, our Digital Products and Technology unit has the following mission:

Our Strategy in Digital Products and Technology

In order to fullfill our mission, we have the following strategy:

Why are we on a mission?

• We want to fulfill our mission „Mission Zuhause“ 20% marketshare

What is our mission as a unit?

• We want to provide the largest digital platform and be technology leaders [for our customers]

How do we fullfil our mission?

• We foster an agile company culture
• We facilitate the interaction between customers, brokers, banks and partners with our business solutions
• We provide customised financing solutions through reliables products and algorithms
• We develop a platform, which is based on a modern, open, safe and resilient architecture.

Which value do we generate?

• We generate customer trust and satisfaction on a long term.

Practical Case on a Squad Level

Taking this into account we know that a few applications on our website do not align with the mission and strategy above. Our squad will focus on our mortgage-calculator:

This application is problematic because:

• We are not „technology leaders enabling an effortless and smooth way towards your own home“ if the application requires an excessive time to load completely on the page (Score below 30 in Page Speed Insight for desktop), which hypothetically increase our bounce-rate (70%)

• We intent to use a modern technology by refactoring the application completely, using a more recent framework

Therefore, we define our Goal and Key Results in line with our strategy:

Our Goal and Key Result (OKR)

Objective: we develop the interhyp website according to market standards with an optimal UX and SEO-optimized content

Key Result: Decrease the loading time of the mortgage-calculator page and reach a PageSpeed Insight Score above 90

Idea to achieve our goal or tactics

Hence, we have the idea to re-factor our mortgage-calculator application and we add it in our Idea Bank. Page speed being a more and more important factor, the idea is highly scored and can go through the necessary steps.

Steps

We plan a technical re-factoring with no changes in the user experience. The Goal is primarily to decrease the loading time of the page.

We can then start refining the idea and break it down into backlog items. Initially, the re-factoring was estimated to take 2 sprints.

Nonetheless, during refinement of the idea, difficulties start to appear and it turns out that the re-factoring would take more time than what was initially estimated.

With a new Ease estimation, we have to recalculate the ICE Score and it seems that our „tactics“ of re-factoring can’t be highly prioritized anymore, due to the increased effort. In the meantime, we still need to stick to our strategy and our goal.

So maybe, we won’t be able to modernize our application, but there might be some alternative, other hypothesis we can explore to reach our goal.

Change of tactics

So, we drop the idea, and re-engage the dialog with other colleagues, stakeholders to review different hypothesis, that would help us increase the page speed.

Along the conversations we had, a few ideas comes to our attention:

• The application could be loaded at a later stage (after a specific click-event, for instance). That way, we postpone the loading of the application and the page would simply load faster without the application.
• The consent manager we show at first page load can have a negative impact on the loading time and its refactoring on the other hand, would be easier and would bring some value as far as our goal is concerned

Tasks

As it turns out, after refinement, these changes can be implemented faster than in the initial plan. Having in focus the goal of reducing the loading time of the page, we can schedule the implementation in 1 or 2 sprints and implement the mentioned changes.

Outcome

After releasing the changes, we observed that the loading time was reduced down to 1,5 seconds on desktop. It turns out that a short-scale and flexible plan worked in order to make progress increasing page speed. On the long term, this improvement helped to decrease our bounce rate at a level around 66%.

This being said, we didn’t reach the goal of having a score above 90 for mobile, but made good progress with an actual score of 70 of mobile and 96 on desktop, and managed to have a positive outcome with a reduction of our bounce rate.

Therefore, the goal of reaching 90 for mobile remains and further hypothesis will be reviewed in order to reach this score.

Outcome VS output, the advantage of a strategic roadmap

Overall, we can see here how the team didn’t focus on the output (a refactored application) but put the strategy and defined goal on top and remained focused on the outcome (increasing the page speed, reducing bounce rate). This was possible thanks to two things:

• The team had a clear goal to achieve. Using the OKR and GIST frameworks, it helped them to look for ideas goal-focused. The point was always to increase page speed regardless which hypothesis or feature will be implemented.

• A proper goal couldn’t have been defined without a proper strategy. Considering that the organization wants to reach its purpose with a common strategy, it gave the team the possibility to identify objectives they can fulfill with their expertise on the product the actually work on (in this case, an application on a webpage).

At the end of the quarter, no one expected the team to come up and show that they have re-factored an application. Instead, the team was asked if they reached this goal of increasing page speed for this app: outcome won the battle over the output!