Stop adding features, start removing problems – an interview with CTO Mika Peuralahti

The CTO vs Status Quo series studies how CTOs challenge the current state of affairs at their company to push it toward a new height … or to save it from doom.

How to make a business case for a new tech initiative to the board?

One way to challenge the status quo is to champion a new tech initiative, like a platform migration or AI. We’re talking about it to Mika Peuralahti, CTO of Smartum. Get practice-shaped CTO insights about:

• Best practices of talking to the board and team about new tech initiatives.
• The process for making a business case.
• Now vs then – did the recent global economic crisis change the whole game?

About Mika Peuralahti

Making a case for a tech initiative with Smartum’s Mika Peuralahti

Jakub Piłucki: Hi Mika. It took a while for us to finally meet, but you were busy after all. I might have heard that you’ve got yourself something really nice from the Tampere Chamber of Commerce. What is it about?

Indeed, it’s been a hectic period. In addition to my day job, I also sit on the board of a software consultancy firm, managing around 60 developers.

Being a board member comes with a steep learning curve—you have to familiarize yourself with a myriad of new things, including legal responsibilities and gain an in-depth understanding of written contracts.

That’s exactly what the course from the Tampere Chamber of Commerce covered. It is structured to activate and develop board work, benefiting both seasoned board members and those who are just considering stepping into such a role. It’s not only about the legalities but also about honing strategic leadership skills.

The lectures and case studies from the Certified Board Member (CBM) program were particularly enriching, offering substantial support in my current day-to-day role as a CTO and in my contributions to the executive team’s efforts in steering the company.

Tech initiatives in the post-COVID era

There was a time when to sell an idea in an organization, all you needed to do was tell a good story. Everyone wanted to grow quickly. Then the post-COVID economic crisis hit and suddenly everyone wanted to pivot, scale back, save what they had. You joined Smartum in the COVID-obsessed 2021. Tell me how you experienced this period.

Yes, I joined right in the middle of the pandemic. Certainly, many businesses were cutting costs.

Smartum is in the benefits business. Companies typically purchase benefits for their employees at the beginning of a year. The January of 2021 was quite good because the COVID craze lessened. But then it came back in full force in the autumn so we were kind of worried about the year 2022.

We decided earlier that to continue our growth, we need to start focusing on customer needs, on solving real problems they have, instead of doing everything.

So you focused on long-term strategies that could benefit you potentially some time in the future, but then you switched to more short-time objectives? 

You could say that. Before COVID, we focused on selling benefits to the employers. During the pandemic, many venues closed their doors. Sports benefits aren’t useful when sports facilities are closed. The same goes for cultural benefits when you can no longer go to the theater or cinema. 

We had to focus on the employee side and think how to ensure that they can actually use the benefits. We didn’t want to provide them with something they couldn’t use.

We decided to focus completely on this issue.

So it is all about the value then. From what I can tell, you seem to put a lot of emphasis on business revenue personally. I wonder to what extent creating value for the user is easily translatable into revenue. A lot of companies are investing in what’s known as RevOps – total alignment of all departments for the sake of generating revenue and holding everyone accountable for it. What do you think about that approach?

When I joined Smartum, there was a business unit and then there was a technology unit – they were separated. The business unit ordered features and we built them. But we didn’t have any clue whether this particular feature was worth building or not. To change that, I came up with an initiative to create end-to-end teams.

When you have end-to-end teams it means that the team can make decisions on its own. It allowed me to get rid of this whole “feature factor”. 

Instead, we gave each team a business manager who calculates the revenue of the current product.

Then we got rid of all the roadmaps. Because I hate roadmaps. They usually talk about features and set a date for each feature to come out. I don’t believe in this approach at all. I believe in problems.

We discover a problem and we try to estimate how much revenue solving this problem could bring us. Then, we prioritize the problems and begin working on them starting with the most critical ones.

I want to know how many customers we get when we solve a given issue and why this is an issue for us in the first place. Only then we can start thinking about features and tasks. And once we are done, we analyze if the new release brought us the revenue we planned.

So you’ve created a kind of priority list first. And then try to tackle the most painful issues.

