Perfection Versus Launching Your Product

Episode 5

In this episode, Scott and I will be talking about the trade off between spending time to perfect your product and getting it launched.

Here are some items discussed in today's show:

Thanks for listening to this episode of The Stretch Goals Podcast! We'd love to hear your thoughts on this episode and answer any questions.

Find us on Twitter @The_Scott_Davis or @RobDickersonJr

Transcript

Robert: In this episode we’ll be talking about the trade off between spending time to perfect your product and getting it launched.

This is The Stretch Goals podcast where each week we’ll share insights and lessons learned based on our experiences as entrepreneurs. We’ll challenge you to create ambitious goals as you start and grow your business. I’m your host Robert Dickerson.

Scott: I’m Scott Davis.

Robert: When I think about product perfection, at least for my own products, I think about how our products exceed customer expectations, and solve their problem in a clear and simple fashion. It’s a product that I’m proud to put my name on, and put out there into the world. Essentially these products are glaring omissions, problems, that might hinder their usage or adoption. The problem lies in the distinction between how we as founders, and leaders, view perfection of our products, and how our customers view it. Sometimes in search of product perfection we can continually delay launching while we’re tweaking and fix bugs. I know this is a problem that I come across all the time. Evaluating whether or not this new feature, or this new bug, is actually something that we should delay launching our product to fix.

In this episode Scott and I are going to talk about some strategies that can help you push through perfection and get your product launched. Scott I’ve thought about that we could start out by focusing on defining and solving your customer’s problem, because I think that’s really the first step in identifying whether or not you should launch your product. Then we want to talk about putting together MVP and agile development, and some of these other techniques that are really good about helping you evaluate whether or not your product is ready to launch. I think it’s important as we talk about these things, is that you want to get your product out there quickly, you want to continually iterate. Talk a little bit about the iteration, the agile approach, and things that you have found that work well to help you force getting products out there, getting in front of people, even if they’re not perfect.

Scott: Sure, like you said, these are things that come up, software products, physical products, whatever. The iteration process is always ongoing in any business, right? The question becomes, how do you know what features you ultimately want, and which ones are going to be important, and all of that good stuff. From the software development standpoint, we’ve got the agile process, or whatever you want to call it. Where you’ve got a backlog of issues that sort of pave your road map, but the problem is when you’re trying to get to launch, how do you make the decisions to get to the key items that you really want to put out there in front of your customers. That’s really where a lot of people struggle, you don’t necessarily know where, or who, your customer ultimately will be. You could put it in front of your intended target, and turns out that it’s not really them, it’s going to be somebody else. From your perspective with what you’ve done, how have you addressed these issues?

Robert: One thing I want to just talk about real quick is that launching doesn’t necessarily mean your first release, right? It could be any release. Sometimes the first release is the hardest to get out there. I want to talk about that a little bit, because I think as it relates to the products that I’ve put out there, that first release is a lot of times the hardest release.

Scott: It is, yeah.

Robert: Because you want to put your best foot forward, and so you want to make sure that the whole experience is really clean, and that you’ve addressed any glaring problems. Sometimes, for me at least, as I’m going through the backlog of issues, it’s like, oh all these things, we got to fix, and so it continuously delays moving the product forward. I think at some point you have to look at what you have, and say … The thing that I’ve found that works well is to take out features that you just have to say, “Okay, this feature set is not going to be in this first release.” You just take it out, and so that removes a bunch of issue off the table.

Then you can take what you have, and you can put it out there. I think it’s important that you don’t necessarily worry about that you fix every little problem. That you have, maybe, at least a solid foundation to build off of, even if there are little issues. There’s always going to be issues. Especially, I think we’re talking more about software development there, there’s always going to be issues, but even any type of product, there’s going to be problems. There’s going to be things that you have to evaluate. You have to decide whether some of these problems are big issues. If you think about Samsung with the Note, right? That battery problem was a huge issue, right? They had to …

Scott: Right.

