March 18, 2025 • 21 mins
How many logins do you use at work each week? If you’re not sure, you’re not alone. A 2024 report found that the average employee uses 36 cloud-based services daily—engineering teams use twice as many! Yet, over half of SaaS licenses go unused, wasting valuable resources.
In this episode, host Hannah Clark sits down with Moshe Mikanovsky, founder of Products for Good and co-host of the Product for Product podcast. Moshe shares his framework for selecting the right tools, helping organizations boost adoption, productivity, and cost efficiency. Tune in to learn how to make smarter software choices!
Resources from this episode:
- Subscribe to The Product Manager newsletter
- Connect with Moshe on LinkedIn
- Check out Products for Good and Product for Product podcast
- Moshe’s frameworks
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Hannah Clark (00:01):
Quick, without counting, can you tell me how
many logins you currently useat work on a weekly basis?
If you don't know, hitpause and try counting.
I bet the number is shocking.
In fact, a 2024 report byCloudZero found that the
average employee currentlyuses 36 cloud-based services
per day, and engineeringteams use twice as many.
(00:21):
Crazy, right?
And here's another crazything that probably
won't surprise you.
According to CloudZero's2023 study, over 53% of
SaaS licenses go unused.
In other words, despite ourorg's constant need for tools to
support our unique operations,we are wasting a ton of money
on tools that, for whateverreason, just aren't fitting.
(00:43):
My guest today is MosheMikanovsky, founder and lead
product coach at Products forGood and the co-host of the
Product for Product podcast.
Having worked in product andsoftware engineering since
1989, a major focus of Moshe'sin recent years, is helping
product teams make betterdecisions around the tools
they choose to implement.
Of note, Moshe has developed acomprehensive framework to help
orgs choose the right tools fortheir needs, thereby increasing
(01:04):
adoption and productivity whilereducing wasteful spending.
We discuss some of thehighlights from the framework
that can help you choosebetter tools starting today.
Let's jump in.
Welcome back to TheProduct Manager podcast.
I'm here today withMoshe Mikanovsky.
He is the founder andlead product coach
at Products for Good.
Moshe, thank you so muchfor joining us today.
Moshe Mikanovsky (01:24):
Thank you for having me, Hannah.
Hannah Clark (01:25):
So we'll start off the way we always do.
Can you tell us a little bitabout your background and how
you got to where you are today?
Moshe Mikanovsky (01:30):
Yeah, I started as a software
developer many years ago.
For the first 20 years ofmy career, I was working
on the engineering side.
I was lucky enough to workfor small organizations.
Or at the field,actually working with
clients and with users.
So I think I developedpart of my empathy to
users and what they need.
(01:51):
Back then.
And then after 20 years,I decided to move to
product management.
This is what I'm doingfor the past 14, 15 years.
Really love doing that.
I love talking aboutproduct management.
I love helping otherpeople 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
(02:15):
me up in the morning.
Hannah Clark (02:15):
You're in good company here.
So today we're going to betalking about something that
I think is of interest toeverybody, which is tools.
How product teams can makebetter decisions when selecting
tools for their organizations.
A chronic concern.
And this is also a majorarea of expertise for you.
What initially inspiredyou to create your product
selection framework that we'llbe talking about shortly?
Moshe Mikanovsky (02:33):
Yes.
So I have a podcast that Ico host for four years now
with my friend Matt Green.
It's called TheProduct for Product.
And on the podcast, we arebasically covering tools that
product people are using.
That was always an interestof both of us from different
directions for Matt.
When he moved into productmanagement for me, just trying
(02:53):
different products in the pastand choosing products because
no one else chose them forme and I had to do the work.
It's always reallyinteresting to see, what
is available out there.
So that's what we'redoing in the podcast.
And from that, I realizedthroughout recording different
episodes for differenttopics and different themed
(03:14):
products, that there are somecommonalities 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 interviewedusers of the products,
unless it's a startup.
And then, there isnot a lot of users.
So we bring the founder, but inmost cases we interview users.
(03:35):
So they already have.
insight, knowledge abouthow it's used, what
works, what doesn't work.
And from that, I accumulateda lot of this reasoning and
things to look for, which mademe put it all in one framework
that I love sharing with people.
Hannah Clark (03:52):
In your experience, if we want to talk
about some of the misstepsthat people make before we get
into kind of the right way ofdoing things or a framework for
how to do things, maybe in thebest way for your organization.
What are some of the mostcommon mistakes that product
organizations make whenthey're choosing new tools and
what consequences did thosemistakes typically lead to?
Moshe Mikanovsky (04:11):
Yeah, I think that it's mainly about how
they choose the tools and notlooking into a better fit for
the tool to their organization.
That would be the first thing.
And that's quite a bit whatthe framework is all about, but
also not really understandingthe tools before choosing them.
(04:31):
It's a common thing.
We always are very excitedabout the new tool.
We look for it.
We see the differentfeatures that it can do.
We feel, or we think it willfit 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 onlyat the marketing information on
(04:53):
the vendor's website, and it'snot telling us the full story.
Or the demos were not tellingus the full story, or there
is different gotchas that welearned throughout doing it.
So that's what I see manytimes, not the best fit for
the organization and not enoughunderstanding of how the product
actually will work for them.
Hannah Clark (05:14):
Yeah, that makes sense.
All right.
Then let's walk throughyour selection process.
So the way that yourframework starts out,
you start by identifyingproblems and then there's
prioritizing and shortlistingand then comparing tools.
So quite a bit of prework before you even
get into actually thecomparisons side of things.
And why is this preliminary workso important before you actually
jump into comparing features?
Moshe Mikanovsky (05:33):
I think it's like any other product.
I try to approach as productperson for so many years,
almost everything that I do, Itry to approach as a product.
So I did the samething with this.
Trying to understand what isthe real problem we're trying
to solve is really important.
So we don't want to buildfeatures for a solution
that no one will use.
(05:53):
The same thing, we don'treally need specific features
if there is no problem tosolve for us over there.
So the fact that everyone isdoing something doesn't mean
that you have to do it as well,or that the way that other
people are doing it will fit howyour organization is working.
So that's where really thebeginning preliminary work
before you even look at allthe features is to understand
(06:16):
what are the real problemsyou're trying to solve,
to understand what is thework, what is the job to be
done of your product team.
So for which you needto choose those tools.
And then what are thepriorities between all of these?
So we know sometimes we cannotbuy all the products right away.
Sometimes even gettingbudget for one product
(06:36):
is more than we can get.
And therefore prioritizingwhat is really the biggest
problem that we have rightnow, that, and maybe it's not
always a problem, but it's.
Something that takes us along time to do, or there is
a lot of mess and we need toclean it up or whatever it is.
And based on that biggestproblem to prioritize that
(06:58):
and say, okay, this is reallythe thing we need to look
for first and then creatingalmost a roadmap for your
choosing of products andimplementing them eventually.
Hannah Clark (07:07):
Okay, so I want to talk to you a little bit about
something that's interestingabout the process that you
use for comparing tools, whichis product philosophy, which
is the first criterion here.
Okay.
First of all, what do youmean by product philosophy
and why does this matter?
What are the differences inphilosophy really look like
and how does it impact thetools fit for an organization?
Moshe Mikanovsky (07:24):
Yeah, one of the things that I noticed
throughout talking withpeople, and it was also my
own experience and my co hostMatt's experience, is that
we're not alike with the waywe 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 Iput under philosophy.
(07:45):
So for example, Some of usreally want to have one product
that will solve everything.
And all the different featuresthat we need will be there.
We don't need toimplement anything else.
But we know many times thatsuch products don't go very
deep in each one of thosefeatures, but they go very wide.
Where others, theirphilosophy is, I want the
(08:06):
best of the best for eachspecific problem that I have.
I do want it to be integrated.
So everything is talkingwith each other, but that
adds to the complexityof the solution as well.
So that's just one exampleof a philosophy where,
what is it really that weare as an organization?
And sometimes it's hard todefine if you don't know how
your organization is working,who's making those decisions,
(08:29):
but it's important to lookfor this information because
this will help you nail into aspecific product or a selection
of shortlist your product.
Another one of thesephilosophies is whether
you want the product to beflexible or deterministic.
So some products will giveyou the option to create any
workflow that you want anddefine any field that you want
(08:52):
and whatever, but that's verysometimes generic, but flexible.
I will, I'm using that word.
So each organizationwill implement it in
a bit different way.
And some products in thesame category could be
very deterministic whenthey can tell you, no,
you have to work this way.
So we only build it that way.
I'm not saying one isbetter than the other.
(09:12):
Sometimes it's a stage ofthe 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 theydon't know a specific.
Way to do, I don't know, sprintsand to do a backlog grooming
and all of these things, andthey get a product that is
deterministic about it, thenit will teach them the process.
(09:35):
But it will only teach them inone way where there are many
other ways that it could happen.
And maybe once they are moremature, they will be more
comfortable using anotherproduct that will be much
more flexible for that.
So these are some of thethe items that I'm looking
for that are part of theframework to, even before
you look into the future tosee, what is your culture,
(09:56):
what type of products arebetter fit for you, et cetera.
Hannah Clark (10:00):
Okay.
And speaking of flexibility,there's another criterion I
want to grill you on a littlebit, which is The factor of
ongoing engineering required.
So this is an interesting one.
So how should teams evaluate theengineering resources that are
needed to integrate differenttools and how might that kind
of correlate with the longterm success of that product?
Moshe Mikanovsky (10:16):
Yeah, this is also going into some type
of philosophy, my philosophyin building products in
general, for my own companythat I work for, or when
I consult other companies.
is that our engineers shouldreally focus on the added
value that we're creating andnot reinvent the wheel with
many things that millionsof other developers already
(10:39):
developed in the past.
So in the same way, when Iadd features to my product in
app messaging or like productanalytics, which are all.
Existing in those toolsthat we, we have these
days, just as an example.
I'm just takingthis as an example.
I don't really wantmy developers to worry
about these things.
(11:00):
I prefer them to integrateit once with a very
simple integration andkind of forget about it.
And then give me the productmanager or other people outside
of the engineering team, theabilities to define whatever
we need to define in order to.
Get the most value of thisproduct, but some products in
(11:21):
the same category for enoughmessaging and for product
analytics actually do requireengineers on an ongoing basis,
because sometimes you will haveto define for them events to
raise or how to do to definethe look and feel of your enough
messaging or whatever that is.
And to me, and again, this isa personal thing for me, so I'm
(11:42):
not saying it's right or wrong.
But to me, it's a wasteof time of the developers.
I prefer they work on value thatis unique to our organization.
Hannah Clark (11:51):
Okay.
So speaking of companyvalues and some of those
more unique things.
You've mentioned also thecultural factors like company
values and communicationstyles can also impact tool
selection, which I thinkis really interesting.
I would love to hear a storyof how that kind of works
in practice, how these lesstangible elements can influence
which of the tools can besuccessful in an organization.
Moshe Mikanovsk (12:13):
Yeah, for sure.
I can give you an example ofa place where I worked and
we had a really hard timewith async communication.
It was really annoying tome because we were working
remotely and you will think thatremotely, async is one of those
things that help you collaboratebetter and That you don't need
(12:33):
to be on regular meetings.
We had to be on regularmeetings on all the time in
order to move things forward.
And we also chose to uselike a backlog system.
I think it was Jira, but inany of those systems, when
you define your let's say yourepics maybe in a confluence
document and your storieswith acceptance criterias.
(12:54):
You would expect people togo through that, to read
it and collaborate on thecomments on some way of
asynchronously work together.
And it just didn't work.
And every time that peoplewould tell me, Oh, I didn't see
that, or the way they open itup in meetings, I was like, but
we had all of that in there.
That was a cultural issue thatwas impacting how useful our
(13:20):
usage of the products were.
And I was sometimes feeling I'mswimming against the stream.
I had to do a whole sessionjust to tell them what the
async communication are andwhat's the importance of this.
I don't remember ifit even helped or not.
So that's whatI'm talking about.
And it's just one example of howyour organization is working.
(13:41):
And a tool is not goingto fix that necessarily.
A tool can help you be, makeyour communication better.
If you put the efforts inactually using it, a tool can
help you make your processesbetter if it works for the
way your organization work.
And usually not the other wayaround, even though it could
(14:02):
help modify how companies work.
But I would first lookat, what are the cultural
constraints that you have andthen fit the tool to that.
Hannah Clark (14:13):
That makes a lot more sense.
Let's go back to featurecomparisons now that we've
talked about some of this prework and some of the factors to
consider before we're gettingreally into the nitty gritty
of what the tool has to offer.
So many teams obviouslyjump straight to feature
comparison and pricingwhen evaluating tools.
You mentioned that earlier.
Why are these factors so latein your evaluation framework?
Moshe Mikanovsky (14:31):
Mainly because I don't want people
to look first into the outputsof what they can do with the
product they're using, but moreof the outcomes that they're
trying to get from that.
Features are probably theeasier thing to compare.
And also organizations willtell you that they have this
(14:53):
feature and this feature.
But when you look into thedetails, Which sometimes will
be published, sometimes not.
So you have to find it yourself.
You will find out whetherit is really the features
you were expecting.
Sometimes they will usedifferent terminology for that.
Sometimes they will use verydifferent pricing for different
features that are available.
(15:13):
Which is all fine, but mostof the time it's up to us,
the consumers, to reallypick through all of that,
all of those details to findthe right product for us.
But again, I think the mostimportant thing is that
we want to have outcomes.
oriented selection of thetools and implementation of
(15:34):
the tools versus just outputs.
I can do this and I can dothat, and therefore this tool
is better than the other.
Hannah Clark (15:40):
Okay, so I want to get into maybe the
most frustrating componentof implementing a new tool,
which is getting everybody toadopt it and getting everyone
on the same page with how toadopt it as an organization.
Especially after you've donesuch extensive work, trying
to find the right tool, makeall these adaptations consider
all these things to make sureit's the right tool for you,
(16:00):
you still have to get people touse it and use it the same way.
So what are some of thekey strategies for ensuring
successful adoptionacross an organization?
Moshe Mikanovsky (16:08):
Okay, so the first one is selecting
the right tool, or at leastthe least unfitted tool that
you can find, because thereis always going to be things.
The second thing isthe selection process.
It's a tough one.
It depends who owns it,what the governance on the
ownership and the selectionprocess is going to be.
And you could have naysayerseven from that time.
(16:32):
So right now I don't havea specific recommendation.
It's something I'm thinkingabout and I will probably
extend the frameworka bit in the future.
When I get more informationalso from other people.
Because if you have many peoplein the selection process,
first of all, it can takevery long to select and the
second, do you have consentor do you have consensus and
(16:56):
that's another cultural thingin the organization and then
who owns the product, not justfrom the selection perspective
or implementing it, how manytimes in the past, historically.
IT was owning products inthe organization because it's
a software and you have toinstall it on a computer.
So IT will own it.
(17:17):
But then they will not reallycare much about is it really
successfully implemented or not.
So you always needed anotherchampion to implement it.
So ownership of thatis important as well.
And these days with productops, it might be an easier job
for some organization if theyhave product ops, because I
(17:38):
see it sitting quite nicelywithin product ops, especially
if you want to standardizeit across the organization.
And then they can.
understand all the needs ofall the different teams and
they can understand, what arethe differences between them?
What are the difficultiesto implement them and to
really use them in each team?
(17:59):
Because those couldbe personality issues.
It could be projectconstraint issues.
It could be manydifferent things.
And like any other product,the same way that, some of
us have to work hard for ourproduct to be implemented
properly at our client sites.
And, this is a B2B product.
All of the products we'retalking about are B2B.
So if you are developing aB2B product, you probably
(18:20):
know what I'm talking about.
And you might have moreempathy towards that as well.
If you are not buildingB2B products, you might
have some disconnect there.
It's not easy sometimes.
Depends on the size of yourorganization, how many projects
you have, how many productsyou have, lots of different
things involved, but I wouldsay overall is like who makes
(18:43):
the decision, who owns it,what type of governance you
have, how people are actually.
Accepting those decisionsand then moving it forward,
even doing iterations, soyou don't have to implement
all of it right away.
You can try different thingsand then iterate on it like you
would with any other product.
Hannah Clark (19:01):
Yeah, that makes sense.
Yeah, having an onboardingprocess that's a little
bit more staggered.
At least you have more accessto your users in this situation.
So that's an advantage.
Moshe, thank you so muchfor joining us today.
This has beenreally informative.
I think it's been reallyhelpful because we're all
at a point at some point toselect new tools and the whole
process of implementing themcan be a bit of a journey.
So we really appreciateyour guidance here.
(19:22):
Where can people learn moreabout this product selection
framework that you've developedand connect with you online?
Moshe Mikanovsky (19:26):
Yeah.
So first of all, my pleasureand thank you for having me.
Everyone can connectwith me on LinkedIn.
You can find me with my lastname, Mikanovsky, and my
website is productsforgood.co.
I have the frameworkas a Miroverse board.
So it's published on Miroverse.
I have a link to that onmy website under resources.
(19:47):
But also I will share itwith you so you can put it
in the description of theepisodes, more than happy for
me to share it with everyone.
You can copy itand start using it.
There is explanationsover there.
There is a lot of resourcesinside the framework, like
Airtable, list of productswith some categorization.
(20:08):
It's still a work inprogress because there is
always new, I always findnew products, if there is
something missing over there,by all means, please contact
me on LinkedIn and I wouldlove to hear from everyone.
Hannah Clark (20:18):
Yeah, we would be so excited to share it and yeah.
Thank you so much for all theresources and for your time.
Moshe Mikanovsky (20:23):
My pleasure.
Thank you very much, Hannah.
Hannah Clark (20:28):
Thanks for listening in.
For more great insights,how-to guides and tool reviews,
subscribe to our newsletter attheproductmanager.com/subscribe.
You can hear more conversationslike this by subscribing to
The Product Manager whereveryou get your podcasts.
Quick, without counting, can you tell me how
many logins you currently useat work on a weekly basis?
If you don't know, hitpause and try counting.
I bet the number is shocking.
In fact, a 2024 report byCloudZero found that the
average employee currentlyuses 36 cloud-based services
per day, and engineeringteams use twice as many.
(00:21):
Crazy, right?
And here's another crazything that probably
won't surprise you.
According to CloudZero's2023 study, over 53% of
SaaS licenses go unused.
In other words, despite ourorg's constant need for tools to
support our unique operations,we are wasting a ton of money
on tools that, for whateverreason, just aren't fitting.
(00:43):
My guest today is MosheMikanovsky, founder and lead
product coach at Products forGood and the co-host of the
Product for Product podcast.
Having worked in product andsoftware engineering since
1989, a major focus of Moshe'sin recent years, is helping
product teams make betterdecisions around the tools
they choose to implement.
Of note, Moshe has developed acomprehensive framework to help
orgs choose the right tools fortheir needs, thereby increasing
(01:04):
adoption and productivity whilereducing wasteful spending.
We discuss some of thehighlights from the framework
that can help you choosebetter tools starting today.
Let's jump in.
Welcome back to TheProduct Manager podcast.
I'm here today withMoshe Mikanovsky.
He is the founder andlead product coach
at Products for Good.
Moshe, thank you so muchfor joining us today.
Moshe Mikanovsky (01:24):
Thank you for having me, Hannah.
Hannah Clark (01:25):
So we'll start off the way we always do.
Can you tell us a little bitabout your background and how
you got to where you are today?
Moshe Mikanovsky (01:30):
Yeah, I started as a software
developer many years ago.
For the first 20 years ofmy career, I was working
on the engineering side.
I was lucky enough to workfor small organizations.
Or at the field,actually working with
clients and with users.
So I think I developedpart of my empathy to
users and what they need.
(01:51):
Back then.
And then after 20 years,I decided to move to
product management.
This is what I'm doingfor the past 14, 15 years.
Really love doing that.
I love talking aboutproduct management.
I love helping otherpeople 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
(02:15):
me up in the morning.
Hannah Clark (02:15):
You're in good company here.
So today we're going to betalking about something that
I think is of interest toeverybody, which is tools.
How product teams can makebetter decisions when selecting
tools for their organizations.
A chronic concern.
And this is also a majorarea of expertise for you.
What initially inspiredyou to create your product
selection framework that we'llbe talking about shortly?
Moshe Mikanovsky (02:33):
Yes.
So I have a podcast that Ico host for four years now
with my friend Matt Green.
It's called TheProduct for Product.
And on the podcast, we arebasically covering tools that
product people are using.
That was always an interestof both of us from different
directions for Matt.
When he moved into productmanagement for me, just trying
(02:53):
different products in the pastand choosing products because
no one else chose them forme and I had to do the work.
It's always reallyinteresting to see, what
is available out there.
So that's what we'redoing in the podcast.
And from that, I realizedthroughout recording different
episodes for differenttopics and different themed
(03:14):
products, that there are somecommonalities 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 interviewedusers of the products,
unless it's a startup.
And then, there isnot a lot of users.
So we bring the founder, but inmost cases we interview users.
(03:35):
So they already have.
insight, knowledge abouthow it's used, what
works, what doesn't work.
And from that, I accumulateda lot of this reasoning and
things to look for, which mademe put it all in one framework
that I love sharing with people.
Hannah Clark (03:52):
In your experience, if we want to talk
about some of the misstepsthat people make before we get
into kind of the right way ofdoing things or a framework for
how to do things, maybe in thebest way for your organization.
What are some of the mostcommon mistakes that product
organizations make whenthey're choosing new tools and
what consequences did thosemistakes typically lead to?
Moshe Mikanovsky (04:11):
Yeah, I think that it's mainly about how
they choose the tools and notlooking into a better fit for
the tool to their organization.
That would be the first thing.
And that's quite a bit whatthe framework is all about, but
also not really understandingthe tools before choosing them.
(04:31):
It's a common thing.
We always are very excitedabout the new tool.
We look for it.
We see the differentfeatures that it can do.
We feel, or we think it willfit 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 onlyat the marketing information on
(04:53):
the vendor's website, and it'snot telling us the full story.
Or the demos were not tellingus the full story, or there
is different gotchas that welearned throughout doing it.
So that's what I see manytimes, not the best fit for
the organization and not enoughunderstanding of how the product
actually will work for them.
Hannah Clark (05:14):
Yeah, that makes sense.
All right.
Then let's walk throughyour selection process.
So the way that yourframework starts out,
you start by identifyingproblems and then there's
prioritizing and shortlistingand then comparing tools.
So quite a bit of prework before you even
get into actually thecomparisons side of things.
And why is this preliminary workso important before you actually
jump into comparing features?
Moshe Mikanovsky (05:33):
I think it's like any other product.
I try to approach as productperson for so many years,
almost everything that I do, Itry to approach as a product.
So I did the samething with this.
Trying to understand what isthe real problem we're trying
to solve is really important.
So we don't want to buildfeatures for a solution
that no one will use.
(05:53):
The same thing, we don'treally need specific features
if there is no problem tosolve for us over there.
So the fact that everyone isdoing something doesn't mean
that you have to do it as well,or that the way that other
people are doing it will fit howyour organization is working.
So that's where really thebeginning preliminary work
before you even look at allthe features is to understand
(06:16):
what are the real problemsyou're trying to solve,
to understand what is thework, what is the job to be
done of your product team.
So for which you needto choose those tools.
And then what are thepriorities between all of these?
So we know sometimes we cannotbuy all the products right away.
Sometimes even gettingbudget for one product
(06:36):
is more than we can get.
And therefore prioritizingwhat is really the biggest
problem that we have rightnow, that, and maybe it's not
always a problem, but it's.
Something that takes us along time to do, or there is
a lot of mess and we need toclean it up or whatever it is.
And based on that biggestproblem to prioritize that
(06:58):
and say, okay, this is reallythe thing we need to look
for first and then creatingalmost a roadmap for your
choosing of products andimplementing them eventually.
Hannah Clark (07:07):
Okay, so I want to talk to you a little bit about
something that's interestingabout the process that you
use for comparing tools, whichis product philosophy, which
is the first criterion here.
Okay.
First of all, what do youmean by product philosophy
and why does this matter?
What are the differences inphilosophy really look like
and how does it impact thetools fit for an organization?
Moshe Mikanovsky (07:24):
Yeah, one of the things that I noticed
throughout talking withpeople, and it was also my
own experience and my co hostMatt's experience, is that
we're not alike with the waywe 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 Iput under philosophy.
(07:45):
So for example, Some of usreally want to have one product
that will solve everything.
And all the different featuresthat we need will be there.
We don't need toimplement anything else.
But we know many times thatsuch products don't go very
deep in each one of thosefeatures, but they go very wide.
Where others, theirphilosophy is, I want the
(08:06):
best of the best for eachspecific problem that I have.
I do want it to be integrated.
So everything is talkingwith each other, but that
adds to the complexityof the solution as well.
So that's just one exampleof a philosophy where,
what is it really that weare as an organization?
And sometimes it's hard todefine if you don't know how
your organization is working,who's making those decisions,
(08:29):
but it's important to lookfor this information because
this will help you nail into aspecific product or a selection
of shortlist your product.
Another one of thesephilosophies is whether
you want the product to beflexible or deterministic.
So some products will giveyou the option to create any
workflow that you want anddefine any field that you want
(08:52):
and whatever, but that's verysometimes generic, but flexible.
I will, I'm using that word.
So each organizationwill implement it in
a bit different way.
And some products in thesame category could be
very deterministic whenthey can tell you, no,
you have to work this way.
So we only build it that way.
I'm not saying one isbetter than the other.
(09:12):
Sometimes it's a stage ofthe 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 theydon't know a specific.
Way to do, I don't know, sprintsand to do a backlog grooming
and all of these things, andthey get a product that is
deterministic about it, thenit will teach them the process.
(09:35):
But it will only teach them inone way where there are many
other ways that it could happen.
And maybe once they are moremature, they will be more
comfortable using anotherproduct that will be much
more flexible for that.
So these are some of thethe items that I'm looking
for that are part of theframework to, even before
you look into the future tosee, what is your culture,
(09:56):
what type of products arebetter fit for you, et cetera.
Hannah Clark (10:00):
Okay.
And speaking of flexibility,there's another criterion I
want to grill you on a littlebit, which is The factor of
ongoing engineering required.
So this is an interesting one.
So how should teams evaluate theengineering resources that are
needed to integrate differenttools and how might that kind
of correlate with the longterm success of that product?
Moshe Mikanovsky (10:16):
Yeah, this is also going into some type
of philosophy, my philosophyin building products in
general, for my own companythat I work for, or when
I consult other companies.
is that our engineers shouldreally focus on the added
value that we're creating andnot reinvent the wheel with
many things that millionsof other developers already
(10:39):
developed in the past.
So in the same way, when Iadd features to my product in
app messaging or like productanalytics, which are all.
Existing in those toolsthat we, we have these
days, just as an example.
I'm just takingthis as an example.
I don't really wantmy developers to worry
about these things.
(11:00):
I prefer them to integrateit once with a very
simple integration andkind of forget about it.
And then give me the productmanager or other people outside
of the engineering team, theabilities to define whatever
we need to define in order to.
Get the most value of thisproduct, but some products in
(11:21):
the same category for enoughmessaging and for product
analytics actually do requireengineers on an ongoing basis,
because sometimes you will haveto define for them events to
raise or how to do to definethe look and feel of your enough
messaging or whatever that is.
And to me, and again, this isa personal thing for me, so I'm
(11:42):
not saying it's right or wrong.
But to me, it's a wasteof time of the developers.
I prefer they work on value thatis unique to our organization.
Hannah Clark (11:51):
Okay.
So speaking of companyvalues and some of those
more unique things.
You've mentioned also thecultural factors like company
values and communicationstyles can also impact tool
selection, which I thinkis really interesting.
I would love to hear a storyof how that kind of works
in practice, how these lesstangible elements can influence
which of the tools can besuccessful in an organization.
Moshe Mikanovsk (12:13):
Yeah, for sure.
I can give you an example ofa place where I worked and
we had a really hard timewith async communication.
It was really annoying tome because we were working
remotely and you will think thatremotely, async is one of those
things that help you collaboratebetter and That you don't need
(12:33):
to be on regular meetings.
We had to be on regularmeetings on all the time in
order to move things forward.
And we also chose to uselike a backlog system.
I think it was Jira, but inany of those systems, when
you define your let's say yourepics maybe in a confluence
document and your storieswith acceptance criterias.
(12:54):
You would expect people togo through that, to read
it and collaborate on thecomments on some way of
asynchronously work together.
And it just didn't work.
And every time that peoplewould tell me, Oh, I didn't see
that, or the way they open itup in meetings, I was like, but
we had all of that in there.
That was a cultural issue thatwas impacting how useful our
(13:20):
usage of the products were.
And I was sometimes feeling I'mswimming against the stream.
I had to do a whole sessionjust to tell them what the
async communication are andwhat's the importance of this.
I don't remember ifit even helped or not.
So that's whatI'm talking about.
And it's just one example of howyour organization is working.
(13:41):
And a tool is not goingto fix that necessarily.
A tool can help you be, makeyour communication better.
If you put the efforts inactually using it, a tool can
help you make your processesbetter if it works for the
way your organization work.
And usually not the other wayaround, even though it could
(14:02):
help modify how companies work.
But I would first lookat, what are the cultural
constraints that you have andthen fit the tool to that.
Hannah Clark (14:13):
That makes a lot more sense.
Let's go back to featurecomparisons now that we've
talked about some of this prework and some of the factors to
consider before we're gettingreally into the nitty gritty
of what the tool has to offer.
So many teams obviouslyjump straight to feature
comparison and pricingwhen evaluating tools.
You mentioned that earlier.
Why are these factors so latein your evaluation framework?
Moshe Mikanovsky (14:31):
Mainly because I don't want people
to look first into the outputsof what they can do with the
product they're using, but moreof the outcomes that they're
trying to get from that.
Features are probably theeasier thing to compare.
And also organizations willtell you that they have this
(14:53):
feature and this feature.
But when you look into thedetails, Which sometimes will
be published, sometimes not.
So you have to find it yourself.
You will find out whetherit is really the features
you were expecting.
Sometimes they will usedifferent terminology for that.
Sometimes they will use verydifferent pricing for different
features that are available.
(15:13):
Which is all fine, but mostof the time it's up to us,
the consumers, to reallypick through all of that,
all of those details to findthe right product for us.
But again, I think the mostimportant thing is that
we want to have outcomes.
oriented selection of thetools and implementation of
(15:34):
the tools versus just outputs.
I can do this and I can dothat, and therefore this tool
is better than the other.
Hannah Clark (15:40):
Okay, so I want to get into maybe the
most frustrating componentof implementing a new tool,
which is getting everybody toadopt it and getting everyone
on the same page with how toadopt it as an organization.
Especially after you've donesuch extensive work, trying
to find the right tool, makeall these adaptations consider
all these things to make sureit's the right tool for you,
(16:00):
you still have to get people touse it and use it the same way.
So what are some of thekey strategies for ensuring
successful adoptionacross an organization?
Moshe Mikanovsky (16:08):
Okay, so the first one is selecting
the right tool, or at leastthe least unfitted tool that
you can find, because thereis always going to be things.
The second thing isthe selection process.
It's a tough one.
It depends who owns it,what the governance on the
ownership and the selectionprocess is going to be.
And you could have naysayerseven from that time.
(16:32):
So right now I don't havea specific recommendation.
It's something I'm thinkingabout and I will probably
extend the frameworka bit in the future.
When I get more informationalso from other people.
Because if you have many peoplein the selection process,
first of all, it can takevery long to select and the
second, do you have consentor do you have consensus and
(16:56):
that's another cultural thingin the organization and then
who owns the product, not justfrom the selection perspective
or implementing it, how manytimes in the past, historically.
IT was owning products inthe organization because it's
a software and you have toinstall it on a computer.
So IT will own it.
(17:17):
But then they will not reallycare much about is it really
successfully implemented or not.
So you always needed anotherchampion to implement it.
So ownership of thatis important as well.
And these days with productops, it might be an easier job
for some organization if theyhave product ops, because I
(17:38):
see it sitting quite nicelywithin product ops, especially
if you want to standardizeit across the organization.
And then they can.
understand all the needs ofall the different teams and
they can understand, what arethe differences between them?
What are the difficultiesto implement them and to
really use them in each team?
(17:59):
Because those couldbe personality issues.
It could be projectconstraint issues.
It could be manydifferent things.
And like any other product,the same way that, some of
us have to work hard for ourproduct to be implemented
properly at our client sites.
And, this is a B2B product.
All of the products we'retalking about are B2B.
So if you are developing aB2B product, you probably
(18:20):
know what I'm talking about.
And you might have moreempathy towards that as well.
If you are not buildingB2B products, you might
have some disconnect there.
It's not easy sometimes.
Depends on the size of yourorganization, how many projects
you have, how many productsyou have, lots of different
things involved, but I wouldsay overall is like who makes
(18:43):
the decision, who owns it,what type of governance you
have, how people are actually.
Accepting those decisionsand then moving it forward,
even doing iterations, soyou don't have to implement
all of it right away.
You can try different thingsand then iterate on it like you
would with any other product.
Hannah Clark (19:01):
Yeah, that makes sense.
Yeah, having an onboardingprocess that's a little
bit more staggered.
At least you have more accessto your users in this situation.
So that's an advantage.
Moshe, thank you so muchfor joining us today.
This has beenreally informative.
I think it's been reallyhelpful because we're all
at a point at some point toselect new tools and the whole
process of implementing themcan be a bit of a journey.
So we really appreciateyour guidance here.
(19:22):
Where can people learn moreabout this product selection
framework that you've developedand connect with you online?
Moshe Mikanovsky (19:26):
Yeah.
So first of all, my pleasureand thank you for having me.
Everyone can connectwith me on LinkedIn.
You can find me with my lastname, Mikanovsky, and my
website is productsforgood.co.
I have the frameworkas a Miroverse board.
So it's published on Miroverse.
I have a link to that onmy website under resources.
(19:47):
But also I will share itwith you so you can put it
in the description of theepisodes, more than happy for
me to share it with everyone.
You can copy itand start using it.
There is explanationsover there.
There is a lot of resourcesinside the framework, like
Airtable, list of productswith some categorization.
(20:08):
It's still a work inprogress because there is
always new, I always findnew products, if there is
something missing over there,by all means, please contact
me on LinkedIn and I wouldlove to hear from everyone.
Hannah Clark (20:18):
Yeah, we would be so excited to share it and yeah.
Thank you so much for all theresources and for your time.
Moshe Mikanovsky (20:23):
My pleasure.
Thank you very much, Hannah.
Hannah Clark (20:28):
Thanks for listening in.
For more great insights,how-to guides and tool reviews,
subscribe to our newsletter attheproductmanager.com/subscribe.
You can hear more conversationslike this by subscribing to
The Product Manager whereveryou get your podcasts.
Popular Podcasts
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Intentionally Disturbing
Join me on this podcast as I navigate the murky waters of human behavior, current events, and personal anecdotes through in-depth interviews with incredible people—all served with a generous helping of sarcasm and satire. After years as a forensic and clinical psychologist, I offer a unique interview style and a low tolerance for bullshit, quickly steering conversations toward depth and darkness. I honor the seriousness while also appreciating wit. I’m your guide through the twisted labyrinth of the human psyche, armed with dark humor and biting wit.