Absolutely. We had this extensive backlog crammed with features, and yet often there wasn’t a clear understanding of what we aimed to achieve with each one. As a CTO, it became increasingly important for me to grasp what we were actually delivering to our customers. 

Previously, our backlog tended to be just a collection of features. I remember questioning the team, ‘Why are we working on this feature, like a “blue button”?’ The immediate answer would be, ‘Because that’s what the customer wants.’

But delving deeper with the team and questioning why the customer wanted that blue button, we discovered it was to streamline their process, say for distributing benefits.

Upon further probing into why the benefits distribution needed simplification, we would uncover a problem that could lead to a completely different solution than just adding a ‘blue button.’ It might even result in removing all buttons from the interface, thereby addressing the customer’s original issue more effectively.

This insight led us to a paradigm shift. We started practicing and developing a mindset where our backlog should be more about problems and opportunities rather than features. This way, the solution could be anything that evolves as the team picks up the problem from the backlog.

Now, we drive our development with a prioritized list of opportunities and problems, focusing on the value each solution brings to our customers and to our business when that problem is solved.

So basically you reverse-engineered the whole feature-making process?

I was keen on the idea that developers and development teams should be the ones to conceive features that best fit a solution for a given problem, given their expertise in this field.

We maintain that the understanding of the customer’s issues should come from the customer interface and the business side – these are critical insights we can’t overlook.

It’s essential to hold onto the principle that we’re striving to comprehend the problem thoroughly and extract it from the business developers, ensuring that the solution we create is not only technically sound but also effectively resolves customer issues.

Best practices of making a business case

To push any initiative forward, you need the buy-in of the board. How much of this support depends on the pitch itself and how much on slow and steady relationship building with the board?

We aimed to further enhance our product development, which was also a directive from the company’s board. In our case, it wasn’t difficult to justify the need for changes to the board, as the efficiency gains from the changes were easily measurable.

We also began to focus on measuring the value created for the customer in product development and the extent to which this value creation was reflected in our business growth.

Our focus has shifted away from merely implementing features. Instead, we are centering on measuring the value generated and its impact on our business.

Is there ever a situation though where you want to implement something specific regardless of whether you can measure the business impact?

We’re contemplating the development of a new mobile app. But is the new app truly going to be better? How do we determine that? Sometimes the answer might be subjective, like it has a better appearance. However, is our issue really about the app looking unattractive, or is there a deeper problem with the current app?

Often, if the decision to redesign is based solely on a subjective feeling, we end up merely replicating the old app with a different look and feel, inadvertently preserving its issues because we haven’t fully grasped what we actually want to improve.

It’s crucial that once we understand what needs to be enhanced, we set clear, measurable goals and verify them concurrently as the new app is developed.

There always must be a very good reason for doing anything, especially something big. The point of a product upgrade is to generate more customer value and through that, it impacts positively for revenue. If that’s the case, you should do it.

How do you foster a culture that allows for both different opinions and finding a common ground within the board and the whole company?

I think that my entire approach that I described is very open to innovation. We do have some long-term strategic goals. Let’s say we want to get to the top 10 biggest employers by a certain date. And then the question is what problems keep us from getting there. 

Then, we go to our team and present it as a challenge. And you can come up with any idea you want as long as you think you can use it to face this challenge and measure it. If the numbers say it doesn’t work, you should stop what you’re doing right away. So the team doesn’t need to ask for any permission as long as they can measure their work.

We have very highly motivated developers now that the feature factor is gone. They become more interested in innovating. They implement small changes in their work and observe the effects. They need to analyze the change and why it was positive so that they can do that again in the future.

Smartum presents itself as the provider of well-being to businesses and their employees. How important is this open exchange of new initiatives to the well-being of your people?

It’s very important, within certain limits, like the technology stack, which needs to be unified across all teams so that we don’t end up with a huge mess. But when it comes to ideas, features, concepts, they have a lot of freedom and we want them to have fun with it.

We know how Smartum’s IT pushes new initiatives forward. Is there something CTOs or their teams should NOT do when dealing with new tech initiative ideas?

Never make fun of a coworker’s idea. There are really no stupid ideas. Some just need refinement.