Robert: … take a huge loss, and they can’t sell the Note any more. Things like that, you know, you need to balance against maybe just a tweak or small bug in something that maybe no one will ever see. Scott: Yeah, you know, here’s the thing, right, most of the time we focus on this first impression of our software product, or our new whatever product. We’re so fixated on this idea that it has to be perfect at first sight, love at first sight, whatever. Throw that out the window, because here’s why, 99% of the products that are launched everyday, are not viral day one. They just aren’t. As much as we want to think that we have the greatest product in the world, that we’re going to have five million users on day one, it’s not going to happen 99.9% of the time. If that’s the case, why do we focus on perfection then? Let’s get a product out there that proves a concept, that we can get feedback from, that shows who are, and start building the brand, start learning what our customers really need, so that we can then be perfect when we start getting that exponential growth curve.

I don’t necessarily want to have a bad experience, I don’t want a bad app review one of my apps in the app store, but the bottom line is, if I’ve got 20 users today, and I’ve got five million in two years, those five million all the reviews that they’re going to be posting, is going to wash this one or two little one stars out, for people who just don’t understand what I’m trying to build. For me, perfection doesn’t need to be a day one goal. You can ask my wife, she met me, I was sloppy when she met me, so you know, it held true for me in daily life as well.

Robert: Yeah, no, I think that’s a really good point is that those first couple people that use your product and give you a bad review, that doesn’t necessarily mean that your product is a failure, right? From all the products that I’ve launched, no one comes. You launch to silence, unless you have a large audience that you’re launching into. Most people don’t care, and they don’t have time to look at it. I think that’s a really good point that you make there, is that you shouldn’t really worry too much about it to start, and just focus on continuously improving each day, and continuously getting things out there. I think, you mentioned this before, getting the customer feedback, and under … Using that feedback to continuously improve your product.

Scott: Absolutely. I think as someone who, I pride myself on being an early adopter of pretty much everything, maybe stupidly so, but what I like to see is I would rather have a product that didn’t meet my expectations initially, but you see how the company responds to that, and tries to make that product, and that relationship with you right. For example, like Samsung, when they found out that these batteries were dead, they didn’t say anything for weeks. That’s a bad sign right there, but if they were immediately like, “Yeah, you know what? Send us your phone, we’ll replace them for you ASAP,” and then it turns out that the replacements are bad too. If they just handled it differently, “Hey, we’re going to give you a free Note 6,” or whatever, I don’t know. The point is, you can sort of learn a lot from the company.

I would rather see an app that was like wow, this could have been really awesome, and I’d give it a one star, but I keep it on my phone. Then I see an update a couple … maybe every week, or every two weeks, now I see that this company cares about what they’re building. Now I’m engaged, and I’m watching. I’m trying to see like, “Hey, where are these guys going to take this thing? Have they fixed the bugs that were annoying me?” You feel a part of that process if you get in at that phase. For me, that’s kind of what I do, that’s how I expect, as a consumer. At the same time, that’s what I do as a provider of a service and a product. I try to constantly put out new releases that fix lots of things from user feedback, but also from my own roadmap and goals, for the product.

Robert: I think too, if you’re solving your customer’s problem, they’ll overlook …

Scott: Absolutely.

Robert: … maybe some poor things about the product, right?

Scott: Absolutely.

Robert: They need it so badly to solve their problem, they’re willing to overlook those warts, and those bugs, that might exist, and so you have time to fix those things.

Scott: Sure, and every great brand has that same problem. Nike, they had their first shoe made out of a waffle iron with rubber poured into. Surely that thing fell apart in a week or two, you know, but they loved the shoe. Well okay, well we’ll look past this. Next time you give them a shoe it lasts four weeks, and then it’s six weeks, and now we’ve got shoes that last three years. Every product goes through this, every product.

Robert: Yeah, I think about with phones, and even Apple does this too, with Apple TV, they launch it with a really minimal set of features.

Scott: Yeah, yeah.

Robert: They’re just continuously building on it over time. Those features work, but they’re just a very minimal set. That’s another way to think about launching, is just launch with a core set of features that work, and then keep building on that, keep iterating on that, even if it’s not perfect to start out with.

