Your Product Manager Toolkit

Moshe Mikanovsky at UXDX USA. Video: https://youtu.be/Y2h65P0eILc

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

Introduction and why this talk exists

[00:00:00] Hi everyone, how is everyone doing? Perfect. Nice day today, although we're in the basement. But still, it's all product people, UX people, so what's not to love?

[00:00:12] Okay, starting with that. My name is Moshe Mikanovsky — sorry, I didn't introduce myself — and I'm going to talk about your product manager toolkit. I've been developing and building products, first in engineering and then in product management, for the last 30 years, a bit more than 30 years. Right now I'm working with Bain Public. It's an education and consultancy group in Montreal in Canada, where we're basically teaching other companies how to do product, so product culture. It's all about the product center, just about the product.

[00:00:44] I also have a podcast called Product for Product. In the last more than two years — thank you for COVID — me and a co-host, Matt Green from Atlanta, we basically have this podcast where we're talking about products for product people. So we learned a lot about the products that are available out there, and also what the difference between them is, and how different products fit different organizations. We talked with a lot of people, and this presentation came up from that.

[00:01:16] So do you ever feel like this? That there are so many products out there, how do I choose my product? By show of hands maybe, how many of you have used some of these products? So all of you. By show of hands, how many of you have to choose a product to use? A little less, but still quite a bit of people. And then my last show of hands, how many of you said it was easy? No one. Yeah, we know that.

[00:01:45] When we are product managers or UX — this is geared to product managers, my talk specifically, but this is for anyone that has to choose products. I know there are a lot of UXers over here and you also have to use products, and you see some of the products that you're using. But I've been in situations where I didn't have a UXR or UIR, so I had to choose my own products and do my own UX, et cetera. So product managers really touch everything.

The process for choosing a product

[00:02:11] So how do I choose which product to use? What I put for you — and don't worry, at the end the last slide, and I hope it will stay for a few seconds so you can grab it, there is a QR code that you can scan and you will be able to access this Miro board. I know people yesterday mentioned processes, we don't like processes, but they are important, we need to use them. So I put the process here of how I choose a product, quite detailed as you can see, but don't worry, we'll go through all the steps over here.

[00:02:49] It's quite similar to building a product. First you have to identify which problems you want to solve, or which ones you have to solve. Then you want to do some type of prioritization. Here we're talking about third-party products, so it's not the products that we're building in-house, these are products that we will buy externally for our stack as product people. So we usually will say, okay, there are these products out there in the market, let's shortlist those products and see what is going to work for us and what's not. We compare them, we test them, and then we implement what we chose.

[00:03:28] Now, how many of you start really in the identification of the problem versus in the compare? Maybe by show of hands, who starts with the identification of the problem? Good, a few of you. And who starts with the compare? I think more, but you just don't want to admit it, because that's what we usually tend to do. We say, no, we have this problem, let's just see what's out there, we start comparing them and whatever.

Identifying the problem

[00:03:57] So let's go through this process. Let's start with identifying the problem. This is us, little product managers, in the center of our world. I'm using here The Lean Startup, or lean product manager, whatever you call the lean process, for learn, build and measure. When we go through this process there are a lot of things we have to do as product managers, and many of you UXRs probably have to do a lot of these things also, or analysts. When we learn, we have to learn our domain, we have to learn who is the competition out there, we have to do discovery — we've talked a lot about this yesterday. When we build, there are a lot of things we have to do with engineers, with other engineers, with the stakeholders, et cetera, there are a lot of activities we have to do. And when we measure, we have to look into all the data and what our KPIs are, and is there an ROI to what we're doing, et cetera. So a lot of stuff we have to do.

[00:04:55] And then for each one of those things there are a lot of activities that we have to do there. I tried to list everything, but I'm sure I missed something. Each one of those things is really one of the problems we have to solve. So if we need to do experiments, how do we do experiments? Do we have any type of prototyping system? Do we create wireframes? How do we create A/B testing? Do we approach our users for testing, et cetera. When we work on our backlog, or when we work with an engineer: okay, so we need now to write our stories, and we have to get feedback, and we have to write and communicate it with our team, et cetera, et cetera. So there are a lot of those small things in this process that we have to solve.

[00:05:47] So this is really identifying the problem. Here you say, okay, these are all the things I have to do. Wow, that's a lot. But we know being a product manager is not easy.

Prioritizing, and what impacts the decision

