How to Choose Tools Your Product Team Will Actually Use

Read The Transcript:

We're trying out transcribing our podcasts using a software program. Please forgive any typos as the bot isn't correct 100% of the time.

Hannah Clark: Quick, without counting, can you tell me how many logins you currently use at work on a weekly basis? If you don't know, hit pause and try counting. I bet the number is shocking. In fact, a 2024 report by CloudZero found that the average employee currently uses 36 cloud-based services per day, and engineering teams use twice as many.

Crazy, right? And here's another crazy thing that probably won't surprise you. According to CloudZero's 2023 study, over 53% of SaaS licenses go unused. In other words, despite our org's constant need for tools to support our unique operations, we are wasting a ton of money on tools that, for whatever reason, just aren't fitting.

My guest today is Moshe Mikanovsky, founder and lead product coach at Products for Good and the co-host of the Product for Product podcast. Having worked in product and software engineering since 1989, a major focus of Moshe's in recent years, is helping product teams make better decisions around the tools they choose to implement.

Of note, Moshe has developed a comprehensive framework to help orgs choose the right tools for their needs, thereby increasing adoption and productivity while reducing wasteful spending. We discuss some of the highlights from the framework that can help you choose better tools starting today. Let's jump in.

Welcome back to The Product Manager podcast. I'm here today with Moshe Mikanovsky. He is the founder and lead product coach at Products for Good.

Moshe, thank you so much for joining us today. 

Moshe Mikanovsky: Thank you for having me, Hannah. 

Hannah Clark: So we'll start off the way we always do. Can you tell us a little bit about your background and how you got to where you are today?

Moshe Mikanovsky: Yeah, I started as a software developer many years ago. For the first 20 years of my career, I was working on the engineering side. I was lucky enough to work for small organizations. Or at the field, actually working with clients and with users. So I think I developed part of my empathy to users and what they need.

Back then. And then after 20 years, I decided to move to product management. This is what I'm doing for the past 14, 15 years. Really love doing that. I love talking about product management. I love helping other people build products. And see, what's out there, what works, what doesn't work, learning new methodologies.

So everything about product, it's part of what wakes me up in the morning. 

Hannah Clark: You're in good company here. 

So today we're going to be talking about something that I think is of interest to everybody, which is tools. How product teams can make better decisions when selecting tools for their organizations. A chronic concern. And this is also a major area of expertise for you. What initially inspired you to create your product selection framework that we'll be talking about shortly? 

Moshe Mikanovsky: Yes. So I have a podcast that I co host for four years now with my friend Matt Green. It's called The Product for Product.

And on the podcast, we are basically covering tools that product people are using. That was always an interest of both of us from different directions for Matt. When he moved into product management for me, just trying different products in the past and choosing products because no one else chose them for me and I had to do the work.

It's always really interesting to see, what is available out there. So that's what we're doing in the podcast. And from that, I realized throughout recording different episodes for different topics and different themed products, that there are some commonalities between why people are using specific products, what they like about them, what they don't like about them.

And things like that. So we always interviewed users of the products, unless it's a startup. And then, there is not a lot of users. So we bring the founder, but in most cases we interview users. So they already have. insight, knowledge about how it's used, what works, what doesn't work. And from that, I accumulated a lot of this reasoning and things to look for, which made me put it all in one framework that I love sharing with people.

Hannah Clark: In your experience, if we want to talk about some of the missteps that people make before we get into kind of the right way of doing things or a framework for how to do things, maybe in the best way for your organization. What are some of the most common mistakes that product organizations make when they're choosing new tools and what consequences did those mistakes typically lead to?

Moshe Mikanovsky: Yeah, I think that it's mainly about how they choose the tools and not looking into a better fit for the tool to their organization. That would be the first thing. And that's quite a bit what the framework is all about, but also not really understanding the tools before choosing them. It's a common thing.