Scott: Yeah, and I don’t want to get too off topic with the outline that we have for the podcast, but the thing is, when you start looking at larger companies like Apple, and Microsoft, and Google, and all these guys, there’s like this sort of bisection of the company where sometimes they have a product that they just kind of put it out there and see what happens. Maybe Apple TV is a good example, like perfected the hardware for years, they spent years perfecting that hardware, and then it was out of date, right? Don’t get me wrong, I love my Apple TV, especially the new one, but then they just put the software out there, and then they iterated it like you said. They gave you constant updates, and every time you’re like, “Oh man, it’s a great new feature, now I’m going to go back to it.” That’s a great example of it. On the flip side, when you start looking at the iPhones, and operating systems, and things like that, these are processes that they don’t cut corners on. They are so specific about perfection at launch, and they have to be, especially when you’ve got hundreds of millions of users on day one, and stock prices, and everything.

There’s something that has to be … We as consumers expect perfection, but we’re not mega corporations that are worth five billion dollars, right? When we’re talking about building products, we need to keep that in mind, that we don’t have the time or the money to be perfect. We want to get it out there, we don’t want to be an Apple or a Google, who do have time, in most cases, to perfect their products.

Robert: That’s true, they have large teams, and they have time to spend, a lot of money to fix some of these things. I think it is still, there is still a scale issue there, because they still, I’m sure, have a huge backlog of things they want to fix.

Scott: Absolutely.

Robert: I mean even Microsoft, you think about Windows. There’s just tons of issue there to fix. While the scale is certainly different, I agree with you too, that for individual founders, or founds of small teams, you want to think about how you get these things out there as quick as you can. I think it’s important too, you mentioned that these first beta testers, and you like evaluating products like that. I think it’s important to get people that are beta testing, that have that mindset, that understand that this is an initial product, and they’re able to give you feedback in that light. They’re not really, maybe, honing in on really specific things, or really specific features, they’re kind of looking at a broad view, and able to provide you that feedback, that you can help bring other people on.

Scott: Absolutely, and if you get beta testers, try to get a wider array of testers, because … A large demographic, because especially if you’re a software developer, right? You’ve got people of different mindsets. My dad is going to react to an app differently than my niece, you know? My niece is probably just going to get it, but my dad is probably going to go, “Where do I click?” Getting different perspectives help you, ultimately, smooth out your reception of your product if you’ve got a good demographic covered.

Robert: Yeah, because they’re going to have different expectations about how to use things, I’ve always found that people will use things totally different than the way that I use them as the creator. I had a certain workflow in mind, and so I’ll continuously go through that same workflow, and then someone else will try it a totally different way I didn’t expect.

Scott: Right, and …

Robert: Either find issues, or be confused about the process and the workflow.

Scott: Yeah, and if you look at companies like SnapChat. When SnapChat first came out, their interface was horrendous, in a lot of cases it still is. I downloaded SnapChat when it was number one in the app stores, years ago. I just didn’t get it, I thought it was horrible, I thought it was not well done, so they completely disconnected me. The only reason I even use SnapChat is because my friends were like, “Hey, come watch my SnapChat story.” I’m like, “Okay.” Then you get use to the interface after somebody shows you how to do it, or I Googled stuff, “How do I do this in SnapChap.” That’s an example of they defined an interface that was very specific to a very niche amount of people, younger generation, who is more exploratory with their interfaces. Completely alienated me, but then it went viral. You can’t hit every target, and SnapChat, in their case, they didn’t care, and it worked out for them. That’s not always going to be the case for every startup, and every product.

Robert: If you’re … As you’re getting started, and you’re thinking about your own products, I think it’s important to set some milestones in order to launch, and figure out what stages, what features, make up certain releases. That way you have a clear understanding of what needs to be in the product in order to launch. Then you can set deadlines around those milestones, and get it out there. We’ve talked a little bit about an agile approach, and putting together an MPV, and really iterating over those milestones, and figuring out when you need to launch. I think those milestones can change, and the features within those milestones can change, as you get more feedback from your customers. That’s okay, right? That’s okay to move things around, it’s just figuring out, “Okay, when I have met all these different things, I know I need to continually get the product out there.”

Another thing that you could do is just continuously launch on a every two week basis, or every week basis, maybe even more frequently than that, but just continuously push things out there. That way you won’t be limited by trying to make a decision if it’s just, “Hey we’re going to launch this week every day on Thursday,” or something like that.

