Friederike from BMS tells us how she is driving product development in the financial sector

In this interview, Friederike reveals how to create products that are designed from the user’s perspective and succeed in the market, and how existing processes within corporate structures can be broken down to achieve this.

Product development at BMS

Friederike, what is your role?

As an external product manager, I’m responsible for both the business side of things and translating that into IT requirements. I work to bring the vision to life. Everyone on the team should understand why we do what we do. Together, we figure out how we can get closer to that vision. Specifically, in our case: How can we use software to enrich the day-to-day operations of a medium-sized business? 

How does the product development cycle work at your company? 

We take on a problem and try to understand it. Then we experiment to come up with a good solution. We test the concept through pilot programs and ultimately make the result available to the general public.

I guide my team through the entire process, from brainstorming to implementation. 

What do you consider to be the most important tools for putting the user at the center of product development?

So, first of all, you were right there with us, helping us develop the right mindset.

That said, experimentation is fundamental. It’s important to secure the necessary budget and time to listen to users without pressure, analyze their needs, and experiment. Through these conversations, we’ve realized that our users are happy to talk more about their companies and to have us as a sounding board.

At the end of the day, this approach saves a lot of money. Our learning curve was incredibly steep. It was like a small pebble that started rolling and triggered an internal avalanche: “Ah, if I invest here, I’ll save resources elsewhere.”

How do you feel about this shift in perception within companies? 

The cultural shifts are fascinating. We come from a culture where you can do anything. Even as a banker, I was taught to avoid risks and to have to be able to do everything. Furthermore, within the financial world, we’re heavily regulated and trained to focus on accuracy.

This culture of precision suddenly encountered experimental methods. And the fact is, we simply can’t and don’t know everything. Allowing for experimentation, consciously admitting ignorance in an interview, and asking what’s expected, we had to learn how to deal with unfamiliar situations.

It’s all the more rewarding that the experiments are going well and that we’re learning more about our users bit by bit. Being able to experience this process firsthand and gain insights together really changes your perspective.

The user testing process

How do you conduct user testing?

That really depends on what we’re doing and testing. We’ve learned a lot from you in terms of methodology. 

The most important part of an experiment is formulating a hypothesis. As a team, we consider what we believe and what we want to find out. With a well-formulated hypothesis, the right method almost automatically becomes clear. 

Depending on the target group, we work either remotely or in person. In both cases, we invite the participants to a session and give them a general overview of what we’re working on. Depending on the test, we then present them with a prototype, interview questions, cards they’re asked to prioritize, or A/B testing examples. And then we basically just observe and gather insights. 

In my experience, the interview is initially perceived as a challenge, but the real challenge tends to be putting the insights into practice.

At the beginning, we made an organizational mistake: We formulated our hypotheses and ran tests. We thought we could incorporate the findings into the sprint two weeks later and have our developers get started. But we made this plan without consulting our test participants. And that’s exactly where what you said comes into play.

We really need to take the time to discuss honestly, and above all, to understand what we’ve learned. Otherwise, we might as well skip the test altogether.

If we don’t start testing until two weeks before development, we won’t have time to learn. That’s why we sit down with the team after the test and discuss what we’ve learned. It’s really interesting that team members take away different insights and perceptions from the interviews. 

We’ve also had hypotheses that were later disproved. Our prototype was irrelevant to our users’ everyday lives. They were completely uninterested and bored. That sealed the deal for us: we don’t need to invest any more energy or money into further development. 

Solution space vs. problem space

It’s often not easy to separate the solution from the problem: have you noticed any changes in your team in this regard?

After conducting an experiment, we first focus solely on the observations. Only in the second step do we address interpretations.

We’ve reached the point where we’re aware of the difference and are taking the time to discuss it. I’d say that we’re constantly improving in this area within the project team. 

Have you had experience with other methods that support you in the process of user-centered product development?

For us, the interview is the most important tool. In addition to this qualitative method, we also use surveys, usually when we need a broader range of opinions. This allows us to verify whether we’re truly on the right track and to conduct a quantitative preliminary screening. 

Next steps

What would you like to try next?

I want to involve users even more. Currently, we make a shortlist and let users prioritize the items on it. The most important points are then tested for quality. In the future, I want to work even more with customer data to further develop the best possible solutions. Since our first products are now on the market, we can start there. It’s not rocket science, but for us, it’s the next step.

Empowerment

What role does empowerment play for you within your project team?

I regularly ask myself how I can better empower my colleagues. 

In addition to a culture of learning from mistakes, it’s primarily about being open to experimentation. I want to lead by example here. When we gain valuable insights through experiments and experience and discuss them together, it’s not only fun but also encourages interaction. 

Another important factor is the corporate environment in which we operate. Enablement is also about being able to break free from these corporate structures. A willingness to experiment means that we take our time, and that we don’t get bogged down in administration, documentation, and checklists. 

Thank you very much for your tips and insights, Friederike.