We always are very excited about the new tool. We look for it. We see the different features that it can do. We feel, or we think it will fit our needs, but then when we start implementing it, we might see that it's not exactly what we thought it is. Or maybe we were looking only at the marketing information on the vendor's website, and it's not telling us the full story.

Or the demos were not telling us the full story, or there is different gotchas that we learned throughout doing it. So that's what I see many times, not the best fit for the organization and not enough understanding of how the product actually will work for them. 

Hannah Clark: Yeah, that makes sense.

All right. Then let's walk through your selection process. So the way that your framework starts out, you start by identifying problems and then there's prioritizing and shortlisting and then comparing tools. So quite a bit of pre work before you even get into actually the comparisons side of things.

And why is this preliminary work so important before you actually jump into comparing features? 

Moshe Mikanovsky: I think it's like any other product. I try to approach as product person for so many years, almost everything that I do, I try to approach as a product. So I did the same thing with this. Trying to understand what is the real problem we're trying to solve is really important.

So we don't want to build features for a solution that no one will use. The same thing, we don't really need specific features if there is no problem to solve for us over there. So the fact that everyone is doing something doesn't mean that you have to do it as well, or that the way that other people are doing it will fit how your organization is working.

So that's where really the beginning preliminary work before you even look at all the features is to understand what are the real problems you're trying to solve, to understand what is the work, what is the job to be done of your product team. So for which you need to choose those tools. And then what are the priorities between all of these?

So we know sometimes we cannot buy all the products right away. Sometimes even getting budget for one product is more than we can get. And therefore prioritizing what is really the biggest problem that we have right now, that, and maybe it's not always a problem, but it's. Something that takes us a long time to do, or there is a lot of mess and we need to clean it up or whatever it is.

And based on that biggest problem to prioritize that and say, okay, this is really the thing we need to look for first and then creating almost a roadmap for your choosing of products and implementing them eventually. 

Hannah Clark: Okay, so I want to talk to you a little bit about something that's interesting about the process that you use for comparing tools, which is product philosophy, which is the first criterion here.

Okay. First of all, what do you mean by product philosophy and why does this matter? What are the differences in philosophy really look like and how does it impact the tools fit for an organization? 

Moshe Mikanovsky: Yeah, one of the things that I noticed throughout talking with people, and it was also my own experience and my co host Matt's experience, is that we're not alike with the way we like to work, with the way we like to communicate, with the way we, what we are emphasis on different things.

And that's where I put under philosophy. So for example, Some of us really want to have one product that will solve everything. And all the different features that we need will be there. We don't need to implement anything else. But we know many times that such products don't go very deep in each one of those features, but they go very wide.

Where others, their philosophy is, I want the best of the best for each specific problem that I have. I do want it to be integrated. So everything is talking with each other, but that adds to the complexity of the solution as well. So that's just one example of a philosophy where, what is it really that we are as an organization?

And sometimes it's hard to define if you don't know how your organization is working, who's making those decisions, but it's important to look for this information because this will help you nail into a specific product or a selection of shortlist your product. Another one of these philosophies is whether you want the product to be flexible or deterministic.

So some products will give you the option to create any workflow that you want and define any field that you want and whatever, but that's very sometimes generic, but flexible. I will, I'm using that word. So each organization will implement it in a bit different way. And some products in the same category could be very deterministic when they can tell you, no, you have to work this way.

So we only build it that way. I'm not saying one is better than the other. Sometimes it's a stage of the organization, not so much how early they are, building a product, but it's more about their maturity, how mature they are. So for example, if they don't know a specific. Way to do, I don't know, sprints and to do a backlog grooming and all of these things, and they get a product that is deterministic about it, then it will teach them the process.

But it will only teach them in one way where there are many other ways that it could happen. And maybe once they are more mature, they will be more comfortable using another product that will be much more flexible for that. So these are some of the the items that I'm looking for that are part of the framework to, even before you look into the future to see, what is your culture, what type of products are better fit for you, et cetera.