[00:05:57] Next, to prioritize. Which one of those are we going to — what is most important for us? Now, I'm not going to go into your prioritization method, because there are millions of them maybe. There was a session yesterday about prioritization. At Bain Public we are using a method we call the blueprint, the service blueprint, where we have this process of the user journey on the top, which is the full picture of what needs to happen, and then all the components on the bottom, the technical ecosystem. So we were using that one, and here I'm seeing, oh, I prioritize this: parking lot, product analytics, strategy, et cetera. But again, to talk about this I will need not 25 minutes, I will need maybe a day, so if you want we can talk about it later.

[00:06:48] But in general you prioritize for yourself what are the things that you have to work on. Now, throughout all of this thing, don't forget to work with your stakeholders, because if you prioritize alone and you do the stuff on your own, you know what will happen at the end. There's not going to be any buy-in, people will not want to use it. So always, always do it with your stakeholders.

[00:07:08] Now, what impacts our decision making here? Because there are a lot of things, and every one of you is in a different organization, a different size of organization, and for the organization there are things that will impact what it is that you actually need, what are the needs for the organization. So for example, the size of the organization: which stage are you at, are you at a startup or a growth or an enterprise? Different types of enterprises will have very different needs for the product they're choosing, so this will impact your decision. Who are your users, what is the complexity of your users, so how many types of users do you have, et cetera.

[00:07:47] Other things like the maturity of your organization. Who is going to own these products that you're bringing in? Do you have product ops? Usually product ops will help you with that. All the knowledge I have is because I never had product ops, so I had to do it myself. So is it going to be you, is it going to be a team of people that are going to do it? Who's going to own it, and what type of skills do they have to actually do that? There are a lot of skills that you need in that: looking for the products, trying them out, testing them out, project management, et cetera, et cetera.

[00:08:20] And then, what are your current tools? So how will a new tool that you bring in work in the ecosystem that you already have? Is it going to work, or what are you going to look for?

[00:08:30] The next thing is the culture of your organization. Culture to me — I should have put it as number one — to me is the most important thing, culture. What do you value, how flexible are you, and what type of communication you have. All of those things will impact again the type of product that you're choosing.

[00:08:50] And last but not least is your budget. So what is your current budget, but also think about the growth, because many of the tactics we are trying to do with our product, lock-in — how hard is it going to be for our clients to get off our product — will also happen with the products that you use. If they lock you in, can you still pay for it in the future when you grow? So think about things like that. I know it's hard. No one said it's easy.

Shortlisting

[00:09:19] Okay, so now we prioritized based on all of those components that we have. Now we want to shortlist it, and remember all of those tasks that we had before. So I put here some of the products that will cover some of those tasks, but this is not all of them. And just a small disclaimer, most of these are from those that we talked about in the podcast, but not all of them. And by the way, I'm looking for guests, so reach out to me.

[00:09:51] I put together on Airtable a list of products and also categorized them. There I have actually more than 130 right now, so you will be able to show at least the specific things that you need, and you will see that some products are covering one type of functionality, other products are covering other types of functionalities, or multiple functionalities. So it's all in there with the links to the company. You will see that link also in the Miro board.

Comparing: product philosophy

[00:10:28] Okay, so we shortlisted our products. Now we need to compare them, and I put together for you nine factors to compare. But maybe you can tell me what will be the first factor, or the most important factor for you? Price. What else? Sorry? How well it solves a problem. Okay, so price is always like, oh, price, that's the first thing I have to look at. You will see it is in there, but it's not high on my list anyway. Yes? Usability and flexibility, a very good one. So let's see what they are.

[00:11:13] Okay, so the first one I put here — and again, all of these are going to be in your Miro board, so you can always, and there are kind of questions in there to help you fill it up. It's basically like an Excel spreadsheet but in Miro, so you can copy it over to your Miro and start filling it up and compare the different products.

[00:11:31] So let's start with product philosophy. What is product philosophy? To me there are three things. There are different types of products, and the way that they solve problems is different, and also the way that these companies grow these products is different.

[00:11:51] So the first thing I'm looking at is deep versus wide. What does that mean? Deep means they solve one problem, but they go very deep. But if you need to solve any adjacent problem you need other products, and then you have to start integrating them. Wide means they solve several problems, so it's not only solving that one problem you need right now, it will solve others also. But usually they may not go as deep as one of the deep ones. Some of them do, I'm not saying they don't, but many times they will not. The nice thing about it is that it's all integrated, working very well with each other, you don't have to start implementing other products, but it's usually more expensive.

