Alignment Through User Centricity

Jesper Stenberg at UXDX Community: Nordics. Video: https://youtu.be/oWwSEtYfBSM

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

From startup to scale-up

[00:00:01] Hi, thanks for tuning in today. My name is Jesper, and I'm the head of product at Mestro. We are a company that helps property owners, property managers and also tenants to reduce their energy and at the same time reduce their environmental impact. I'm here to talk to you today about how we shifted from a startup company to a full-blown scale-up, which is now also listed on Nasdaq. You will learn how we democratized our product development process, and how at the same time we managed to grow more with our customers while still keeping our churn at almost zero percent. I'll start from the time when I started at Mestro almost five years ago and stretch up until today, when we're a completely different company.

[00:00:56] So how did I end up at Mestro in the first place? Well, I have a background as an industrial engineering student, with a master's degree in industrial management. After my studies I found myself very interested in how technology was used by people, and also how technology could be used as a means of improving sustainability and reducing the environmental impact of us humans. So I started my research at university. After that I joined a research group in smart grids, with projects mostly in Sweden, but there were also some research networks around Europe. I found that very interesting, and it gave me a good background in the energy market, both how the technology worked and the economics behind it all.

[00:01:52] My interest in energy and infrastructure later took me to RISE, the Research Institutes of Sweden, where I was involved in different projects and mostly stayed in Johannesburg, South Africa, and surrounding areas, working together with UNISA and others around the university on different projects with the energy supply where infrastructure is lacking or very poor. I think it was somewhere in those projects that I found myself again wanting to have more direct impact, and I asked myself, where do I go? The answer was obvious: of course I will join a startup. So I started at Mestro almost five years ago as part of the customer success team, and after a couple of years I got the opportunity to start and build up a whole new product department, built around what Mestro wants to be today and our ambitious plans for the future. I will share with you some of these lessons.

[00:02:58] But first I will just briefly talk a little bit about what we do as a company, and if you are interested in learning more, you can log on to our website and read up on us. Mestro is a Stockholm-based SaaS company in energy and sustainability management. Basically what we do is help our clients by collecting, storing, analyzing and visualizing the measurable data that flows through buildings. This data is used in many different ways: for energy efficiency measures, sustainability reporting, budgeting. We have a wide range of stakeholders, and as you understand, this also makes our offering quite complex. Because of that, we need a very well-structured approach to product development and UX design, to avoid scope creep and make sure that our products are user friendly for all our stakeholders.

The sales-driven years

[00:04:11] When I started at Mestro back in 2017, we were still very much a startup company, with all the good and also bad things that come with that. We had a very small development team, and they were responsible for everything: developing the product, maintenance of the product, and also delivering things to actual customers. They were working very closely with the customer success team, collaborating to fill in the gaps that our product had.

[00:04:47] At this point in time, I would say we had three main issues that were affecting product development. We had too many individual needs of individual clients being met. This gave the effect of a very sales-driven development process, and because of that, the goals for product development were very fragmented, based on a varied set of needs. Why is this a problem? It's not a problem if you understand it and do something about it. I'm not saying that it was wrong of us to have this kind of process at that point in time. I think it's inevitable for a startup at a certain point of its life to have to say yes to all needs coming from clients.

[00:05:43] But the problem is that we were past that point. We didn't have to say yes anymore, because we had landed and had a stable platform and were about to scale up, but we still said yes to everything, which crippled us and our growth at the time. The problem here was that the priorities were completely sales driven, which meant that it was basically impossible for our development team to reach their goals. Of course that's a very stressful environment, to always be trailing and always feel like you don't perform enough.

[00:06:24] And of course the tension between the sales team and the development team, and also customer success together with the developers who were delivering our product in the end, the tension between all these departments was at a very high place at the time, which affected the relations and communications in the whole company, which was also a big issue at the time.

[00:06:52] So what was good back then? Even back then we had a somewhat good culture and good people coming into the company. Even though there was a lot of tension, most people stayed. Some of the clients were quite happy because they got their features, but a lot of them weren't. And of course there was a lot of room for potential and for building this company into something better, so that's also a good thing. What's surprising to me throughout our history is that even back then, when you look back at it, we had almost zero percent churn. But I will get back to that a bit later as well.

The tech-driven years

[00:07:38] After some time there were some organizational changes, which led to a shift of power more towards the tech team, and our product development instead was quite tech driven for some time. The main reason for this was that we needed to do some major changes in our database and basic technology, and a lot of responsibility was put on the tech team for driving these changes. We realized that some other issues arose at this point. Opposite from before, we instead had too little focus on our end users and the clients. Paths were often chosen because they were technologically better for us rather than for the users. And the frustration between the development team and the sales team was still pretty bad. While the vision of implementing this new system was very grand, the actual short-term plans for implementing and developing were lacking.