Hannah Clark: Okay. And speaking of flexibility, there's another criterion I want to grill you on a little bit, which is The factor of ongoing engineering required. So this is an interesting one. So how should teams evaluate the engineering resources that are needed to integrate different tools and how might that kind of correlate with the long term success of that product?

Moshe Mikanovsky: Yeah, this is also going into some type of philosophy, my philosophy in building products in general, for my own company that I work for, or when I consult other companies. is that our engineers should really focus on the added value that we're creating and not reinvent the wheel with many things that millions of other developers already developed in the past.

So in the same way, when I add features to my product in app messaging or like product analytics, which are all. Existing in those tools that we, we have these days, just as an example. I'm just taking this as an example. I don't really want my developers to worry about these things. I prefer them to integrate it once with a very simple integration and kind of forget about it.

And then give me the product manager or other people outside of the engineering team, the abilities to define whatever we need to define in order to. Get the most value of this product, but some products in the same category for enough messaging and for product analytics actually do require engineers on an ongoing basis, because sometimes you will have to define for them events to raise or how to do to define the look and feel of your enough messaging or whatever that is.

And to me, and again, this is a personal thing for me, so I'm not saying it's right or wrong. But to me, it's a waste of time of the developers. I prefer they work on value that is unique to our organization. 

Hannah Clark: Okay. So speaking of company values and some of those more unique things. You've mentioned also the cultural factors like company values and communication styles can also impact tool selection, which I think is really interesting.

I would love to hear a story of how that kind of works in practice, how these less tangible elements can influence which of the tools can be successful in an organization. 

Moshe Mikanovsky: Yeah, for sure. I can give you an example of a place where I worked and we had a really hard time with async communication. It was really annoying to me because we were working remotely and you will think that remotely, async is one of those things that help you collaborate better and That you don't need to be on regular meetings.

We had to be on regular meetings on all the time in order to move things forward. And we also chose to use like a backlog system. I think it was Jira, but in any of those systems, when you define your let's say your epics maybe in a confluence document and your stories with acceptance criterias.

You would expect people to go through that, to read it and collaborate on the comments on some way of asynchronously work together. And it just didn't work. And every time that people would tell me, Oh, I didn't see that, or the way they open it up in meetings, I was like, but we had all of that in there.

That was a cultural issue that was impacting how useful our usage of the products were. And I was sometimes feeling I'm swimming against the stream. I had to do a whole session just to tell them what the async communication are and what's the importance of this. I don't remember if it even helped or not.

So that's what I'm talking about. And it's just one example of how your organization is working. And a tool is not going to fix that necessarily. A tool can help you be, make your communication better. If you put the efforts in actually using it, a tool can help you make your processes better if it works for the way your organization work.

And usually not the other way around, even though it could help modify how companies work. But I would first look at, what are the cultural constraints that you have and then fit the tool to that. 

Hannah Clark: That makes a lot more sense. 

Let's go back to feature comparisons now that we've talked about some of this pre work and some of the factors to consider before we're getting really into the nitty gritty of what the tool has to offer.

So many teams obviously jump straight to feature comparison and pricing when evaluating tools. You mentioned that earlier. Why are these factors so late in your evaluation framework? 

Moshe Mikanovsky: Mainly because I don't want people to look first into the outputs of what they can do with the product they're using, but more of the outcomes that they're trying to get from that.

Features are probably the easier thing to compare. And also organizations will tell you that they have this feature and this feature. But when you look into the details, Which sometimes will be published, sometimes not. So you have to find it yourself. You will find out whether it is really the features you were expecting.

Sometimes they will use different terminology for that. Sometimes they will use very different pricing for different features that are available. Which is all fine, but most of the time it's up to us, the consumers, to really pick through all of that, all of those details to find the right product for us.