Scott: Yeah, and a couple things based on what you said. Number one, I’ll touch on that last thing. If you’re constantly iterating, when it comes to discovery of your product, and search engine optimization, constantly putting releases out there is actually exceptional for this, because especially if you like the app store for Google Play, or iOS, every time you have a release, there’s a new release that’s categorized, and archived, and is now searchable, and discoverable, historically. That helps your organic search discovery. Same thing applies to websites and other products, right? Every single time you have a new version, you got release notes, that’s immediately discoverable, and indexable by a search engine. This is a slight tangent, but it gives you a little bit of context into those added benefits to doing iterated releases. The seconds part, what you commented on, having a product vision, and these milestones, as a certified scrub master this is what we call a backlog, a product backlog.

To anybody what this means is we need a list of feature that we want in our product. That just, should just, come naturally, right? Every time I’m working on something I’m writing notes, or making mental notes, on what needs to be in the product. You need to write these down somewhere, because you will forget. These will ultimately become your roadmap as you expand on those ideas, and get feedback from users, and create new features you’re going to then have three other tasks that sort of spawn off that core idea, so write these things down. Get a Trello board, get on JIRA, pick your own tool that you love, and get these tasks, and items, and product ideas, all in one place, where you can use those as your milestones. Turn them into actionable things for your product that you can shoot for. Then get a team together and start building it.

Robert: How do you tell the priority of these different things?

Scott: Yeah, great question, great question, and that’s the hardest thing, right? That ties back to perfection of the product. Obviously if you are the business, if you are the CEO, or the product owner, or whatever your title is, you set the priorities. The priorities shouldn’t necessarily be based on throwing darts, sometimes they have to be, because you don’t know what your customers want, or who your customers are. You need to set the priorities based on feedback, based on your gut instinct, based on any number of factors. If you’ve got a large bug in your software, and you’ve got crashes that are impacting, say, more than 3% of your user base, probably want to take a look at that, and get that fixed. That should be prioritized accordingly.

Critical new features, things that you can market that are going to get you more discoverable, hit a new demographic, things like that, those would take precedence, but also just hitting key milestones for your company. Let’s say you want to create a revenue, a new revenue stream, well that’s probably going to be high on your list. It may not be the highest, but you want to get it in there, and position right. There’s an iteration process as it pertains to setting these goals for your product, and those are outside of technical things, this is you just setting the expectation of what your product is going to look like in three weeks from now, three months from now, three years from now.

Robert: Yeah, I think it’s important to set that direction, that general direction that you want to go. Then figuring out what features make sense to fix now based on whether it’s a bug, or something like that, that you need to get fixed. It’s just kind of this navigation of where you’re taking the product. As you get more feedback that’s going … That path is going to change.

Scott: Absolutely, and I would suggest setting … When you create these notes initially, create, what I refer to as epics in the software development space. An epic is like an overarching concept. Let’s say you want to be able to pay people directly from an app you’re building, okay? That would be an epic, pay people, something generic. Now you break that down into stories, “As a user I want to be able to send money to my friend Rob, as a user I want to be able to receive money from my friend Rob,” and then you break those down into sub items. Now you have a bunch of tasks that make up those stories, and those stories make up that epic. All this technical jargon really just means set a big goal, break it down into pieces, and then break that down into some more pieces, which are actionable items that can get you to your milestone.

Robert: Yeah, I think that’s really good advice. I think another point I wanted to touch on is that you mentioning continuously releasing. I think that also shows that you’re actively developing, you’re actively working on the product, and I think that is a positive thing for your customers. If you see an app, or you see something that is never updated, people are going to wonder, “Why am I going to use this?” It’s hard enough, especially with apps, to gain traction, but if you’re continuously addressing bugs, you’re continuously engaging with your customers, then people are more willing, I think, to give you the time, and they understand, “Hey, they’re working on it.”

Scott: Absolutely, and I always give priority, and have a little bit of extra appreciation for companies that do that. Two recent ones that stick out Houseparty, which is a video conferencing app, that’s basically like Facetime with multiple participants. Then there’s another video messaging app called Tribe. Both of those apps have done that, they’ve constantly incremented, they both been very high up in the app store rankings lately. Within Tribe you can even send a video to the CEO, and he’ll respond within 12 hours, to you directly. Lots of fun little things that let you know that they care about their product.