[00:12:36] The other philosophy is entry level versus advanced. Many of us, when we start, we opt to go with the entry level products. I don't want to mention any names because I'm not an advocate for any product, but I'm sure you might think about some products that everyone is using. Maybe from Google. And no, not bashing Google at all, they have great products, I'm using Google here. But in many cases this could be entry level, where they don't go very deep in functionality, or they don't make it as simple to use as some other products. Because the simplest it is to use probably means there is a lot of work in the back end to make it simple. So the company invested a lot to make it simple, therefore to me it's more advanced, because it saves me a lot of time when I use it. Many products, their free tier could be that entry level, and then you graduate, you mature into the advanced one.

[00:13:46] And then open-ended versus deterministic. Some products are open-ended, meaning that you can define whatever you want in them. They're very flexible, you can create your workflows, you can create your rules, but every company will implement in a different way. So if you worked with Jira in one company and then you move to another company, it's completely different. Where some products are very deterministic, they will tell you this is how you have to do things.

[00:14:12] Now, why do I call these philosophies? Because it's really up to you as well, what is your philosophy. Do you like going deep but picking the best product in each one of those problems and then integrating them, or do you like, oh, just give me everything at once and I will just solve all of my problems, but I'm willing to basically pay for not being very deep on that. On deterministic for example, if you don't have the capacity inside to say this is how we should work, because we don't really know, all of us are young and early in our career, we want these best practices, then maybe those deterministic products will give you those best practices. So it will be much faster for you to start, but then if you grow and you have to be more flexible, it will be a bit harder. So answer these questions to see what your organization is all about.

Engineering effort, integration, user experience

[00:15:10] Next is no versus ongoing engineering required. Some products, and mostly these are products that are integrated with your products, like you have to get data in or things like that, you will have products in the same category that you integrate once, very simple integration, and then everything else is done by someone that is not an engineer. Where other products, you will need an engineer on an ongoing basis, creating tickets for them, they have to do something. So there are pros and cons for that, it's not obvious that one is better than the other, you have to look at what is better for you. Some of it is what is the effort for you, for your team, to implement it. And another thing is what type of controls do you give on that, because sometimes when you don't have this engineer in place you have less control actually. So you have to look at both things.

[00:16:06] Third criteria, integration with other products. This is quite obvious: how does it work with the ecosystem, what ecosystem do they already have, what type of effort do you have to do in order to make that happen, what does it integrate with, the systems you have today. But one of the other things that sometimes I'm looking at is how is that company's philosophy about integration? Does the product look like, oh, they just integrated with one or two products maybe 10 years ago and that's it, or do they on an ongoing basis look at new technologies, new things to integrate with, and therefore they're really on top of things? So looking at the product is not — looking at the company behind the product is as important as looking at the product.

[00:16:56] Next thing is user experience. Someone mentioned that before. So how easy is it to use, consistent, modern, intuitive. Modern to me is one of those things where I'm seeing products that look like they were last designed in 1999 or something like that, and I'm like, yeah, I don't think I'm going to use that. So there is definitely that refresh and modernity that you want to look for in there. And then of course accessibility, we're talking a lot about that. And then which platforms you need to support, because you don't always need to support everything. It doesn't need to be mobile always, but if you need it, then it should be.

Security, AI support and company culture

[00:17:35] Next is security. Quite obvious, although no one mentioned it here before. But how secure is this product? Do they comply with any regulations that you need to comply with? And also, what do they do with your data on it? There are lots of talks recently about don't use ChatGPT because now they're using that data of your company to do whatever they do. So this is really, how do they use my data? It's personal data, but it's also your company data, et cetera. So it's really important to look into that.

[00:18:15] Next is AI support. Okay, so here this is like the elephant in the room, we have to talk about AI. It's almost like if we don't talk about it we don't exist, I guess. Many products these days will say they have AI components, they will put some components in there, they will kind of ride the wave. From what I've seen recently, people are saying in our industry we're probably not going to be replaced by AI anytime soon, but if we use tools that have AI in them we probably are going to be more efficient than other people that don't use them. So it's more about the efficiency. But still, ask yourself, is it really required for what you're trying to do? Is that really that important? Case by case, of course, but always have this in mind. You see, I'm trying to be very critical about every one of those points.

