In this Dear Melissa segment, Melissa answers subscribers’ questions about product best practices relating to MVPs, nonprofits, and customer behavior.
Show Notes
In this Dear Melissa segment, Melissa answers subscribers’ questions about applying product practices to nonprofit companies and customer engagement and debunks myths about MVPs.
Q: How applicable are product best practices and principles outside of for-profit SAAS companies? [1:08]
Q: Do you have any suggestions on how we can encourage our users to experiment with the new payment method our company introduced? [6:32]
Q: How do I advocate for a more iterative and incremental approach to new product releases and product updates, as opposed to big bang releases? [10:34]
Resources Melissa Perri on LinkedIn | Twitter MelissaPerri.com
Episode Transcript
Hello, and welcome to an episode of Dear Melissa, from the Product Thinking Podcast. The lines are now open, and we're ready to answer your most pressing product questions. Which prioritization framework would you recommend and why? Hi, Melissa. Do you have any suggestions on developing a product strategy?
Whoa, whoa, whoa, whoa, whoa, whoa. That's a lot of questions. All right. Let's dive in. Hello everyone, and welcome to another episode of Dear Melissa. Today we've got three very interesting questions about using product best practices and applying it in different situations. So let's dive in and start to take a look.
Our first question, Dear Melissa, I'm a huge fan of ETBT. Never heard anybody abbreviate Escaping the Build Trap that way, but I love it, and have read and loved most of your public articles and podcast episodes. Thanks for producing and collating so much valuable information. I'm working on growth at a nonprofit that helps people find impactful careers solving important problems in the world.
My question is, how applicable are product best practices and principles outside of for-profit SaaS companies? Internally, we're playing a game of reference class tennis at the moment. I think many of the principles you discuss would help us build more impactful products and grow faster, de-risk product decisions, et cetera.
Others are more hesitant. As we developed for tech startups who are maximizing profit, not nonprofits advocating for social change. Really great question. So I think there's one thing to remember. No matter what business you are, whether you're for-profit, whether you're SaaS, I've done product best practices in banks and healthcare companies, lots of different things around the world.
The key here is that every single business has a North Star, even if you're a nonprofit. So if you run a for-profit business, usually your North Star, the thing that everybody wants to do is make money. And hopefully you have some kind of other goal that's not just make money, right? You have to have guiding principles or values or the way that you want to make money.
But at the end of the day, it's usually make money. Now, a lot of for-profit businesses will not tell you that is their goal. I worked with a healthcare company doing a workshop a couple of years ago, and they kept telling me like, oh, that's not our goal. But honestly, if you looked at every single public decision they made in the market, it was, that was their goal to make money.
If you're a nonprofit though, you don't have to be tied to just, you know, making money, which is great. You have some kind of other goal. So if you, for example, if you're a nonprofit that was helping to bring like computer science education to underserved populations, I might use something like number of people who go through our program and land a computer science job as a North Star metric.
If you're a nonprofit for like leukemia, I might look at something like the number of clinical trials we can fund per year to advance the treatment of leukemia. Maybe long-term, I look at number of lives saved from the funding of treatments. That's something that I'm going to have to measure over a long period of time.
But at the end of the day, product management in any type of company is about creating solutions that help you maximize your ability to reach that goal. So you want to figure out what are the software solutions that we can build that will help us get there. When we look at for-profit businesses, it might be a little more black and white to manage costs and to manage revenue.
For you, you're basically just taking away that other level. Your North Star is something that's way more mission-driven, which is totally fine, but it should be measurable. It should be impactful and it should be something that you've come back and look towards. So when you think about product management, all the best practices that we do recommend, like figuring out what is the problem that we can solve, coming up with a great solution that meets our customers' needs, iterating on that solution, trying to figure out how to skill that, they all apply to nonprofits as well, right?
That's why you exist, to solve a big problem in the world. When we do a for-profit business, we kind of extrapolate our mission one step further and say, and hit that mission and make money. You don't have to do that. You could just say, hit that mission, right? Hit that goal, which kind of streamlines it a little bit more, but doesn't make it as black and white.
I can evaluate options in product management for-profit companies and say, what's going to make us more money? What's in line with our mission? You don't have to go that way. You're going to want to really make sure that you can have a concrete Northstar metric that you can judge which solution is going to be appropriate for.
But I do believe that you can use all the same best practices that we have been talking about to help reach those goals. And honestly, if we did a little bit more of that in the nonprofit sector, maybe we'd be having more impactful solutions as well. So is it going to be like an absolutely cookie cutter, A versus B, take what you did in for-profit and just slap it on a nonprofit?
Absolutely not. I don't think you can do that with many different types of businesses. The way that I'm going to operate in a SaaS company is going to be different than the way that I operate in a bank because a bank is not a SaaS company. So same thing for nonprofits. The way that you operate with a nonprofit is not going to be the same with the for-profit, but you can still use many, many of the tools.
You just have to refine your goals. And I think that is the key in any type of business. Refine your goals. Think about what does the solution mean to you and what's your mission? And then use those practices of understanding problems and empathizing with your customers and figuring out who your users are, and then work your way towards solving those problems with great solutions.
I think that's really all there is to it. But like everything, you know, I always say this when everybody asks, like, are best practices meant to be just followed blindly? Like, no, pick and choose what's going to work for you and refine stuff. If some stuff doesn't work for you, or you're like, there's absolutely no way I can apply this.
Well, at least you tried, and that's okay. Throw it out. Use something different. I think the more we get used to refining our own practices to fit our situation, the better we're going to be. I don't think you should blindly follow any kind of formula or method without really thinking about how to inspect and adapt that to your situation.
But I have worked with nonprofits in the past as well. And what we've done is just take that North Star metric, it's not going to be profit. We still want to manage towards costs usually to make sure that we can run our nonprofit, you know, efficiently, but our North Star goals and the things that we're creating solutions around are just going to be different.
It's not going to be for profit. So that's what I would really look at when you're evaluating what to use and what to leave when you're looking at the product management best practices. All right. Our next question. Dear Melissa, I'm loving your podcast. Keep up the good work. Thank you. I'm a developer based in Portugal, working at a small startup.
Our product helps nutrition professionals do their work. One of our last main releases was the addition of a payment method by integration with Stripe. Previously, our professionals could do all of their work on our platform, but their patients had to pay them via other methods. The problem is that this feature had very little adoption.
We got some really good feedback from some professionals, but our expectations were much higher. Do you have any suggestions on how we can encourage our users to experiment with our payment method? So I think you have a classic case here of needing to figure out what are your customer's customer's needs are and what they're doing.
So it sounds like you looked at the, and I could be wrong, you may have done some of this user research, but this is what it sounds like to me. You said, hey, everybody can do everything they need to do on our platform, except take money. Some people express interest in taking money. Let's integrate Stripe and let people do payments through our platform for their services.
But there's probably a lot of questions around why people aren't adopting this. So here's my suggestion. Go to the source, right? Like go to your customers who are the nutrition professionals, right? And then try to figure out how are they being paid right now? Are they taking PayPal? Are they doing credit card payments outside of the platform through Square?
Or are they using cash? This is one of the big things that I think you have to kind of understand too, is what types of entities are your customers? Are they small, little, you know, solo entrepreneur nutrition professionals? In that case, cash might be king in this scenario. They might not want to take credit cards.
In the United States, we have a lot of small businesses that do cash, so they don't pay taxes. I'm not advocating for that, and I'm not telling you that you should not pay taxes. I'm just saying that's literally why a lot of people wouldn't use something like Stripe or a credit card service, and why I've seen a lot of small businesses not take on payment services that were integrated into these other platforms.
So here's what I think you need to do. Go to your nutritionists, sit with them, maybe shadow them while they're taking care of one of their patients and seeing what happens when they transact at the end. Are they asking for cash? Is this person trying to pay through Stripe? It could be, you know, they don't like to pay through credit card or through Stripe.
It may be that you have a complicated checkout process that people don't quite understand. There may be a lot of reasons on here, but I don't think you're going to learn anything without going to the source and watching how this happens today, and then trying to understand their reasons for it. A lot of times our customers are going to tell us, yeah, that sounds like a great idea without really fully thinking through, you know, how they would work with stuff in real life.
They don't want to disappoint us, especially if we're building something for them. So they'll say, yeah, it sounds great to have payment services. Stripe is cool. Fantastic. But in reality, they haven't really thought about how they would like to transact or why they take the way the cash or the other payments that they do today.
So I think you need to really figure out how your payment system is going to provide so much more value to them over what they're currently doing, because that's the only way you're going to get them to flip their behavior. If you want to change somebody's behavior and get them to adopt your solution, it has to solve a problem for them. And what you interpret as a problem may not really be the problem, right?
They may not have a problem with the way they accept payments today, or they might have a big problem with the way they accept payments today, but you're not solving it correctly. And I think that's what the problem is in this situation. You don't really, really understand it. So it's not just encouraging your users to experiment with your payment method.
It's deeply understanding why are they relying on the old ways that they collected payments? And what can you do to solve their problems, if they even have any, with the current way they accept payments? Maybe they don't have a problem. Maybe there is no problem to solve, and you're just over-engineering this.
That's my advice there. Go to the customer. Sit with the customer, understand what's going on with the customer, and figure out how they do it today. All right, and here is our last question. Dear Melissa, the company I'm working for has historically put a lot of emphasis on Big Bang releases for new products and product updates.
When I advocate for a more iterative and incremental approach, I'm often confronted with the argument that if we release an MVP version of Feature X, our users might not accept it because it isn't finished and is lacking all the sophisticated details. If we screw up the initial release, they won't give it a second chance, and our brand reputation might suffer. I personally do not believe this, but I find it hard to have a constructive discussion because I can't find supporting evidence on the subject.
What's your take on this situation, and how would you approach the conversation? Oh my God, I hear this literally all the time. And especially when I first got started consulting, I specifically would go in to help people build MVPs. And I always thought it was amazing that they wanted me to come in to help them learn how to build MVPs, but nobody wanted to build an MVP for the same arguments you are facing here today.
But I will tell you that we did succeed. And the reason for this is because I would tell them, I don't want you to build a crappy MVP. Like I had this one company, right, that thought, oh, you know, an MVP is just like a button to nowhere, or it's a half-finished solution, and it doesn't look good, and it's broken, and it's awful.
And that's not an MVP, right? Like I don't advocate for releasing crap, like that's not what an MVP is. And nobody has ever said that. I think people who misinterpret what an MVP is are the ones who have done that in the past, and they've ruined it for all of us. So thank you very much, anybody who's been screwing that up.
But let's actually define what a good MVP is. I've always subscribed to the notion that an MVP is the minimum amount you need to build to learn. That's always been my definition, the minimum amount you need to build to learn. So this can look like various levels of fidelity. And the rule that I always teach people is that the more people you plan to test with, the more people you plan to expose this to, the higher the fidelity needs to be.
So if you want to run an MVP kind of like concierge, or Wizard of Oz, or do some research with people, those are all low fidelity things. You're only going to do that with a few people. You're not going to scale that to hundreds and thousands of users. First of all, it doesn't scale. MVPs were not designed to scale.
That's actually the antithesis of an MVP, solution scale. But MVPs are for testing, they're for de-risking, you're supposed to keep it small. So what do you do? You go out and you curate a group of beta testers who are going to be your people that you test the MVP with. So if you were in a large enterprise, it may only be 10 people from different companies or different places.
It might be 20 people, but it's going to be a small subset, it should not be like half of your users. So you want to get that small group in, but you're also going to tell them it's a test. You're curating them, right? You're telling them, hey, we are planning to solve this problem for you. And we think we have a solution that might work.
And I really need your feedback to be able to tell if this is the right way to go or not. So you want to incorporate what you think into the solution and you can help us make it awesome for you. But the catch is, it's not fully done. So what I'm about to show you is not completely baked, but it's an idea and I need you to tell me if we're on the right track, because I think this will help.
And if you do that, most users and most customers get it, you know, you have to preface it that way. If you just show them something in the middle of their flow while they're using the product in production, like they're going to get confused, they're gonna be like, what is this crap? Like, what did you just give me?
So you have to design a way to have a subset of people that give you feedback. So I used to build MVPs or help people build MVPs for very large companies, banks, investment companies, healthcare companies, like we built this for doctors seeing patients. And that's what we did. We curated a group of users who knew that they were giving feedback on something that was a test, right?
That was a proposed solution, but not a final solution. So when they saw something and it didn't look absolutely perfect, they went, oh, okay, right? And they knew they weren't going to get it tomorrow as well. And that gave us a lot of feedback. So you need to start small, you need to really focus on getting feedback on the specific thing that you're trying to de-risk.
And that could be the problem, it could be parts of the solution, it could be the way that you're delivering the solution, hone in on the thing that you need to de-risk, cultivate a small group around it, communicate to them what's going to happen, and then really test it with them and get that feedback to make it even better. And then when you really do the solution, right, you can start to roll it out into small groups and test it before you do a big bang release to everybody. It's going to be very different than big bang releases.
And that doesn't mean that, you know, this is going to screw up your marketing or something. I've heard that from companies too, it's like, well, we got to do a big flashy marketing thing so we can't MVP. No, you should not be marketing the MVP. Like you should be only doing that with a small group of beta testers.
And one of the biggest arguments I always got with MVPs was like, well, Apple didn't do this. And that's, you know, frankly, just wrong. Apple does this stuff all the time, but they have everybody signing extensive NDAs to not tell you about it. You know, they're not giving away their secret sauce. They test things like crazy.
But when they know they got something good, that's when they do that big splashy release where everybody gets up on stage and they're like, wow, this is really cool. I never knew my watch could talk to me. So that's what you have to do for your MVPs as well. That's what we should all be doing now in B2C.
Sometimes I see companies just like throw out like a half-baked MVP to a wide array of users in an A-B test. And I don't think that's right either. B2C, you might get something more polished and have an easier time like segmenting your audience and testing it to see if it moves needles, especially if it's e-commerce or something like that.
It's a lot easier to do that. But at the same time too, you don't want it to be broken then, right? Like it shouldn't be a half broken piece of thing that you're going to release to a wide array of users and not tell them it's a test. This still applies for B2C as it does to B2B. You just really have to make sure that the fidelity that you're building justifies the test that you're actually trying to run in the thing that you want to learn.
So that's the biggest issue. Like a lot of companies do testing like this, a lot of them. And a lot of the Silicon Valley companies everybody likes to look up to, this is how they run it. This is how they test things. This is how they get feedback. They talk to tons and tons of users and customers. They tell them, this is what we're thinking.
This is what we think about the solution. What do you think? And they get feedback like that. So I think if anybody's scared that the MVP is going to cause users not to accept it, tell them they're building it wrong or they're thinking of an MVP wrong. And then really refine it and build down a smaller group of beta users so that you can test with them, get the feedback that you need to move forward and build a full solution that you can make a nice, pretty splashy launch with.
And it will feel like a big bang to your users, but it won't be because you have already risked it. That's the way that you got to run MVPs. All right, that brings me to the end of our Dear Melissa segment for this episode. Make sure that you submit all of your questions at dearmelissa.com. I'll be looking there to find out what we can answer for you next week.
We've got lots of great episodes coming up on the podcast. Our next podcast is going to be with Jeff Patton. Jeff and I have been friends for a very long time, and he's going to debunk all these myths about Agile, which I am super excited about. So make sure that you tune in next Wednesday to hear Jeff and I talk all about your misconceptions with Agile.
And then in the meantime, go to dearmelissa.com and submit those questions.