Robert: It’s important, I think, as we’re thinking about these things too, is that as you continuously launch, continuously be engaged with your customers. That will help them get through the missteps, and if you’re communicating problems, and things that you’re finding, to your customers, they’re more willing to be acceptive of those types of things.

Scott: Sure, and don’t be afraid to toot your own horn. Send out a newsletter, send out a push notification, create detailed software update release notes. People read those, they’ll help you and your customers feel engaged.

Robert: Well let’s talk a little bit about those first testers, you know you’re putting together an app, you’re putting together a product that you want to get out there. What’s the best way to find those first couple testers? I know with me, I’ll go to other developers, people that I trust as kind of a first step to get their feedback, because I know that they’ll have my best interest in mind, and they’ll tell me exactly what they think, and not sugar coat things. That’s really important to me, I don’t want … If you go show your mom, or something like that, they’re going to be, “Oh this is the greatest thing in the world.” That feedback is not helpful. You need feedback from people that you trust, and you respect, that have been doing this, that can give you that feedback, and tell you like, “Hey, you need to stop, you need to work on this. You need to fix these couple of issues.” Or they might give you some little tweaks, and things, that you can think about down the line. For me, that’s kind of a go, no go, type thing, of getting that really initial feedback from people that I trust.

Scott: Yeah, and so I almost always go to friends and family first, just to get those glaring things that I just didn’t think about, or maybe the color is really bad, or things aren’t aligned properly. Generally friends and family will let you know about that kind of stuff. Or you really missed something, like for example, Rob, I sent you an app that we’ve been working on lately, and you couldn’t create an account. That seems like a pretty big oversight, probably need to get that one fixed. As a developer, when you’re working on software, you test very specific scenarios, and things get overlooked. When I send the app to a developer it’s usually at a point where I feel like most of the nit picky buggy stuff is solved, because as a developer I know that we’re going to be focusing on those types of issues.

For me, developers aren’t necessarily going to be like the greatest adopter of these technologies that I work on at least, because I don’t know, we’re always busy, right? I want a good demographic for my beta users. I want to send it to a friend, I want them to send it to a couple other friends, maybe you put it out there on BetaList.com. Maybe you drop it out on Product Hunt, if you’re really brave, but the point is you want it controlled. Sometimes maybe you have a list of users, 1,000 users, 500 users, that you let them sign up, and give you some feedback, but the initial group, friends and family, trusted developers, people who have done this before in the startup space, they’ve always got good key insight that you haven’t thought about, potentially. Send your app to Rob and I, we’d love to help you take a look at it, anybody like that, send it to them. Get their feedback.

Also, don’t be afraid to put your app out on … Put it on your website, put it on BetaList, like I said. Take signups from people who are potentially interested in your product, for two reasons. Number one, you now have a potential acquisition list for a customer base, and number two, you’ve got people that you can let know what’s going on with the product, and who can jump in as soon as it’s ready to be tested.

Robert: Yeah, I think those are some really great points. I think, like you said, it’s important to get a wide variety of beta testers, because as a founder, as a leader, developing a product, sometimes you can get so ingrained in a feature, or how you expect it to work, that you can overlook things. It’s important to get outsider feedback on those things.

Scott: The great thing about outsiders too is a lot times if you’ve got a friend who knows what you’re working on already, they get the concept, they might even have seen screenshots and different pieces. They may even have used it on your phone before. If you send them a piece of software, or a product, that they already are familiar with, their view of it is going to be a little bit different than somebody who has no idea what it is. Make sure you don’t just send it to people who already know what you’re doing, who are most likely going to pat you on your back, like Rob said. Send it to your mom, she’s going to be like, “This is beautiful.” Of course she’s going to say that, so make sure you get it to people who don’t know what the product is, but might be closely related to you that you can get some honest feedback from. It will be very helpful.

Robert: I think one thing, maybe, a lot of people don’t … A lot of people don’t launch, because they’re worried about the negative feedback.

Scott: Perception.

