Why "Perfect" Products Take Forever to Ship

In this episode, Gino and Wayne explore one of the most common traps in product development: the pursuit of perfection that actually prevents you from delivering great products.

We discuss why waiting for the "perfect" product can take 2-3 years and still fail in production, share a real case study of a project that took 2 years to build but needed 6 more months to actually work, and explore how different companies handle the perfection vs. speed dilemma.

Key topics include:

• The perfectionism trap and elongated delivery times
• Apple vs. startup approaches to product perfection
• Customer segmentation strategies for faster releases
• Feature toggles and controlled rollouts
• Why production validation trumps test environment success
• Multidimensional planning: dirt road vs. highway implementations
• A fascinating airport dropdown case study that reveals unexpected user behavior

The counterintuitive insight: If you want to make a perfect product, go to your client with an imperfect product first.

Ideal for product managers, developers, startup founders, and anyone involved in product development who wants to ship faster without sacrificing quality.

Have a workplace situation with unintended bad outcomes? Share it with us for a future episode!

Contact us at feedback@goodintentionsbadoutcomes.org

Transcript

[00:02] Hello, everyone.

[00:04] Welcome to Good Intentions and Bad Outcomes, a podcast about challenges and practices you might encounter in the workplace, where good intentions have unintended and often unnoticed consequences.

[00:14] I'm Gino.

[00:16] And I'm Wayne. And every time we share a situation that we or one of our listeners have seen in the workplace that is challenging in some way.

[00:25] We discuss the what and the why and we try to come up with alternatives on the spot.

[00:29] So let's get started.

[00:30] So Wayne, you're bringing a topic today, so why don't you tell us what it's about?

[00:36] Sure, I was thinking about some good intentions that turned into bad outcomes and a really good intention that I've seen in a lot of companies is the intention of producing a product, whatever it happens to be, that the customer really loves - that it does what they want it to do.

[00:54] The customer wants to buy it, you know, maybe you want to be that company like Apple where people are lining up on the street camping out before the release of your products so that they can get one of the first ones.

[01:08] So the desire to please the customer and have a really great product, I think that's a really good intention to have.

[01:17] But what I've seen... yeah, would you say that's a good intention?

[01:22] I definitely would. I mean, I wouldn't want to buy anything from a company that does not have the intention to please me.

[01:29] Right, yeah.

[01:31] And I've talked to lots of product owners who are really hesitant to release, like a minimum viable product, for instance, because they think it's half baked or it's missing pieces or the customer won't accept it.

[01:47] It's not doing similar to what the current product is like, and they have to have at least "like for like" - some of these phrases that I've heard before.

[01:58] So I think the desire there is the correct desire. They want to make sure the customer is pleased and happy.

[02:04] But the bad outcome is that we will never rest until we have a product that's perfect.

[02:12] In fact, we might not ever even release the product because it never reaches the state where we think it's good enough for the customer to see.

[02:21] And so we see these really elongated delivery times and product development that's taking 2 and 3 years because of perfectionism.

[02:31] It has to be perfect before anybody can ever see it.

[02:34] Yeah, this is a bad outcome.

[02:38] Yeah, I've seen this too where indeed, as you say, people applying practices and principles to ensure that they can deliver something in an incremental fashion.

[02:50] And then they essentially wait before they go to the client.

[02:54] And the problem is not so much that they... because you call that an example - Apple.

[03:01] Right. Apple cannot afford to put a product out there that is not entirely polished.

[03:06] They can't afford that at all.

[03:08] They are absolutely required to ensure that as soon as they put something out there - just not even for a small audience, right?

[03:17] Because their products are so secretive that they cannot afford to do that.

[03:22] They have to deliver a polished product.

[03:27] Day one. They have no choice, that's what they're going for.

[03:31] That's part of their brand, that's what they do.

[03:33] But there are techniques to ensure that you don't run into the problems that you just talked about.

[03:39] And that is, as soon as they do deliver it to production, that's the first time that they run into challenges because they've never seen it before, because they haven't gone all the way to production, because there are unknowns that they haven't discovered. And that's the issue that we're talking about, isn't it?

[04:03] Right, yeah. I recall one product that was being developed and we thought it was being developed incrementally.

[04:11] We had split the product description into a backlog.

[04:15] We were executing in Sprints.

[04:17] The team was building software in Sprint, testing it in Sprints that had been released incrementally into a pre-production environment, into a QA environment.

[04:28] And it worked and was tested in that environment. So it looked like it was being built up in an incremental way, but it was never released to production.

[04:39] And it took them... took about a year and a half project.

[04:46] The project was extended into almost 2 years and then somebody decided that we should release this product after 2 years' worth of development.

[04:56] It went into production and immediately hit all kinds of problems and it took approximately another 6 months after that point to work through all of the issues before it was actually usable by a customer.