[00:08:56] So what was actually good at this time? Of course we did some interesting things. Even the tech-driven things, working on basic things on our platform, in turn led to a more stable base for the product, with collecting and storing and everything like that. So that was something positive. Another thing that was positive during this time was that the development team tried different methods of development, like Scrum for instance, as a product development process. That didn't turn out to be something that we wanted to do; it wasn't a good fit for the company. But it was a good learning experience to take with us in building a better process, and this is something I understood when I talked to the team afterwards, but I will come to that later. And at this point in time the churn was still very low. That has been with us, like I said, from the beginning, and that's something that I will elaborate on later.

Lessons learned

[00:10:05] So let's move on to talk a little bit about what I learned from how we used to do things and how we do things now instead. First things first: making mistakes isn't really a problem in itself. If you don't make mistakes, you're not moving fast enough. But they become a problem when you don't learn from them, or don't change the way you do things and keep making the same mistakes all over again. What I want to share with you now is firstly the lessons I've learned from how we previously did things, and then I will also share insights on a few changes we made within our processes of product development and user experience development.

[00:10:52] What I found is that we want to build products for many users and not just a few. The previous way of doing things, when we did customized products for certain users, only led to lower overall customer satisfaction, so this is something that we will change. In doing this we also need to find the real customer need, the true customer need. The easiest way to do that is to talk to your customers a lot and find out what they want, but you need to focus on what's the need of the many and not just a few.

[00:11:37] Working with these needs, you also have to balance them with regard to your technological base and what you can do tech-wise. From the beginning we had a very sales-driven, not even customer-centric, design, and then later we had a very technologically driven design instead, but neither of those worked out that well for us. You need the balance between them to be more successful. At the same time, you don't want to solve all their problems at once. If you build towards too grand a mission and try to solve all the problems at once, you probably won't get that far.

[00:12:24] A super important point right here is that all teams are equally important for the success of your company, or at least for us, and because of that, all of them should have a voice, even in product development, I believe. We as a product team need to find out the needs internally, and what they have found when it comes to external needs as well, and we need to balance all of these opinions and find the best way forward for us as a company.

[00:13:02] To do this, of course, we need to communicate a lot, and this was something that we also found important for the company as a whole. Now we communicate a lot. The lack of communication only leads to frustration and bad cooperation between the teams, and as a result, the results of the company are also much worse than they could be if you don't communicate, understand each other and cooperate in a good way.

[00:13:38] The last of these lessons is that we tried a lot of different methods. I guess a lot of you have also tried Scrum or agile or waterfall or whatever, but what I found for us is that if you try to fit one of these into our development, it doesn't work. It's not one-size-fits-all. But it's good to try a whole range of different methods to understand their value to your own product development.

What we changed

[00:14:10] So what did we actually change in the process, then? Before going to that, I just want to say that our offering is quite complex, as I found out, which makes it even more important to have a well-structured development process and also a UX design process. This is to avoid, most of all, scope creep, doing too many features and not doing them well, and also to ensure that our products in the end are very user friendly.

[00:14:46] The first thing I did was quite simple. I sat down and talked to everyone involved in the process of product development, which in my mind now was basically everyone at the company, or at least a few people from each team, to understand what they would need from the process and also what they would need in terms of communication from us as a product team. This really helped a lot in filling out the gaps in the knowledge I had already collected about how we did things before. It seems quite simple, but it really helped me a lot and made the evolution of the new process much easier.

[00:15:31] Here are a few things we do differently, or look at differently, now than we did before, that have helped us grow a lot with our customers and produce better products. We consider ourselves a team of teams. I don't know if you've ever heard of this, but we're not a very hierarchical structure. We are very low hierarchy, and we want to keep this even as we grow. When we're 12 people, it's quite easy to hold on to that, but now we're approaching 40 and we're going to grow even more, so we really need to actively work on maintaining this way of communicating with each other and working together.

[00:16:13] Like I said before, we communicate a lot, all the time. We talk about everything. We try to involve everyone that should be involved at the right time. For instance, we involve our development team very early in the product research process, to make sure that we don't have to iterate too late in the process, and to understand what we can do technology-wise. And of course we even still have technology-driven development. We also include the whole company in product development a lot, doing workshops and understanding what they can contribute, and of course we involve our users early.

[00:16:58] So there's a lot of involvement of all different stakeholders, both internally and externally, to understand their needs earlier in the process than we ever could before. Even in product research, we involve our users, again in story creation, and again in the UX process and for testing and everything, so we understand as much as possible about our users and can build a better product.

Focus areas, lanes and smaller features