[00:19:13] Then the company culture. So this is the company behind the product, what is their culture? Like I said, this is as important as the product itself. So I'm looking at two things. The customer support and success: are they responsive, are they helpful, is there any self-serve or do I always have to contact them, what are other people saying about them? I guess no one here buys anything today before they look for reviews online, so why buy this without reviews from other people? And for that you will need to contact support and see how they interact with you before you make a decision. So you will see it later on as part of my recommendations, when you implement.

[00:20:00] And then the second thing is sales and marketing, not less important. Some products, there is not a lot of sales and marketing involved in that because it's very self-serve, product-led, et cetera. But others there is a very lengthy, an enterprise B2B product, so you will interact with them. Look at how they interact with you. Is it, do they look for their short game of like they need to sell, sell, sell and get their quota, or is it about a long value that they're creating for you? And with that, when I'm saying product-led I don't mean specifically for the growth, I mean do they have the same focus within their internal company about how they grow, about product-market fit? Do they focus on the product, or do they just focus on getting the next client?

Price and feature comparison

[00:20:55] Price. Of course it should be there, but you see, I don't think it's the most important, it's just the first thing we go into. Here you want to consider the cost, the free tier that you can test it on, et cetera. The return on investment. And I think I mentioned also before, not just the price now but in the future, how can you grow into it. I've been in situations where the same product, because the company grew so much — the company of the product that I bought grew so much and they added features and modules, et cetera — it becomes very, very expensive as time was going by. So when you are getting a product in a company — oh, I have to rush, okay, sorry — so look into that, it's extremely important.

[00:21:47] Okay, feature comparison. That's one of those things that, you know, that's what we usually start with. If you remember in the first flow, we compare things. But when we compare it we should really look at the limitations, and how much it's going to cost me more if I use this one or this one, because sometimes it's tied with the price and level that you're doing.

Testing and implementing

[00:22:13] Now, the next two steps are actually quite simple, testing and implementing, but I also included a couple of flows for that, because why not. So very simply, define your test cases, what success means for you. Test at least two products so you can compare something. I usually test three if I can, maybe sometimes more. Contact the support so you know who they are, even if you don't have any questions for them, still do that. So ask them questions and see how they interact with you. What are their SLAs, are they quick, are they responsive, do they try to help you or not, is it a machine, is it a person, et cetera. Compare the performance, and not just speed or stuff like that, but between the different features. And then make a decision. I created a couple of tables for you for that, so it's in the Miro board, for the test cases and for the support.

[00:23:10] And implement. Again, a flow, why not. It's very similar to what we do anyway in product management, we just apply it to those products that we're choosing. So define your scenarios, prioritize which scenarios you want to implement first, because you shouldn't really implement everything at the same time, because probably it will not work. So be agile about this. Implement it, always, always include your stakeholders in this, because otherwise communicating and training users will be a huge hassle and they will probably not really adopt it. And why choose a product and implement it if no one is going to use it? That's where I see most implementations fail, with people don't use it. And then monitor it and reiterate on that. So, does it work, what we're doing, do we have to change things? Keep it kind of a live thing, so you will get better with a product. And of course there is a table in the Miro.

What happens if you choose wrong, and turning the method around

[00:24:18] So what can happen if we choose wrong? I think that maybe I should have started this at the beginning, but because you saw such a cumbersome big flow with lots of process, maybe we should also answer this. So you can have wasted time and efforts, obviously, you chose something wrong. Weak buy-in: again, people don't want to use what you chose. Locked into a bad solution: so imagine, you will spend all of this time, you started using something and you got kind of locked in, what do I do now, it's not the best one for us. And expensive maintenance, there is always that. It's not only about the first initial cost or the license you get, but it's also the ongoing maintenance of that.

[00:25:06] Okay, now I want to turn this around and ask you this question. As product people, can we use the same methodology to reverse engineer our product with our competitors and see how our clients are going to use the product they will use? They can apply the same processes exactly. So if they can apply the same process, then we can apply it too for our product, to see where are we better than others, where are we not, what can we do to make it better. Make sense? I'm not going to answer that, because this is a question for you.

[00:25:44] So thank you very much, and here is a QR code that I promised. I hope this will stay for a few seconds so you can — here, let me move so you can scan that. It will have a link to the Miro board, to my website, to the podcast — we just released today a new episode — and to my LinkedIn. So please feel free to connect with me, I will connect with anyone. And that's it, thank you very much.

