Re-thinking Customer Expectations

Our 2004 van broke down on the way to New Years/Christmas celebration at my parent’s home. Thankfully no one was hurt and it was a good spot to have troubles [* – see bellow]. We were just off the interstate by a gas station on a Wednesday morning and my Dad was only 20 minutes away. The heater stopped working and the engine was smoking. I have 3 children under 8 and it was 20 degrees out, so having no heat was concerning (but not threatening). After talking to my Dad and realizing the coolant had leaked out (the resovoir looked frozen and empty) and seeing some smoke, I bought a gallon of coolant. Thinking that should be enough to get me 20 miles to a mechanic, we took off and didn’t make it far. Dad brought another gallon and water, but we barely made it to town.

Talking to the mechanic got me thinking about what I expect as a customer and how that can help me understand our customers’ wants and needs better. I also thought about how important that temperature gauge is in the van. With the possibility that I overheated the engine too much and a greater expense of a used engine (I think/hope it will just be the timing belt) that I should have paid more attention to the warnings and just called the tow truck (imagine me kicking myself over that decision for a few hours).

Someone asked “So what happened to the van? Did it get repaired? Did you enjoy your Christmas? Were there other issues later that day?”

Everything worked out better than I expected. The timing belt was the issue, some bearings went out and they put in a new belt and water pump kit and had to replace some sensors. The engine is fine as well. We now have the van back, thanks to my parents. I was able to borrow a family car, so it was very little inconvenience. We had a great time with family doing puzzles together, playing games (like Stars Wars X-Wing Miniatures ) and celebrating my mom’s birthday on January 1st. Happy Birthdr asking! The van has been working great and now it is March. Thanks for asking.

My Expectations as a customer

I have/had many naive/high expections that highlight how I assume things should work.

The van should always work. I had 120,000 miles on it, just took it in for an oil changed and had them check the belts after I heard some noises. They said the belts should be changed sometime, but looked good. The mechanics should know everything and see everything that might be wrong with the van. I expected the oil change and belt check to ensure that things were good. I don’t know much about the mechanical part of the van. It’s akin to magic in some ways as Scott Hanselman explains abstractions . I haven’t made the time to understand all the parts and what signs to look for. I rely on my father and having a reliable vehicle. I don’t think I should have to understand everything to use a vehicle, few people do. My vehicle should be back working as quickly as possible, but with New Years Day holiday it will be next week. I was able to borrow a vehicle, so this is ok with me. The mechanic should get it working correctly, close to his estimate and have confidence that I can rely on the van again. I was very happy with a best case to worst case estimate. If it was just the timing belt then it will be about this much, if it was the full engine needing to be replaced it will be about this much. I could make an informed decision about if it was worth fixing the used van or getting a new one. Thankfully, the less severe problem was the issue and the timing belt fixed it. That made me glad. Complete honesty and transparency about what’s wrong and what should be done To get updates occasionaly on how things are going

Our Customers’ Expectations

Our customers who want/need software for their business and life have many of the same expectations. I’m seeing that my expectations of my vehicle match closely to agile ideas and working with people.

Reliability

Everyone wants their application to work all the time it is needed. They want us to catch problems before they see them (Dev Ops tools like Application Insights help Microsoft monitor for problems before releasing to a wide audience). Vehicles are starting to get this and I think it would be great to get a message that something needs to be fixed soon, based on big data and statistics. Probably too high for us to deliver perfect software and environments that never stops working with minimal effort We, the team, are experts. they just want it to work and be helpful

They want it quick and don’t want to wait, especially for fixes or avoiding downtime. Estimates, as much as I hate them, and as much as I don’t know how it fits in Agile beyond a sprint . We need to be able to estimate projects to bid on them and get business. I don’t know how to do this, but there are several articles out there and something I’ll need to learn more about. Maybe we need a budget, not an estimate ? There is some risk that it will be the worst case. The degree of comfortableness of the client to handle this risk may depend on the amount of money they have available. To increase our confidence in these numbers, the developers, QA, managers should be involved. Please don’t just throw some numbers out! Be honest and open about both ends of the spectrum, dishonesty or hiding things will just cause problems, damage your reputation, and loose you a customer. Communication, honesty and relationships make good business and projects go much better. Be honest as soon as possible if something is taking longer than expected. Meet often, at least once a sprint, to demo and get feedback from product owners and those who will use your software. It’s interesting how most of this relates to what I understand about Agile and how communication is very important in any business, but in creating software it is essential. Let’s put ourselves in our clients shoes. Let’s serve them and treat them as we want to be treated by any other business.

[*] I’m learning that things don’t go as planned very often. As C.S. Lewis says , “The truth is, of course, that what one regards as interruptions are precisely one’s life.”

Feedback I’ve received

There were some interesting comments from an email chain when I sent out this link to my company:

“Interesting comparison. I generally get a new vehicle before the warranty runs out. This mitigates risk of said issues.”

“However it trades your risk for higher monthly costs (assuming a loan) versus an older vehicle that is paid for. Some people find the trade-off worthwhile, others don’t.”

“On the other end of the spectrum you could trade safety, reliability, and convenience by going with a cheap older car that’s cheap to fix, assuming you’re savvy enough to constantly be DIYing it. … If you can stomach the cost of the constant repairs, (or occasionally buying an entirely new car, RIP g0cart) as opposed to the higher incoming cost of a “better”, “more reliable” product, it may be the better option.”

“Yes you could go for a horse and buggy and have minimal maintenance and easy DIY but even though you may be savvy enough to fix it, the is the old proverb. Time is money.”

Conclusion

We shouldn’t be anoyed by our clients/product owners’ expectations or questions. They don’t understand the complexities of writing good software products and that is OK. Let’s communicate more openly, avoid snide comments when they aren’t there and work for the common goal of creating value for the business and others.