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 Cloud Zero'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 Michinowski, 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 Moshia's in recent years is helping product teams make better decisions around the tools they choose to implement.
Of note, Moshia 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 Moshia Mikinowski.
He is the founder and lead product coach at Products for Good.
Moshe, thank you so much for joining us today.
Thank you for having me, Hannah.
So we'll start off the way we always do.
Can you tell us a little about your background and how you got to where you are today?
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.
Well you're a 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.
So, what initially inspired you to create your product selection framework that we'll be talking about shortly?
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 post -cast. From that, I realized throughout recording different episodes for different topics and different themed products, 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 interview users of the products, unless it's a startup and then you know there is not a lot of users, so we bring the founder, but in most cases we interview users.
So they already have inside knowledge about how it's used, what works, what doesn't work.
And from that, I accumulated a lot of these reasoning and things to look for, which made me put it all in one framework that I love sharing with people.
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 do those mistakes typically lead to?" 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 are always very excited about a 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 you 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 batches 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.
That makes sense. All right.
Well, 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 can get into actually the comparisons side of things, and why is this preliminary work so important before you actually jump into comparing features.
I think it's like any other product.
I try to approach as product person for so many years, almost everything that they do, I try to approach as a product.
I did the same thing with this.
Trying to understand what is the real problem we're trying to solve is really important.
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 is 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, 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, whatever it is.
And based on that biggest problem, them 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 product and implementing them eventually.
Okay, so I want to talk to you a little bit about something that's kind of interesting about the process that you use for comparing tools, which is product philosophy, which is the first criterion here.
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 in fit for an organization?
Yeah, one of the things that I noticed throughout talking with people and it was also my own experience and my co -host, Matt 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 philosophies, 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.
That's just one example of a philosophy where, what is it really that we are as an organization?
Sometimes it's hard to define if you don't know how your organization's 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 shortlisted product.
Another one of these philosophies is whether you want the product to be flexible or deterministic.
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 sometimes generic but flexible, I'm using that word. Each organization will implement it in a bit different way.
Some products in the same category could be very deterministic when they can tell you, no, you have to work this way.
We only build it that way.
I'm not saying one is better than the other.
Sometimes it's a stage of 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 sprints and to do backlog grooming and all of these things and they get a product that is deterministic about it, then it will kind of 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 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, etc. Mm, okay and speaking of flexibility, there's another criteria I want to kind of grill you on a little bit, which is a 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?
Yeah, this is also going into some type of philosophy.
My philosophy in building product in general, you know, 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 like in -app messaging, or like product analytics, which are all existing in those tools that 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 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 I actually do require engineers on an ongoing basis because sometimes you will have to define for them events to raise or how to define the look and feel of your enough messaging or whatever that is.
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.
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 tools can be successful in an organization.
Yeah, for sure. I can give you an example of a place where 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 all the time in order to move things forward. We also chose to use 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 the acceptance criteria, 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, you know, they open it up in meetings, I was like, but we had all that in there.
So that was a cultural issue that was impacting how useful our usage of the products were.
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.
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 and 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, you What are the cultural constraints that you have?
Then fit the tool to that.
That makes a lot more sense.
Let's go back to feature comparisons.
Now that we've talked about some of this freework 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 in pricing and evaluating tools.
You mentioned that earlier.
Why are these factors so late in your evaluation framework?
Many 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 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're 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.
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, 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?
Okay, so the first one is selecting the right tool or at least the least unfeated 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's 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.
You know 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, cause those could be personality issues, it could be project constraint issues, 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 the products we're talking about are B2Bs.
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 a B2B product, 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 who makes the decision, who wants 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.
Yeah. That makes sense.
Yeah. Having an onboarding process, that's a little bit more staggered.
Well, 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, you know, 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?
Yes. 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.
My website is productsforgood .co.
I have the framework as a Miraverse board, so it's published on Miraverse.
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 irritable list of products with some categorization, it's still work in progress because I always find new products.
So, if there is something missing over there by all means, please contact me on LinkedIn and I would love to hear from everyone.
Yeah, we'd be so excited to share it and yeah, thank you so much for all the resources and for your time.
My pleasure. Thank you very much. Thanks for listening in.
For more great insights, how -to guides and tool reviews, subscribe to our newsletter at theproductmanager .com slash subscribe.
You can hear more conversations like this by subscribing to The Product Manager wherever you get your podcasts.