[00:17:25] A few more concrete things that we changed in how we do product development: we now have a few focus areas each quarter, so we're not spread so thinly with our resources, and we can also produce more content for our products, our features, our releases. We break down the development time into three different lanes. There's new feature development, that's all new features and products. There's maintenance, which is more basic things and also things that we need to be able to scale technology-wise. And then we have a research lane, which is more long-term. All of these are equally important, of course, but in different periods of time you might need to shift up on some of these, for example to release new features at a certain point in time, or to build more scalability. It's a very flexible system where you can move between them.

[00:18:37] How we manage to produce more features is also because we break down large features into smaller features, and in the end into stories. These smaller features allow us to release more things. We don't need to build everything to create value. We can release a few features and still create value for clients in a shorter amount of time. So we need to shorten the amount of time before we can produce something in our portfolio.

[00:19:12] The next step, like I said, is to use user stories, with the perspective of the actual user of the system, to describe how they want to use these different features and why, and then how they're probably solved. Of course the technology team is the best team to understand how we will actually implement it. But at the same time we iterate all the time. We throw things back and forth between the backend team, frontend and UX and product owner, and even back to the users themselves, to be able to produce products that will be used by the users because it's what they want.

UX in the product team, and an ecosystem

[00:19:58] At Mestro the UX designer is now part of the product team, and used to be part of the development team, and this has worked out very well for us. The collaboration between the product owner and the UX designer has worked very well, and I think it's also partly because we have a very visual kind of product. Sometimes you need to start with a sketch, sometimes you need to start with a user story, and it has been successful for us to have it this way. We also have a closer link to the end user in our product team, which is very nice, to have this deeper understanding.

[00:20:41] A big change in how we think about product development is that we realized that we don't have to do everything ourselves. There are a lot of things that our clients want and need related to their energy management work or sustainability work or something else that is connected to what we do but not really within our scope. Before, we might have been a bit scared to say to a customer that this is not within our scope. But now we've found another solution for that. Instead of providing it ourselves, we work closely with our collaborators, and we're building an ecosystem around that to provide value and services to our clients without having to produce or build them ourselves.

[00:21:33] I think this is a great way of scaling up, and I could have a whole talk just about how to build a network in the ecosystem and the value of that. But it's something I want you to take home with you today: focus really on what you do best, because that's where you will add the greatest value, and that's how you will be better than your competitors and provide the greatest value to your end user. For us it's many things, but for instance, having the whole chain from collection and storing to analytics and visualization makes us better at all these things. But we don't want to be too broad with the use of our data and, for instance, provide consultancy services or something like that. There are other companies out there that are very good at doing this, and we talk to them, and together we can offer greater value to our end users, and they will like us even more.

The churn mystery: customer success

[00:22:41] If you paid attention throughout, one mystery still remains. How did we manage to maintain such a low churn and have such loyal customers, even throughout times where the product maybe wasn't as good as it could have been? I will just give you two words here, and that is customer success. I can't stress enough how important this is for growing companies. They are your ears and eyes on the ground. I'm not saying this only because I was a part of this team before, but they really understand the pain points of the customers every day.

[00:23:30] And for the users of the system, or the clients themselves, they are a place they can go to get help when they don't understand how things work, and to feel safe that we listen to them and understand their pain points. We take in their ideas for improvements, and they just need to know that we are there for them. I think this is one of the main reasons that we managed to keep this low churn, and it's still a very important part of our business, of course. Loyal customers and low churn are among the most valuable things for a SaaS company, because then you know you can grow over time together with your clients, and they help you with improving your products, which in return helps them to do better work and get more value out of it. So it's basically just a win-win situation.

Closing thoughts

[00:24:38] Before I wrap things up, I just want to leave you with some thoughts to help you initiate a change of process, or whatever you're looking to do. The first thing is: reflect on how you do things, understand why you do them, understand what implications they have. The easiest way to do this is to talk to one another. Understand what the developers need to be more successful, what would help them be more focused. Talk to your customer success team to understand the pain points of the clients. Just talking to each other will help you so much. And in the end, of course, talk to your users, because they know what they're struggling with every day, so understanding their struggles will help you focus on what you should do.

[00:25:31] Which brings me to the next point, and that is to focus on what you do best. There are a lot of things you could do, but you need to understand what you are best at and then focus on that, because that's where you will excel and where you will have the most impact. There are a lot of companies doing a lot of things, so that's why you need to understand what differentiates you from these companies and focus more on that. And also, of course, don't be afraid to change things that don't work, and don't be afraid to try new things and understand what happens when you do it, and reflect on that, and then do this whole process one more time.

[00:26:19] I really enjoyed talking to you today, and I look forward to the further discussions we will have, and the questions you will have on this, and elaborating further on my thoughts on UX and digital experience and how to build a better product development process. Feel free to reach out to me anytime; you have my contact information here as well. But once again, thank you very much, and I'm looking forward to continuing our talks.