Interview: A journey to R&D Effectiveness with Perttu Nihti, Basware

Perttu (00:04): B2B software, everybody wants to see roadmaps that stretch out far into the future, depending on the situation and company, depending on how far, but typically, half a year, year, sometimes even longer. Again, we come back to the fact that all the stakeholders are pushing you to show more stuff on the roadmap. And even if everybody's roadmap always, it has a disclaimer, it's not committed. And essentially saying that you can't trust anything that's on it. If you do take something out of there, or if you do delay something, of course, there's going to be someone who's going to be asking that, "What happened?" So in a way that even as a mechanism is... It's sort of locking you in. Lauri (00:55): Hello and welcome to DevOps Sauna. Research and development organizations work most effectively when the culture, business model, and tools guide the organization towards a balanced and effective product development. Oh, that's a mouthful. What does that actually mean? What does it mean to combine culture, business models and tools effectively? What is R&D efficiency? What is wrong with it? And how to start solving it? We are joined by Perttu Nihti, chief product officer at Basware and Markku Nurmela, lead consultant in product and portfolio management at Eficode. Let's tune in to listen what Perttu and Markku say about effective R&D organizations. Thank you for taking the time. Perttu and Markku and welcome to the DevOps Sauna podcast. Perttu (01:53): Thanks. Yeah. Pleasure to be here. Markku (01:55): Same here. Lauri (01:56): How was your weekend? Perttu (01:57): Yeah, well, Christmas is coming. So some preps for that. Going still on the shops while you still can go to the shops. I don't think they'll go through a full lockdown here, but anyway, it's yeah. Mostly Christmas shopping. Markku (02:11): Well, it was a wet one with the dogs in the woods. No shopping for me. Lauri  (02:19): I got a concrete sample of time value of money. I was doing shopping as well. And then I had been given an idea of what to buy and then I was comparing the prices and there was a price difference, but there was also a difference to the distance from where I was to where it was available for cheaper. And then I was calculating like how much cheaper does it have to be for me to go pick it up from the other place. And this time, it seemed to be exactly the amount of discount. I was holding a package in my hand and I didn't know what it costs. And I thought, if it costs more than this, then it's worth going and getting it from the other place. And then I went and checked the price and it was exactly my reservation wage. So I saved some 15 minutes from driving around. Perttu (03:07): So that's your practical example of behavioral economics in action. Markku (03:11): You were relying that the goods are still there. They might have some trouble with the inventory. And there was none when you arrive. There's a risk. Lauri (03:21): Yeah, sure. That reminds me of this mathematical idea of optimal stopping. How many places do you have to check for inventory before you give up or something like that? Well, today we are talking about R&D efficiency and we are lucky to have you, Perttu, joining us. As a matter of fact, this is the second episode of roughly the same topic. So we had somebody joining our podcast, talking about R&D efficiency or R&D effectiveness, but they had a slightly different point of view. Their point of view was, how do you measure it? What are the metrics? And so on, so forth. Where, in our case, we're probably looking at more like a journey, how to get going with it, how to set things on the right track, and then how to go about doing it. I'd like to start by simply asking what is it? And what's wrong with it? Why does it deserve a conversation like this? Perttu (04:20): It's a good question. And I guess everybody can have a little bit of their own point of view on it. I'd say that the way I look at it is from the perspective of how much customer value can and is delivered from product development. So even if it's a bit of a cliche, but I would say that it really comes back to do you really focus at doing the right things, or are you focusing on doing the things right? And from my perspective, really the bigger lever is that first you need to absolutely ensure that you're doing the right things. And of course, there's always room to improve in your processes and in your efficiency and through good times. But ultimately, if you're focused on the wrong things from the beginning, then you can produce a lot of things without a lot of value, very efficiently. Markku (05:14): I have to agree with Perttu. Of course, I have a kind of product management background. So, while the key thing is to kind of have a good understanding before we start developing something. And as you know, things change during the journey and we don't know everything. But we have tools to tackle those things, but just having a good enough understanding on what are we going to do and why is it needed? I think that's the key. It's really hard to fix that later on. Lauri (05:47): Yeah. When we were preparing this, we were discussing about difference between push and pull. The basic concept was that whatever R&D should be doing, we should already know that it's important stuff. Perttu (06:01): Yeah. Yeah. And the way I look at it is maybe that through more, perhaps, a process view than strictly speaking, roles. So not so much focusing on, is it product management or R&,? but looking at it from the stages in the process. And I think you need to have enough capacity in the early stages of the process where you define, what are the problems that you want to solve, and then you start to take a more iterative approach, defining what kind of solution before you really then start the full product development or the R&D effort. And of course, there's iteration also in that, but it's just, the further you go, the more you're self- committed, right? And the more sort of some cost investments you have in place. Perttu (06:48): So from my perspective, I would say that it's... If you're going to do waste and ultimately you are going to do some waste, there's no way around that, you should do that early on in the process. I mean, fail early. That's what everybody's saying, of course. But it also then means that where you need to have the bottleneck in the process is actually further down the line. So you need to have enough capacity in the process. And again, there's going to be multiple roles working on it. So there's going to be product management and R&D and pre-sales, and sometimes, your delivery consultants or support or whatever, who are going to work with you in the early stages of process, but you need to have enough bandwidth there so that you can really, really make sure that once you start the sort of heavy effort of product development, then you're already pretty sure that you're working on the right things. Perttu (07:36): So to me, the product development stage... Of course, it always is a bottleneck and everybody understands it, but it really needs to be a massive bottleneck because if it's not, then what's going to happen is that you're going to rush the early stages in order to, quote unquote, feed the R&D. Feed the product development phase of it. And that's of course, one way to do it. You get a lot of throughput, you get a lot of output, if you do it that way. But the problem is that you're going to be in such a rush that it's going to be... You're not going to have the time to really do the validation well enough, early on. Markku (08:08): I guess it's somehow deep in our DNA that we should really start working pretty quickly with the solution. I guess this is partly our training or education that bring us solutions quickly. I fully agree with Perttu, and my point is focusing on the problem first and focus enough on the problem and have enough people focusing on problem from different aspects, because that's where the hard part is, understanding why is this valuable? Who needs this? What's the real scope? And so forth. And when that's done, then the development also is much, of course, easier. But then again, I think it's not that big time investment, but it requires that people who really know these things, they just gather together and kind of discuss things with the kind of good quality. And then go forward. Perttu (09:09): Yeah. And it's very tempting, of course, to zero in on solution pretty fast, because all your stakeholders are, I mean, if you work in product development, the majority of stakeholders are pushing you to zero in on the solution quickly, right? Sales wants to have something to sell very quickly. Customers want to know how you're going to do this thing. And they want to get it as soon as possible. Perttu (09:29): Product management, management included is sometimes pushing you to get the quick outcome. So that's why partially it's difficult, right? Because everybody's pushing for a solution and a quick resolution. And I agree with Markku. It doesn't have to take long, right? But of course, then it is often difficult to get that key, typically post functional stakeholders to really talk to each other. Typically you can do it pretty fast. If you could lock people in a room for a week, or even a few days, you could actually probably get to a fairly good experiment that you could then start to validate or even validate during that week actually. But it's just... It's in many organizations, that's a luxury that you actually do not have. And that's why they then tend to drag out in terms of calendar time as well. Markku (10:19): I guess it's partly our ways of working these kind of sessions for stakeholders and people who really can focus on what should be developed. That should be kind of pre-plan and calendar set for months and months before. Because if you try to do this before the sprint or whatever system are you running, then you typically don't have slots in calendar for important people. So this is partly a time management problem as well. Lauri (10:49): Paul Graham had a great blog post a long, long time ago. And my colleague referred me to that. It was labeled as a maker schedule and manager schedule. Which was basically the concept that when you are a manager, your week is split into 30-minute increments. And it's easy to do one more meeting because you view the world in 30-minute increments. Whereas if you are a maker, you view the world as a half-a-day increments. And if you put the 30-minute increment in between the half-a-day increment, then basically the half of the day is ruined. That's a good reminder when we work on this step of the process. Okay, let's find out something worthwhile doing, and let's do a quick experiment. Whether it takes half a day, if they get the piece of doing it in and a half a day, you get an incredibly high quality or incredible results in half a day only. Perttu (11:43): Yeah. That's true. And I think... At least what I see is that now during the pandemic, when we have got into hybrid, or depending on the time and the country, fully remote working for now, an extended period of time, I think actually it's gotten even a little bit worse. So there's a little bit more in terms of having these quick 15, 30-minute sync meetings, which, normally you would've done it at the water cooler, right? Especially if you're at the same office, there's a lot of interaction that has happened that you now realize isn't actually there. And there was actually a very interesting article in, I think it was in Nature. They studied the US-based employees of Microsoft over the first half of 2020. So time before the pandemic and time during. What they found out wasn't really super novel. Perttu (12:37): However, what they found out is that yes, actually, communication, roughly stayed because it was just replaced by other means. But what dropped off pretty much completely is the communication to different teams. So the communications within your team, they stayed up and down. That worked perfectly well. But pretty much all the accidental communication and all the communication to teams that you do not work closer with, dropped off. Perttu (13:03): And I think this has a bit of a connection also to this discussion because it means that... Like Markku said, you really actually... Perhaps now even more than ever, you actually need to preplan things in order to make sure that you have those discussions. And during the early stages of the life cycle, because none of it happens as a surprise, unless, of course, you're lucky enough to be at the office with some people. But I just pointed out like a few weeks ago, I was at the office and just bumped into some people from an R&D team and led to a discussion, which I would not have booked with them, but got some really good insights, over already in the market. But still, insights that I would not have gotten otherwise. Markku (13:49): That's really interesting because there was another study. What are people actually doing with the kind of saved time from commuting to the workplace? And it was kind of surprising at like 50% of that saved time, they will use for working. So they will do actually more work and they will do more work with their own team and less work with the other teams. So I guess if we don't pre-plan the interactions or kind of make changes to ceremonies between teams or however this kind of change of information can be handled, then things will actually get worse. So this is something we should really kind of put really some focus on this kind of serendipity or how you interact with your colleagues in not so formal way. But that's a really important way to change the information. Lauri (14:48): Yeah. When we were preparing this, were discussing about what are the best ways to approach the R and D efficiency problem. Some of them probably have shown their class during this special time, but I believe that some of them are, let's say, evergreen stuff that they are always true. Maybe we should look a little more closely into those, let's say, three methods to apply when solving the problem in the R&D effectiveness. And I think you are touching on so many points there that, to prompt you to dive a little more closely into those. So you listed number one, which is, be close to a customer. Then number two, being joint-high-level process across teams. And then number three was portfolio metrics and transparent prioritization. Should we start with the first one getting close to customers and then take it from there? Perttu (15:46): Yeah, sure, absolutely. So, of course, again, sounds really obvious, right? If we said that you need to focus on the right problems to solve, and probably it makes a whole lot of sense to have a chat with your customers. So that's not really like a completely new idea. However, I think, again, probably, like many organizations struggle from the fact that again, the calendars are really filled. Everybody's super busy. So what at least I found out, it's actually important to have some systematic ways of interacting with the customers throughout the development process. And this of course also includes internal stakeholders. Even if I don't necessarily call customers, but of course, if you are, for example, developing software that has a need for a lot of configurations and, for example, integrations, then probably the delivery consultants are one key internal stakeholder you need to keep in the loop. Perttu (16:41): And many times, the product management, especially as well as R and D, they're so busy during their day-to-day job that they do of course have interactions with customers, but it's more reactive. So unless there is someone facilitating in a way the more proactive ways to reach out to your customer, I feel that it's often not done enough, right. But if you have mechanisms in place, right where product managers are sort of, I have this idea. I need to also validate it. How could I do it? Where can I find the customers? If you have all that sorted out, right, and you have a place for that person to go, and then, in a way, a mechanism in place to do it, it makes it, again, so much easier. Perttu (17:23): And I think we come back to the fact, now things are a bit different and I think it's truly working more. And I think it's actually just even more important that there is someone who can facilitate this. You can call them customer focus groups or customer deep individual. Whatever, however you want to do it. But so that there is a mechanism in place and it can be a person who helps a product manager. It can be just one sheet of, okay, this is how you do it. Here are the customers who have expressed their interest, but something to help them along so that you just don't put the burden on it, on each and every individual themselves. But that says something like pre-thought to facilitate a little bit. Markku (18:08): As we talked, how valuable the time is that we probably should get more out of that kind of quality time with the customers and stakeholders as well. So that brings to me a couple of question about how we do things or how we going to define things. For example, are we speaking the same language. For example, this seems to be really a challenge even within the organization, but when we talk to customers, are we really talking about the same thing? So the language and terminology we are using, that should be, of course, familiar or shared with each party. Perttu mentioned in the very beginning, the word value. And that is somewhat of a challenge because value is, as a word, has so many meanings. Markku (19:08): It has so many different meanings for different stakeholders and customers. So when we have these discussions with customers, we should really have some kind of framework of our own. How we define the different value elements for ourselves. Because if we don't have that, and we are just using this ambiguous word of value, we don't get that much out of customers. So what are the real value elements? And how do they direct our kind of further development work? How do we prioritize? What's our product vision? That types of things can be then defined much more easily if we have a shared vocabulary. What are we talking about? And also this shared framework of value. What are we trying to solve for the customers and what do they appreciate? Perttu (20:08): Yeah. And that's super important, of course, also internally. So many teams have probably done it already, but what I've also found out is that, if you don't have the jointly agreed terminology, how do you even define value? How do you quantify it and use sort of consistently the same kind of frameworks and methods across the teams. It's really difficult then to enter into a good discussion in terms of how you should prioritize. Perttu (20:41): And of course, prioritization within a team, within a product area, when it gets even more difficult to support it, you want to do it across teams and across product areas, because then there's going to be even some differences that you do need to take into account, also. And for example, how do you then define the value in each? But I think that's something that, again... I think it's a journey. And I think you just need to put enough focus, also on that. It may not sound super important because it may sound a little bit bureaucratic, and you don't have to overdo it. But I think the basic things, should we need to have common between... At least a common understanding between the teams and individuals. Otherwise, it's going to be very difficult to have the more meaningful discussions. Lauri (21:22): Often, the B2B product managers start their sentence by saying, "Sales says this, and sales says that," and that can be available inside if that sales happens to be a person who also has a background as a practitioner who has been in the company long enough so that they actually have a reasonable sample of what the customer need is, but there can also be a risk confusing what sales says to what customer really needs. But I'd like to hear your thoughts about what you said, Perttu, getting the feedback straight from the customer, or getting a feedback through a proxy and what your experience has been sort of mashing up these two. Perttu (22:08): Yeah. I mean, of course it's always best to go direct to the source whenever you can. It's not always practical. It's not always even possible. And of course it doesn't scale as well. If you have a hundred sales people going to customers, of course, it's a really valuable pool of people with really good insights. And they have... You just need to understand that when sales says, then I think you just need to understand why are they saying it, right? And there can be multiple reasons. So I think sales is a really good source of competitor intelligence because they do come across tidbits that come from customers that some competitors have over these kind of things, which perhaps there is a gap in the portfolio. They of course go through a wealth of RFPs. Perttu (22:54): So they see what are the kind of things that customers are requesting for in the market. And then of course, depending on whether they're a hunter or a farmer or something in between, then they can also have really good insights to what your existing customers are actually saying and wanting. And then you just need to be very clear and understand that if sales says that we need X, right, then why do we need it? It's a completely different thing to say that, "But it's in all of the RFPs," and now we have to say no, and that's why it's really hurting us. That gives you an idea that, okay, it's being asked for in the market. It doesn't really give you any confidence that it's actually being used by anyone or even bought by anyone actually. Because it can just be an option that they ultimately don't even want. But it could be a hurdle, that you don't even get into the game if you don't have it. Perttu (23:44): So it's an important to have. If it's an existing customer, then you typically... Then you should pay a very close ear to what your sales is saying. And then definitely follow up and have the discussion with the customers, because then it can be either pointing out something which is just something that you just need to fix in order to, for example, increase your customer satisfaction and decrease your churn. Or it can be a major upsell opportunity, right? It can be even a big area which could actually grow into something very meaningful. And of course, as we all know, you know, doing more business with your existing customers is always easier than hunting for net use or that you should definitely keep a very close eye on. Perttu (24:25): And then if it's then something more generic, I would say that, okay, competitor has this and we don't. Competitors are always going to have something that you don't, right. So that's just the name of the game. And then you just really need to make sure that before you embark on anything, you understand that it is actually something which fits into your product vision and does actually bring value to your customers because the customer segmentation between you and your competitors can also be completely different. So I have to take that into mind as well. Perttu (24:55): But then I would say, of course... Then that I would try to be a little bit through, for example, interviews, or just get a little bit more mass behind that kind of Intel. Yeah, definitely, you shouldn't ever dismiss out of hand what sales says. I know sometimes, can feel that they're sort of, yeah, complaining or shifting the blame on the product for not selling enough, but there's very good insights coming from there. You just have to know what's what. Right. And you can't take everything that fails value. Markku (25:28): Maybe one thing I would like to add here is that, of course, the customer, they sometimes... Or actually they quite often, they look at the symptoms of some problems, but what's the root cause? Or why do they need this X? It might be actually the "why" they are looking for, and that's what, Perttu, you mentioned about the facilitating the discussion is really important because then you just... Maybe just don't accept the first answer that we need this X. Why do you need it? Markku (26:02): And this comes back to the understanding the problem. So why is the X important? So maybe there is some underlying reason for it, which is the kind of actual benefit or problem we should be solving. So that is the reason why there should be more time spent, even if it's sales or if a product manager or even developers discussing with the customer, just getting a better understanding. What's behind all this? Why is this needed? So that leads also to the proper documentation of customer understanding this. How do we document these needs? Who has them? How urgent, or how important is that? All the traceability of requirements, that type of things, that comes next, when you understand. Then you should just also document that as well. Lauri (27:05): That's very much in line with our second point that we were discussing, as we were setting this podcast up. Your point number two was joint high level process across teams to align cross portfolio work and focus on high value items. What does it really mean in concrete terms to have a joint high-level process across teams? Perttu (27:29): Yeah. To me, it just basically means that you have a defined product development process that of course needs to fit your situation, to choose form and adapt, but something which is basically just like a, and again, don't need to go overboard, but something that this is how we do product development around here, right? This is how the early stages work. This is how you analyze, define the problem. This is how you go into defining and designing more the solution and so on validate it. And these are the latest stages all the way to getting something that actually works in the customers' hands. Again, I think each company should pick the one which fits them the best. And then of course, be ready to continuously tweak it, because you might realize that, for example, you've gone overboard and made it Tuesday for... Or whatever. But some structures are good to have in place. Perttu (28:27): I know some people that say that, "no, no, no, no.", but it's just like, everything needs to be like super agile. Just do everything. That can also work depending on the setup. But typically, especially in B2B software, we have a lot of dependencies between the different products or the product components. Then you do need some kind of structure there to manage that. And then just defining that obviously together with the people who are actually doing the work is, otherwise, you are for sure going to be defining something which nobody wants to use. It's a journey to get it into use and start to adapt it so that it is actually a fit for purpose. And that can take easily a year before you are, you want to be. Depending of course, again, where you start from. But if you don't have anything joint in place, it can take a bit of time. Perttu (29:09): And, many companies don't have, because maybe they've done some acquisitions. So maybe they have teams working on different tech stacks. Maybe they have teams working on completely different methodologies. So it takes time to then bring all of that together and start to speak to the same language. Again, if you need. If you don't need to, if you have a situation where you have completely independent products in the portfolio, and of course, you don't necessarily have to do all this, but if you have a portfolio with dependencies, then you do need some level of alignment. How much? That of course is then up for debate per each company. One thing about this, which I think we haven't touched on too much yet. I think Markku mentioned it. But something that I also find sometimes a bit, let's say, difficult or even misunderstood in a B2B context, it's the concept of the Minimum Viable Product. So of MVP. Perttu (30:00): There are a lot of talks about MVPs. Yeah. Let's have an MVP approach and let's do an MVP, but then many times, if you really take it literally, and really try to do something, which is both minimum and viable, meaning that you actually get your customers to use it. And especially, if you work with larger enterprises, the hurdle of that can be pretty high, right? So the minimum can actually already be a pretty substantial investment. If you go down the route of starting to develop something, which I know is not the only interpretation of that, but it is often the one that people do. But Markku, we're using more of this across different companies. So what's your take on this? Markku (30:42): Well, I witnessed what you said a lot, that the MVPs somehow always defined as some kind of product version or even the first version of the product, which it should not be. It can be of course, some set of features you want to experiment. Are these valuable enough? Or have we understood the problem correctly? Or is the usability of this thing we are planning to do good enough? But then again, there's a lot more we can do with the MVP concept. I see it's some kind of well spent time and money for learning. And that's what it should be. So depending on what are you trying to find out, the MVPs can be totally different. You probably don't have to develop anything at all. You could just do some other way, or find some other ways, how to test your assumptions or to test your ideas with the customers. Markku (31:46): And I think we, as product development companies and people working in product development teams, they should use much more time on figuring out smart experiments. Cheap and... Well from money and time wise, but also kind of somehow when you learn something new, because that's kind of the fundamental concept behind the MVPs. How can we learn something quickly and in a cost-efficient way. And that's where we should also look alternatives, which it's not always, we develop something and try it out. We can use... We use other methods for MVPs as well. Markku (32:32): But then again, it requires a bit different mindset. It requires a bit different skillset. One thing I've seen that works well from a competence development perspective is that we just give developers some basic service design skills because that they are not that hard, but they help, especially, in this kind of documenting and understanding the customer problem from a bit different perspective. Who has the problem? Are there alternatives to kind of solve that? How do we document that? And then all that... What is the kind of... If the user experience is, well, that's involved in everything what we do nowadays. So how can we impact that? And there are a lot of other things than just software, for example, which has impacts that those things. So kind of building up or improving the kind of general knowledge of these things among developers is really good investment in from my perspective. Lauri (33:50): It's Lauri again. To succeed today, you need to make the most of Agile practices at scale. A successful level of transformation starts with enabling the leadership team and up-skilling every role throughout the organization. Successful change at scale relies on the team's capabilities and tools. Many teams have also found the recipe for efficiency by adopting a managed services approach to software development tools. You can find links to our training and managed services offering in the show notes. Now let's get back to our show. Lauri (34:31): When you are exploring a need in the market, you can start by Google advertising. You just put $500 on Google ads account and start playing around with different ads, and see what kind of proposition works. You don't even have to do it under your own brand. You can fabricate a company name because you are testing... Simply testing, is there a demand for this? And if you take it to the extreme, it's not my idea, but the idea was that you don't even need a website. Or basically you need a website so that you can read error logs, what of the pages people were trying to reach, but you don't need to have those pages available because only thing you are testing is whether people ever try to reach those pages. And I was thinking from a B2B, especially, in a SaaS software perspective, why not do the same in B2B SaaS software? Lauri (35:20): You conjure an idea that this functionality could be helpful. And if you know your user personas, and if you know how your software is being used, just add a button in the UI. And all what you're doing is observing as to who clicks that button. And maybe that button doesn't do anything, but only thing you want to find out is does anyone even pay attention? And then you can start at the second level. Okay. It seems like people are pressing the button. How can we get their input? Like, what do you expect this button to do when you press it? And so on, so forth. And then you can start to bring the first functionality and things like that. But it sounds like a radical idea to start messing around with your customers or users' expectations, but just putting it out there as an idea. Markku (36:04): Well, that's the famous fake door. We've talked with several customers. And they are always terrified. What? There's nothing behind the fake door. But you can actually make all sorts of things. What happens if the functionality is not there and if you just run that experiment like a week or two or something like that, then it's not that dangerous. But as you mentioned, you can get really valuable input of people even considering this is something worth value. Markku (36:37): But sure, there are other ways to do this as well using really cheap methods to do that time and money wise. But then again, as you mentioned, usually if you are an established company, you have some brand things you have to keep in mind that you... What kind of experiments can you run with your existing customers? Then there are some things you probably should not do, at least not with your own brand. But still, I encourage everyone to think about innovative methods, how to do that. It's doable. Certainly it is. Lauri (37:16): How do you practically build the balance between, we know what needs to be done, and now let's go do it, and we don't exactly know what needs to be done, but we'd like to find that out? And in order to do that, we need both of us. It's not a matter of product management. It's not a matter of R&D, but it's this joint process across those teams to find that. Perttu (37:39): Yeah. That's a difficult one because, again, I think in many setups, you are extremely busy and booked. Just churning out the roadmap that you have in place, which then means that even if I said at the beginning, that the idea is that you have a lot of capacity to spend at the early stages, in many times the reality is that you don't. So and then you do fall into this trap that you actually just... You don't do enough of the validation at the early part. And you, for example, don't take R&D along into the very early discussions at all. Maybe you have an architect there, but that's the extent of R&D involvement at the early stages. And then you go down the path of something to actually, starting to develop something which perhaps then through iterations, you do get that joint understanding. Perttu (38:35): But I have witnessed and have experiences also of cases where that actually hasn't taken place. And then ultimately, you know what has come out has been something which, lack of a better word, wasn't really fit for purpose. And of course, you have the beauty of being stable. Of course, you can then adapt it and correct it. But perhaps by doing a little bit more of a joint iterative process, then perhaps it could have been more right the first time. I mean, you always find out something, right? You're never going to... Hardly ever, you're going to need it on the first go. The question is like, how much do you need to then adapt after that? Lauri (39:19): Yeah. Maybe the actual epic planning or planning of the epic and who gets to be there versus the prototyping and MVP who gets to be there. Maybe that is, or that certainly should be different. Markku (39:35): This is maybe a heretic thought, but maybe I say it aloud anyways. So I guess that maybe one of the kind of biggest reasons why the teams don't have time for try something new is about the backlog is all already full of things. They're like three hundred items waiting to be done and so forth. There are some kind of new type of approaches, which tries to kind of get rid of that kind of burden of history. We don't know why that... Some of things are there and we don't know just why are they there. Who asked them and so forth. And are they valuable anymore? For example, because some time has passed and maybe needs have changed. We should, at least, time from time, maybe once or twice a year, just trying to kind of forget that history and start from kind of fresh, clean slate, and try something new. Markku (40:37): And maybe, just make time, because time management is also about making time for new things. So why don't we just take some pre-planned time to do something new and experiment and just, okay. There are things that needs to be done anyway, but maybe for this sprint or whatever that you are using, or system you're using, we are kind of taking a fresh start. And do something else, because the backlog will never be empty. As Perttu, you mentioned. It should be a battle kind of a bottleneck in that sense. But from time to time, we just could forget what's in there and try kind of fresh approach. Just a thought. Perttu (41:24): Yeah. And I think that goes hand-in-hand with thinking that, as said, you need to have more capacity early on. And it's not about the roles, right? It's not about having more product managers versus R&D. It's about where do the people spend the time. And of course, if you have a full backlog, let's say you've loaded your backlog for the next, a few weeks to a level where, you're running at 90% capacity, then it's pretty clear. You don't have any time. You don't have any time then from... I mean, first off, you're probably not going to even complete it because it's so high that you can't any more adapt to any of these surprises that come along. So there's probably going to be something more urgent coming and you switch the backlog, which is fine, of course. But at least don't fool yourself that you're going to complete all that work that you've planned out for the next few weeks. Perttu (42:21): And of course, the people will not have time to work on anything new because they will be working on exactly the things that are in the backlog. And I think that's exactly the trap where it's super easy to fall, right? B2B software, everybody wants to see roadmaps that stretch out far into the future, depending on the situation and company. Depending how far, but you know like, typically, half a year, year, sometimes even longer. And it's... Again, we come back to the fact that all the stakeholders are pushing you to show more stuff on the roadmap. And even if everybody's roadmap always, it has a disclaimer. It's not committed. And essentially saying that you can't trust anything that's on it, if you do take something out of there, or if you do delay something, of course, there's going to be someone who's going to be asking that, "What happened?" Perttu (43:11): So in a way, that even as a mechanism is... It's sort of locking you in, in a way. Not obviously to very detail, unless you've made the mistake of having extremely detailed roadmaps. It doesn't really lock you into very specific details. But still, even on a high level, there can be so much things there that it's sort of locking in a major chunk of your free capacity. Because again, you always have the maintenance. You always have the surprise to come in that you need to ingest. You'll always have this stuff that's not even visible on any external roadmaps because it's maybe, it's refactoring or I don't know. Overall performance improvements, or fixing some security issues or whatever it is. Perttu (43:55): So if you're not careful, that's what's going to happen, right? All the stakeholders are pushing you to commit to more and more. You're trying to commit to less, probably. But it's also very tempting. Then people have... They have high ambitions. They want to see their own product or own product area grow. So it's even, actually, not that uncommon that even the teams themselves overstretch and overcommit. And then it's a vicious cycle after that. Markku (44:23): I think one, maybe, reason for that is, well, we are not talking about measures today and it's fine. But I guess measure is measurements and measures are one kind of a reason that we somehow are so out-oriented. Because that's something we can measure. Measuring the value is much harder, although we should aim for that. But as you mentioned, that roadmaps and kind of the development... The available capacity for development, that's kind of somehow poorly understood, people outside the R&D because the, as you mentioned, there's so much things that are not visible and still needs to be done. Markku (45:16): So how much capacity you actually have for developing something new? It could be something... It could be 50%. If you are lucky, it could be a lot less. And understanding this from a management perspective requires some good, good knowledge and maybe experience with the actual product development. But maybe that's a kind of a discussion for a topic for some other discussion. Then again, we come to the priorities and big things, like big problems and all that type of benefits. What should be driving our development and how can we find those out? I think that's a key thing. And then that comes back to using enough time with the problems and with the customer needs. Perttu (46:07): Yeah, I think we're very output focused in the metrics in many places. Partially because it's easy. So again, especially if you work in Software as a Service world, and you're bound to be doing quite a bit of product development, which does not end up as a new sellable module. Meaning that it does not end up as something which is separately priced. And then you can, of course, quantify the value early on and all that. But following up and really understanding the value, for example, of a given set of new functionality that you have put into a release. Of course you can follow up on how your customers are using it, which gives you some idea. But if you really want to get to what sort of the hardcore, your CFO is asking like, "Why did we spend this much R&D on this thing? And what did we get out of it?" Perttu (47:03): Answering that is extremely difficult because there's so many other factors that are going into that. And of course, if you can have that discussion, that look, our churn metrics are going the right way. We're bringing in new business. We're growing at a comfortable rate both with existing customers and selling to new customers. And our win rates have improved. And if you can then just like have that discussion and say, "Look, this is an indication that when we look like over the longer term, we're doing the right things in product development." I think that's one way to tackle that. But it's extremely difficult if somebody really starts to pinpoint and say that, "Look, we spent a hundred man-days on this particular thing. What did we get out of it?" And then you're very easily on the, "Yeah, well, we got this new shiny button, which our customers have been pressing on average X amount of times," discussion, right? Because that's the easy thing that you actually can bring to the table. Lauri (47:56): Nowadays, people know the price of everything and value of nothing. It is probably easier to calculate the cost of R&D than the value of R&D. And that's why this conversation exists. Question to Perttu. Now, when you think back your journey, where are you today in this? And what's next ahead of you? Perttu (48:18): Well, I would say that we are on the way. So we spent quite some time now over the past year or so, developing a common product development process and starting to use the same terminology and tools and frameworks to discuss value. And we've set up... We have actually set up the kind of practices to have a joint way of this... We're approaching customers and having really well facilitated customer discussions in place. In addition to, of course, all the sort of day to day normal customer discussions that we have from product management. Perttu (49:02): I think we've learned perhaps something along the way, which is that we... Little bit depending on who you ask, but especially, initially, I think we went a little bit overboard in the process definition side of things, which we now, since then, adapted based on the feedback. Even if we did define the process with the people who are actually living it still. I think we went a little bit overboard. But I think what's good is that now people are starting to speak the same language. Perttu (49:33): We've been able to bring transparency to internal stakeholders. So for example, sales, pre-sales, to explain to them why have we decided to work on the things that we're working on, why have we not started some of the other great ideas that are there. So basically, have a joint discussion about forced ranking. Also the very early part of the development life cycle, which I think is very valuable because it reduces finger-pointing across different teams, which can easily happen if people don't understand why you've made choices you have. Yeah. So I think we're on the way quite nicely. Still, I would say there is room to improve. And I think next, I would say is that where we can also put a lot more emphasis going forward is to then ensure that our customers get the full benefits from both the new and the past product development investments. Perttu (50:32): So even if you are focusing on the right things and building things which have great value, unless you really finalize also the last mile of things, what's going to happen is that you're not going to ultimately get that value into your customers' hands. And I think it's a couple of things. So first off, just like driving the customer adoption more, and that's where you can work with your, again, your internal stakeholders or your professional services or consulting slash delivery slash customer support. Customer success managers are of course, really key, key people in this to make sure that your customers are taking full benefits of what you have been delivering. Perttu (51:11): Then for new customers, I would say really, again, the same internal stakeholders plus then really focus on improving sales enablement, and making sure that your sales is always really up to speed. Both in terms of the latest that you've developed, but are also really the core value promise of your product portfolio. Because what's often overlooked is that there's quite a bit of turnover in a normal B2B. Especially if you look into B2B SaaS companies sales people. There's quite a bit of turnover in sales. Perttu (51:43): And it varies by company. But it's not uncommon to see double digit numbers there. So and if you are in high level digit numbers, it means that you have new sales people coming in all the time. And unless you have a really efficient way of onboarding them and keeping that message fresh and repeating it enough, you're not going to be able to get them to stay quickly enough where they can really communicate value to your customers. Lauri (52:08): What advice do you have for people who are in the beginning stages of their journey, now that you know what you know? Perttu (52:15): I would say maybe just take enough time to analyze the current state of affairs. Meaning that there's probably room to improve in a whole lot of places, right? That's typically the situation and a bit ironically, as we've discussed. Like if you jump to quickly to the solution, you may not be working on the thing which has the most value internally, right? Most value in how do we improve your operations? So perhaps we should have done that as well. That just take a little bit more time, really analyze and discuss where you are today and what are really then the biggest levers? What are really then the biggest levers to pull in order to get the change? Now on a very high level, I think, still, it's very, very possible that it is in the realm of doing the right things versus doing things right. Perttu (53:09): But there's so many elements related to that bigger theme that you should still spend a little bit of time to understand that, okay, well if it's that, then where do we really, really need to focus? What is really the problem that we want to solve first? And then start to perhaps map out, again, to use the same product terminology: Some kind of a roadmap, a sequence of things that, okay, once we have addressed this problem, then let's move on and start to fix this other problem area and not try to introduce too much change at one goal. Because that might then also disrupt the way you're... Markku (53:41): We know pretty much what needs to be done. So that's the kind of good news, I guess. The past few years or the past decade, I think we have been using a lot of effort to improve our factories. So get our throughput up. And I guess now we should really concentrate on the problem side, and what really needs to be done. So my two advice actually are pretty simple. So make time for this kind of analyzing and the problem, and understanding the customer. Well, that means that you have to do something less because we don't get more time unless we do something or leave something out. So make time for this, what Perttu mentioned, understanding the state of affairs pretty good in the very beginning. So that's one part. Markku (54:47): And that means that we do less, but hopefully better. Another thing which is already available today is just to get benefits from new type of tools that helps understanding the customers documenting the problems, documenting the scope we are doing, designing the customer experience and all that type of stuff. So story mapping, new prioritization tools, visual thinking the old customer personas. Those things, I think the tools are there. We just have to get used to those and also educate all people involved in product development and sales as well with these new tools. So that's my take on this. So make time and take advantage of the tools that already exist there. Lauri (55:44): That is to the point. The advice I got from somebody who founded their own company in the 50s and 60s. And built a basically a reselling chain for a specific industry over the next 50 years. And when I was 15 years, he told me that entrepreneurs need a lot of time and good tools and nothing really have changed in those 50 years. Markku (56:10): Good advice. Maybe the tools have changed, but you'd still need them. Lauri (56:15): Yeah. Thank you, Perttu and Markku for joining. This was a wonderful conversation. Perttu (56:20): Yeah. Thanks. It was a pleasure. Markku (56:22): Yeah. Thank you. Lauri (56:24):