Why Make a Bigger Problem?

Adam Bahret
Adam Bahret

When I was a kid, maybe five years old, I went to stay at a friends house for the weekend. I wanted to be a polite guest. After dinner they served us cookies. Wahoo cookies! They were Oreos. I did not like Oreos. I didn’t know what to do. I didn’t want to tell them I was displeased with their dessert selection, so I put them in a napkin in my lap.I really wanted to sell that I liked their dessert. So to cover up any suspicion I took two more. I now had four cookies in a napkin in my lap. Now what? What was my escape plan? I can’t just throw them in the trash because they would see that. My original issue of not liking their dessert, which I would give anything to go back to, was now a much bigger problem.

So what ingenious plan did I come up with? Put them under my friends bed when I got back to the room. My friends Mom found them later and just looked at me with this very confused look. Hiding an issue never goes well. It almost always creates a bigger issue that has to be dealt with later on down the road. I could have just been the kid who doesn’t like Oreos. Instead I became the kid showing early signs of a hoarding disorder.

I see this same approach to “solving” design problems in product development. An issue is found in test. The issues are “tested out” by making tests easier. Will the customer adjust how they use the product if they experience the same issue? No of course not. They’ll send it back, write bad reviews, and switch to using your competitors products.

All this just to avoid the momentary discomfort of reporting to leadership that the product release date will be pushed out? Something fundamental needs to change in your culture if this is occurring. Issues found should be rewarded not punished.

That issue exists wether you like it or not. The fact that you found it, not the customer, is a blessing. Think of how little we get to test our product’s during development. The stars are aligned and your guardian angel is looking over your shoulder if you find even seventy five percent of what is going to unfold down the road over the next five years.

Change your culture to “Fail early and fail fast.” Reward those who find design problems. Extending the schedule to mitigate an issue should be no big deal in your culture. Trace out and advertise what you believe would have happened with the found issue if it had made it to the field. Then show that right next to the proposed program schedule change needed to solve the issue. With the ROI in black and white like that there is nobody that will disagree with the fact this is a joyous moment. We, as a team, just mitigated a huge loss with a simple schedule change. How amazing is that?
-Adam

Share this post