[05:09] So it really elongated the project and cost a lot extra than was anticipated.

[05:16] And it was not a great outcome.

[05:18] Now they wanted to, of course, they wanted to build the perfect product. When they thought they had a perfect, they released it and found out it wasn't quite perfect yet.

[05:25] Yeah.

[05:26] So let's... we just talked about the example of Apple.

[05:31] There's other examples as well of companies who do not have that challenge and who can actually go to production with something really... startups are great at that as well - with something really small, something that might not do everything that they want their clients to be able to do.

[05:49] But it does one thing and it does it really well.

[05:52] And maybe it's not entirely polished, but it already delivers the value.

[05:57] Those are two extremes, right?

[05:59] You know, there's a lot of organizations that sit in the middle where they actually want to go to production.

[06:07] They want to make sure that some of the clients can use it, maybe a few - what they call alpha customers or beta customers - and validate the functionality that they have delivered and then again, rolling it out to a larger group.

[06:25] So there's a whole bunch of things in the middle as well, and those are really the ones that we're speaking about.

[06:30] The companies, the startups that do it and that go to production right away to the end consumers, they don't suffer from these challenges.

[06:37] But it's really about those established companies who have a brand who don't want that brand to be negatively impacted by maybe what looks like an unfinished product. They need to apply different methods to ensure that brand is not negatively impacted.

[07:03] Exactly.

[07:04] But, you know, I heard you talk about a couple of different things that even some of the smaller companies or the startup companies do that would help with those types of problems.

[07:17] So you get a good product, but you're not blocked by perfectionism.

[07:21] And if we were to itemize those things, what do you think is the most important thing for a company to do to avoid the perfectionism trap?

[07:32] I think it's definitely trying to ensure that you go to market with a feature set that is already valuable for your users, but not all the things that you can possibly do.

[07:49] Let's take an example from, for instance, an application that wants to support people in submitting their taxes.

[07:58] 80% of all people have a fairly simple tax return to submit.

[08:08] Those 80% will have maybe two people in a family, maybe some dependent family members, they have either a property or not, they have one source of income, and that's about it.

[08:27] If 80% of your clientele - and maybe it's not 80%, maybe it's 60%, but still, that's a big chunk.

[08:32] If a huge portion of your potential target audience has this kind of profile that is significantly limiting the number of features that you require in order for it to be valuable for them, start with those.

[08:48] That's the first thing, right, that I would do is try to figure out what is that feature set that we can identify that helps some clients, but doesn't necessarily help everyone.

[09:00] That's the first thing I would do.

[09:03] So you're talking about slimming down the functionality, not crippling the functionality or releasing it too soon, but having a fully functional piece of software.

[09:17] Working, but only just a slim slice of it, something that does an important piece.

[09:25] That's right.

[09:26] That would be maybe the number one thing that you're talking about there.

[09:33] Yeah, the second thing that comes out of this for me is not trying to please every single customer with every single feature right off the top.

[09:43] Maybe you do customer segmentation, so maybe there's just a smaller group that needs it.

[09:50] So you build a smaller piece of software to release to some of your customers, but not all of them.

[09:55] And that way you can get it out there faster and you can get the feedback that you need.

[09:59] I saw this happen when in one organization they were building mortgage products and a fair number of their customers were only single applicants.

[10:12] So one person applies to buy a house and one person qualifies for the mortgage.

[10:21] They targeted just the single applicants - quite a few customers. Now it might be a couple who wants to buy a family home, there would be two applicants, a husband and a wife, 2 people going together on a house.

[10:39] So that would be the next use case, you could say, and that would require some extra features.

[10:44] That was a second round of the feature set being built out.

[10:51] But they didn't wait to release until they had the 2-person part done. They did the first part, then they added on the second part, and then after that it came in rounds.

[11:01] After that, I think it was commercial mortgages where businesses would then qualify for a mortgage.

[11:07] So they built it up gradually, but each piece was fully functional, worked well, served a customer purpose and a particular customer segment.

[11:16] Yeah, absolutely.

[11:18] And then you have additional things as well where you basically say, well, we use feature toggles and we are providing a piece of functionality to only a limited group of people that we trust really well who know that they are getting maybe early software, maybe early access software, and as a result, doesn't have all the features.

[11:46] They are OK with that.

[11:48] They're actually signing up to do this, right?

[11:51] You can use features in multiple ways.

[11:52] This is one of the ways that I'm suggesting specifically related to that problem that you're referring to. And the reason why this is important - and we actually haven't talked really about this, or at least not explicitly - is we want to go all the way to production.

[12:07] We want to make sure that the software that we're creating is validated in production, not just on our test environment, not just on our QA environment, not even in a pre-production environment if you have all of these - but in the real production environment where it's integrated with real authentication systems, where it's integrated with all the infrastructure that it requires in order to work. And if we don't do this, we keep on assuming that it will just work within that environment.