Q&A

[00:26:19] Host: Thank you so much, Moshe.

[00:26:24] Moshe: My pleasure.

[00:26:24] Host: Wonderful talk, and hope you have a wonderful evening tonight with the family. I think there's a lot of takeaways, whether design or product, just a lot of things you can think about in your toolkit. Are there any questions? We'll throw our little friend around if there are any questions. Okay, there's an easy one. I don't know what I'd do if I was up at the top.

[00:26:54] Audience: Hi, thanks for sharing. I have a question: how do you think about designers and developers being involved in those requirements, product management process, specifically for choosing a product for something they will use? Especially identifying problems and prioritization, those things. Do you think designers and developers should also be —

[00:27:20] Moshe: Absolutely, yes. Both when we develop our own product, but in this process especially, if they will be some of the users of that. So if we're choosing our next project management system or a board, or roadmapping, or whatever it is, usually developers definitely will use it, designers will use it also for some of their stories, depending on how you build up your stories, et cetera. But they are stakeholders in this, so absolutely. Stakeholders are — I can't emphasize it enough, even though I don't think I mentioned stakeholders here, so that's why I want to make sure I'm saying that.

[00:28:04] Audience: Sounds good, thank you.

[00:28:06] Host: Any other questions? One over there, yeah.

[00:28:18] Audience: Hey, thank you for your talk. My name is Brian, I really appreciate all the information you provided. My question is regarding implementation and the adoption process. No matter how good a product you choose, there will be someone that's not happy about it, whether it's one or a hundred people. What is your advice on some folks that might have some pushback with the product that you chose?

[00:28:43] Moshe: Yeah. I will try to identify them as early as possible and get them involved in the process as early as possible. So like any stakeholder that you might have the same problem with, similar to that, those types of users. It's hard sometimes, depends on the size of the organization and the culture in the organization and all the different things that work there, the politics and whatever it is. But that's why the skills to choose a product and implement a product sometimes are kind of acquired as you go and do it. It's not just a project management process, it's also really understanding the users. So it's like many other things that we do as designers or as product managers: if we build empathy for our users, let's build empathy for the users of this product, et cetera.

[00:29:40] Audience: Thank you.

[00:29:42] Host: I have a question over here from the internet. Mita[?] Voice says, how do you help influence key stakeholders that may be hesitant to switch over to a more efficient tool or product?

[00:29:55] Moshe: Yeah, stakeholders are always hard. Part of it is really creating the business case for that. So is there data about why a new product will be better than what we already have? And also understanding and really talking with them one-on-one, that will always be a better case there, to understand why they are against it. Is it because of past investment that they've done and therefore they were fearful of wasting all of these things that they've done in the past, or are there other things they were afraid of? And then see, okay, so how can I switch it around and create a story that will be able to sell also to those hard sells.

[00:30:52] Host: Good time for one quick question, if it's right over there. Raise your hand so we know where to throw it. Oh, behind, yeah. Did it fast. There we go.

[00:31:11] Audience: Hello. Hi. I'm curious, what do you see as the future of products? You did mention platforms, and currently there are a few platforms but then there's a lot of single products and silos. How do you see the industry evolving in the future, a decade?

[00:31:29] Moshe: Very, very good question. At the end of the day it will be depending on us, what is it that we like, or most of us like, that's how I think it will happen. I actually like those platforms that do it all, because I prefer everything is integrated, I don't need to think about too many things. But that's me. When I interview people for the podcast, I've seen that it's kind of split. Some people like the one-off that does it best, and some people like the one product that does it all. So it's hard to say. There is definitely a lot of products coming up. I actually added to the list two products yesterday in the back there that I didn't have on that list, so now they're there, because I didn't know about them. So there are new products that are coming up all the time, which means there is still a need there.

[00:32:23] Moshe: Some of it I think will consolidate, but even the companies that have in the past done one thing — for example Amplitude, they've done just product analytics — they already expanded into other areas in the last couple of years. So I think that what companies are seeing is that they want to expand the reach and the users and give them more power and charge more, so they add more adjacent products, some of them by development, some of them by acquisition. So it seems like this is where the world is going to. And probably a lot of the small ones that are startups now will be acquired by some of those in the future.

[00:33:11] Host: Thank you. All right, Moshe, thank you so much. Give them a round of applause. Thank you very much.