But again, I think the most important thing is that we want to have outcomes. oriented selection of the tools and implementation of the tools versus just outputs. I can do this and I can do that, and therefore this tool is better than the other. 

Hannah Clark: Okay, so I want to get into maybe the most frustrating component of implementing a new tool, which is getting everybody to adopt it and getting everyone on the same page with how to adopt it as an organization.

Especially after you've done such extensive work, trying to find the right tool, make all these adaptations consider all these things to make sure it's the right tool for you, you still have to get people to use it and use it the same way. So what are some of the key strategies for ensuring successful adoption across an organization?

Moshe Mikanovsky: Okay, so the first one is selecting the right tool, or at least the least unfitted tool that you can find, because there is always going to be things. The second thing is the selection process. It's a tough one. It depends who owns it, what the governance on the ownership and the selection process is going to be.

And you could have naysayers even from that time. So right now I don't have a specific recommendation. It's something I'm thinking about and I will probably extend the framework a bit in the future. When I get more information also from other people. Because if you have many people in the selection process, first of all, it can take very long to select and the second, do you have consent or do you have consensus and that's another cultural thing in the organization and then who owns the product, not just from the selection perspective or implementing it, how many times in the past, historically.

IT was owning products in the organization because it's a software and you have to install it on a computer. So IT will own it. But then they will not really care much about is it really successfully implemented or not. So you always needed another champion to implement it. So ownership of that is important as well.

And these days with product ops, it might be an easier job for some organization if they have product ops, because I see it sitting quite nicely within product ops, especially if you want to standardize it across the organization. And then they can. understand all the needs of all the different teams and they can understand, what are the differences between them?

What are the difficulties to implement them and to really use them in each team? Because those could be personality issues. It could be project constraint issues. It could be many different things. And like any other product, the same way that, some of us have to work hard for our product to be implemented properly at our client sites.

And, this is a B2B product. All of the products we're talking about are B2B. So if you are developing a B2B product, you probably know what I'm talking about. And you might have more empathy towards that as well. If you are not building B2B products, you might have some disconnect there. It's not easy sometimes.

Depends on the size of your organization, how many projects you have, how many products you have, lots of different things involved, but I would say overall is like who makes the decision, who owns it, what type of governance you have, how people are actually. Accepting those decisions and then moving it forward, even doing iterations, so you don't have to implement all of it right away.

You can try different things and then iterate on it like you would with any other product. 

Hannah Clark: Yeah, that makes sense. Yeah, having an onboarding process that's a little bit more staggered. At least you have more access to your users in this situation. So that's an advantage. 

Moshe, thank you so much for joining us today. This has been really informative. I think it's been really helpful because we're all at a point at some point to select new tools and the whole process of implementing them can be a bit of a journey. So we really appreciate your guidance here. Where can people learn more about this product selection framework that you've developed and connect with you online?

Moshe Mikanovsky: Yeah. So first of all, my pleasure and thank you for having me. Everyone can connect with me on LinkedIn. You can find me with my last name, Mikanovsky, and my website is productsforgood.co. I have the framework as a Miroverse board. So it's published on Miroverse. I have a link to that on my website under resources.

But also I will share it with you so you can put it in the description of the episodes, more than happy for me to share it with everyone. You can copy it and start using it. There is explanations over there. There is a lot of resources inside the framework, like Airtable, list of products with some categorization.

It's still a work in progress because there is always new, I always find new products, if there is something missing over there, by all means, please contact me on LinkedIn and I would love to hear from everyone. 

Hannah Clark: Yeah, we would be so excited to share it and yeah. Thank you so much for all the resources and for your time.

Moshe Mikanovsky: My pleasure. Thank you very much, Hannah. 

Hannah Clark: Thanks for listening in. For more great insights, how-to guides and tool reviews, subscribe to our newsletter at theproductmanager.com/subscribe. You can hear more conversations like this by subscribing to The Product Manager wherever you get your podcasts.