Robert: The haters, the naysayers, what are people going to say about their products, and so they … Maybe they don’t launch, or they keep delaying. Let’s talk a little bit about that, and how you develop that thick skin to not take those criticisms personally. I guess that’s one thing that I do, is I think about it as this person is not criticising me personally, they’re actually helping me by providing this feedback, even if it is negative, so that I can fix the problem.

Scott: Yeah, look, everybody is Mike Tyson on the internet. Everybody is a troll. They’re going to say things that they wouldn’t normally say. It’s probably not going to be very nice if it’s a negative review, but there’s also constructive criticism in there. Sometimes you’ll get one or two star app review, and it actually tells you something very telling about your product. Not all of them are going to be like, “This app sucks man,” so look at those comments that they’re making. It gives you the opportunity to add new tasks, and maybe pivot on an idea, and make a change.

Developing the thick skin, it’s like you said, you just have to disconnect from it being personal, and as a founder, a CEO, it is hard to not take that personally, but you’ve got to remember it’s the product, it’s not them telling you that your nose is big.

Robert: They might say that too, who knows?

Scott: Yeah well I have a big nose, so I’m use to that one.

Robert: Well I think that people now with so many forms of communication, people are are communicating with companies in so many different ways, that they forget that some of these companies aren’t … Some of these products aren’t developed by huge companies, they’re developed by a single individual, or a small team.

Scott: Yeah.

Robert: Yet they treat it like a huge company. I remember when I first started developing apps on Android, I was selling an app for a dollar, and people would get … A few people didn’t like it, and they wanted their 99 cents back. It was crazy. They give you this dollar, they expect so much from just a dollar. I thought that was interesting that when people are parting with their money there is really that expectation there that this is some huge company, you should get this right, you should fix these bugs. I thought that was interesting.

Scott: Sometimes they’re based on real things, but I had a review on an app this week of some code that I inherited. Basically you can tell that the person didn’t know what they were doing, they were like, “I can’t even log into this app.” I went and looked at the log history of what they were doing, and they weren’t even doing what they were suppose to. They had an empty username, of course you can’t log in. We can’t fix every problem like that. We can’t handhold every user. Yet you still look at it and go, “Okay, what can I do to prevent this?” Now I’m going to put a label there that says, “Your username is required.” You learn a little bit from all the feedback, positive and negative. Don’t take it offensively, maybe the best way to beat a troll is to be a troll yourself. Trolls have thick skin, so just develop thick skin, and start deflecting those name callings.

Robert: I guess the point is, is that really think about the feedback that you’re getting, both positive and negative, and really use that to help make your product better. Not delaying the launch, right? Just trying to make your product continuously better each time, even if there’s little things you can do to improve it over time.

Scott: Absolutely, and the closed captioning on what Rob just said was become a troll.

Robert: Yeah. I hope this episode has helped you to think about product perfection in a different light, and really focus on getting your product out there, setting milestones, thinking about how those releases continuously release products to get it out in front of your customer, really focus on defining and solving your customer’s pain, and how each release, and each milestone, does that. Then think about how you can get beta testers to use your product to help to give you feedback, and help continuously approve it. Then just focus on the positive aspects, and take the naysayers, and help that make a better product for your company.

Scott: Absolutely, and guys don’t forget, send us an email at the email address associated with our podcast. We’d love to take a look at your products. Hit us up on social media, I’m @The_Scott_Davis on Twitter. Rob I don’t know what you are, because I can’t remember anything. You guys can reach out to us, we’d love to help you, give you some ideas, and help you make a better product.

Robert: Yeah, I’m @RobDickersonJr, so you can shoot me a message there or go to mapoutlearning.com and send me a message there.

Thanks for listening to this episode of The Stretch Goals podcast. You can access the show notes for this episode, and listen to other episodes by heading over to StretchGoals.fm.

Subscribe For New Episodes

Each week we'll share insights and lessons learned to help you create ambitious goals for your business.

Robert Dickerson

@RobDickersonJr

Robert Dickerson is the Founder and CEO of Mapout a mobile learning platform that uses video courses to educate customers and train employees. He helps companies develop and launch their products.

Scott Davis

@The_Scott_Davis

Scott Davis is the Founder and CEO of MobX, a mobile development software agency. He has 20 years of experience developing software for Government, Finance, Sports and the Telecommunications industry.