But that doesn’t mean you should not have conflicts. Conflicts are good.

Do you have any?

Yes. Conflicts, the way I think of them, are healthy. When you have a new idea, you should have a discussion about it.

You should not be scared of a conflict, because this is a great way to validate the idea. If the idea is received well, it will find its allies. If it is flawed, you will get new insights.

But when one is allowed to push an idea without facing a conflict, one can find out too late that the team doesn’t feel it. They keep it inside. And when you hit the wall, they may be like: “ha, I knew it!”.

If everyone takes part in the ownership of the idea from the beginning, they will be more motivated and feel better about it.

But what if you are wrong? What if the initiative doesn’t work out? Forget and move on? Own the failure? How can a CTO keep his reputation intact in the face of defeat?

I want to understand why I was wrong. What I missed and what new things I learned. So basically I want to walk through it, so we can all learn from it.

And the same is true for success as well. Even if we succeed, we need to talk it through, analyze it, understand why we succeeded and learn from it. Otherwise, the success won’t be easy to repeat.

For me, it seems that the CTO should also be responsible for saying: hold your horses! Say a CTO talked to the lead developer and concluded that a big overhaul of the legacy platform is needed. If they don’t do it, it won’t be scalable. But to someone non-technical “legacy” or “scalable” may feel vague. What can a CTO do about it?

I only stop new ideas when I’m not satisfied with the answer I hear when I ask: how does it relate to our current strategy and focus?

If it’s totally out of focus, then it’s not the right idea at the moment. We need to keep our current focus. That’s crucial. Even if the idea is interesting, I’m not going to let it go through if it doesn’t affect the numbers we go for.

Making a case for a tech initiative – the process

Let’s say you see a problem within your organization and a technological solution for it. You got some allies among developers and other employees. What’s next? Many CTOs must be wondering if there’s an effective process for obtaining buy-in.

So we have OKRs, which make a major part of our strategy. We have guidelines that tell us what we’re trying to solve during the year, but the individual teams set different objectives to help the strategy go on.

Let’s say that this quarter we were trying to raise the usage of a specific benefit because only 50% of the annual objective was met and there are only months left. We want it to rise to at least 90% so the team is focusing on that. That’s an example of a KPI in our company.

When the original goal is not met, the team commits to focusing on those metrics in the next period to make up for it. They’re free to think about what they can do in the next quarter to achieve the goal. They can set KPIs for achieving these supporting objectives too.

Congratulations on that because I know companies that have been trying to get this process of optimizing OKRs for years and they can’t get it right. And often, the entire responsibility is on the board and not the individual team members.

There are different ways of doing it, that’s for sure. I have seen companies where the directors take on the topic and even often come up with OKRs.

But at our Smartum, we’re just giving the strategic guidelines. The teams work on practical implementations and they are also involved in figuring out our goals for the next term.

Further reading & resources

Your everyday work is definitely a great learning experience in making business cases, but I’m sure you also get insights from other sources. Which books or online content can you recommend?

Yeah, I have been reading many books on the subjects covered here. I’m especially fond of the Lean Startup book, this way of doing things. Of course, we don’t follow it to the letter, because the theory only works one-to-one in a perfect world, but we do try to fit this lean approach into our processes.

And regarding this, I also have to say – forget the timeline. I think it’s a wrong question to ask when something will be done. The right question is when we should start.

What’s next? 3 actions for CTOs to take

What do you think about the problems-over-features approach at Smartum as described by its own CTO? Is it something you are familiar with or have you tried to implement it at your organization?

If you’d like to introduce the problem-focused approach to development:

1. Introduce the problems-over-features approach by discussing user problems with all of your team members – make sure to note them all down.
2. Sort the problems by their priority and focus on those whose impact you can measure.
3. Pick overarching goals for each period and democratize your idea generation by letting everyone take part in deciding what’s the best way to reach them.

Good luck with your next technology initiative!

About Smartum

When you think about employee benefits in Finland, you think Smartum.

It serves 1,000,000+ users and leads the way in terms of promoting the well-being of employees and the impact employers might have on that. Smartum collaborated with The Software House on a major digital transformation move, which saw them ditch printed coupons in favor of digital vouchers.