[12:35] It will just integrate with all these other systems, and that's not always the case, right?

[12:40] So, more and more, luckily, because we're working in cloud environments, those environments - whether it's production, QA or whatever - are much more alike because they're virtual environments in many cases these days.

[12:58] In the past, they weren't - there were physical different boxes.

[13:02] That is already resolved to some degree, but the configuration can still be different.

[13:08] The data that it relies on can still be different and that data can have an impact in the workings of the software itself as well, right?

[13:15] So that's why we're doing it.

[13:17] We do it because we want to prevent our assumptions... we want to validate whether or not these assumptions are correct in the first place and if they're not, we want to be able to solve them as early as possible.

[13:29] And that's why we want to go all the way to production.

[13:32] Yeah.

[13:33] I think you've highlighted there are two sets of assumptions.

[13:36] There's the assumption that our internal systems and our processes are working. And if we can test those with multiple frequent releases, then we eliminate the assumption that everything is going to work when it gets out there.

[13:53] That's an internal assumption.

[13:55] The other one that we want to validate is the external assumption.

[13:58] We assume the product is going to be wanted by the customer, the customer will buy it.

[14:03] But we have no idea until we release it.

[14:05] So if we can release it soon and we can actually see what is important to them and validate that our assumptions about the customers are correct, then we're going to avoid a lot of problems later on.

[14:16] So we'll actually produce a better product. You know, it's kind of a reverse mindset, right?

[14:21] We want this perfect thing.

[14:23] We actually get a more perfect thing by releasing a smaller piece sooner than we do if we wait for the perfect thing to finally be built.

[14:35] I actually have an example and I think we need to wrap it up because we're already at the 15-minute mark.

[14:42] But many years ago - and I don't even know how many but it might be 20 - I was talking to a gentleman named Kun at a conference somewhere in the Benelux in Europe. And so he introduced me to a concept called multidimensional planning.

[15:00] And I was skeptical at first and I asked him... and essentially, when he explained multi-dimensional planning, which is you always have more than two dimensions - one is scope, one is time - but when you need to deliver something.

[15:13] Another one is depth, and he associated that with a state of a road.

[15:21] So you could have a dirt road implementation, a cobblestone road, an asphalted road implementation, the highway implementation, and we tend to want the highway implementation all the time.

[15:30] So his whole premise was like... instead, get the dirt road or the cobblestone road implementation for most of your things, get that to the client, fully functional, but you can get it sooner.

[15:42] So fully functional, as you said, not with all the bells and whistles, not as pretty as it otherwise would be, but so that you could get feedback.

[15:49] And I was like, yeah, the clients won't want that, right?

[15:51] And so he gave me an example.

[15:53] He said, well, we needed to build some kind of a dropdown and an ability for clients to select an airport.

[16:03] And what the client wanted was an implementation where the dropdown would... you would be able to type in it and it would automatically filter and all that kind of stuff.

[16:14] And, you know, all the stuff that is normal right now - but back in the day, you still had to implement these things.

[16:19] And they said like, yeah, it's gonna take a good week or so or whatever.

[16:25] They said I can do something else for you.

[16:26] I can give it to you tomorrow.

[16:28] I can give it to you tomorrow where you just have a text field, you press enter, afterwards you get a list and you click again on the one that you want, right?

[16:35] So it would filter down to that.

[16:38] And, but at the same time, we're building the monitoring so that we know what people are actually looking for.

[16:43] So they delivered it.

[16:45] The client used it for a week.

[16:48] And lo and behold, instead of the cities that they thought that they would need to optimize for, this site was actually used more by pilots, and they were not using the city names.

[16:58] And I hope that I can... contact me if I'm not telling this correctly and you get on to one of the next posts.

[17:05] But so essentially the pilots were looking for the airport codes like YYZ which is Toronto or BRU which is Brussels.

[17:18] So those are the ones that they were looking for.

[17:20] So they could optimize for that new behavior.

[17:22] That was something that they didn't know.

[17:24] That was the user assumption or the functionality assumption that you were just talking about, Wayne.

[17:29] And that is important as well.

[17:31] So the faster we go to the client, the more assumptions we can validate, and the more we learn about the behavior that our users have and as a result, we can make a better product.

[17:41] So if you really want to make a product perfect...

[17:45] Go to your client with an imperfect product.

[17:50] Exactly.

[17:51] OK, so that's it for today.

[17:55] I hope you enjoyed the conversation.

[17:56] I certainly did.

[17:57] If you have a situation at work, in the past or right now that you feel has unintended bad outcomes, please let us know and we might discuss it at one of our next sessions.

[18:07] Thank you all for listening.

[18:12] Thank you.