Good products don't save bad service: From building a house to building a website

Last night I was sitting around a small bond fire with some friends chatting about our houses. We just moved into our house last October, after having it newly constructed in this new neighborhood. My friends moved in several months prior to us, and watched the construction of our house, which seemed like it was never going to end. We had the same builder, who provides a 1 year touch-up service as part of their warranty to address any "settling", or shrinkage, and my friends just completed their 1 year follow-up.

The difficulties we both had during construction, and post-closing, were the topic of conversation when one of them asked, "would you build another house with them?" I thought about the question for a minute, because the quality of the house and the layout is something we all agreed was above average. But I replied with, "No, I don't think so. A good product won't save bad service."

After the fire I went home, and the similarities between the construction process of our house, and what customers, developers, and agencies go through for websites prompted me to write this. This is my list of issues you might face, along with some pointers for you when starting a new project, or a new relationship with a customer.

A Little Background

In almost 10 years working with CMS products, from the vendor side to the agency side, I have played the role of architect, team lead, primary developer, project lead, tech support, etc... I have been there from the start of the honeymoon phase, as a project finds a proposed solution, to the divorce phase, where it's just not working out between us, and the kids are old enough now. I've been involved from kick-off to hand-off. I've represented the vendor and the customer, playing middle-man. I had never had my own project, though, with my own checkboxes.

That's what buying a house was for me. My wife and I had developed our own checklist to mark off, prioritized items, had a sort-of Minimally Viable Product (MVP), as well as an ideal solution, and we searched for vendors. We met with several, lists in hand, and requested their lists of options and capabilities, and we worked through our checklist. It was the first time either one of us had built a house, but it was a very familiar experience for me, though the perspective was a little new.

Like some website projects I have been a part of, however, it didn't go smoothly. We had delays, constantly changing "go-live" dates, communication issues, changes in resources, and project management issues. Ultimately, we are accepting of the final product, and we really love our neighborhood and new friends, but, as with a website, acceptance of the result, and happiness with the result are two different things. If the builder came to us asking for a maintenance contract, for example, I would say no. Reflecting back, I can point to several key areas that identify why I arrived at my "no" response, and they directly relate to the work we, as PMs, Account Managers, Sales Engineers, and Developers do.

Identifying The Issues

Overselling

The first issue with a project, or any sales pitch, is overselling. We decided to build in a growth area, which meant builders were everywhere, and contractors were stretched thin among them. It also meant there were many options for a home buyer to pick from. That is not unlike the seasons we see in the web development world. And like we sometimes see happen in the development world, our builder oversold their product and timeline to us. They knew some of the struggles they were having, and they knew that their 5-6 month timeline was not realistic, since they weren't hitting it on any of their current projects, but they still promised that timeline, and a specific feature set at a fixed price. The price worked well for us, but if the builder didn't hit their timeline, that price became more and more of a profit loss for them. By the time you near the end of a project like that, your attitude changes from "let's make this amazing", to "let's just get this done and get out of it."

I have been a part of projects that ended like that, and it's an awful feeling; even more so when you want to still deliver on your project, but your boss says, "Just get it done the quick way." As a developer, this can mean repeated code, inefficiencies and lack of optimizations, and ultimately lack of polish. Customers see this. It may not be at first, but they see it, and it affects their final decision whether or not they will come back to you again.

They also oversold on one of their features to us. I love cooking and being in the kitchen, so having a premium kitchen with a gas cook-top and double wall oven was an extra we elected for. We saw this option in one of their demo houses - the only other house in the region that shared our floorplan - and requested it, seeing they had done it before. They sold us that option and told us they could definitely do it. However, at our framing walk-through (wireframe review), they informed us the kitchen wouldn't fit the floorplan.

It turned out the community director for the other area had extended the back of the house an extra 2 feet, and didn't tell anyone. And since that house was the first time they installed those upgrades into our floorplan, nobody knew it.

In my eye, I saw a botched integration with a 3rd party component that was sold and promised with expertise behind it, even though it had only been done once, and they actually had little expertise. For a customer of a website, this will leave questions of doubt on whether the integration was done correctly, efficiently, and whether it will stand the test of time. It also means the final experience will probably not be the initial, desired design. In our case, we lost 4 feet between our island and the relocated spot for our pantry. On a web project, changes like that may lead to a product never being used, and seen as wasted money.

Shopping with their Wallet

Speaking of wasting money: in my early days of retail sales, my hiring Sales Manager, later my General Manager and friend of 10+ years, told me a key to selling is to, "never shop with their wallet." It doesn't mean try to get as much money out of a customer as you can, but it does mean don't hold an option back because you think they can't afford it, or won't spend the money on it.

When we started our build process, we informed the builder we were on a certain budget. What we didn't know, is this meant the community director in charge of our build immediately had this idea of certain things we wouldn't buy. As a result, our options list for the house didn't include everything we could have done or chosen. It wasn't until we moved in that we found out there were structural changes we could have made to create a dedicated office for me instead of using a bedroom, or widened the garage for a work area.

Only the customer in charge of the spending can decide what is important and a priority for their final product. Instead of holding options and features back because they increase the price, or a change order might be required, you should always present them. Sometimes there is extra budget room set aside for these kinds of fluctuations. Other times the customer may see the requested feature as a higher priority than another on the list, and will shift the budget priorities to accommodate that.

If you hold back features and options from a customer, and they later find out they could have worked those into their budget from the beginning, it will affect the trust they have with your organization. Sometimes, in the sales process, we don't think about how much more expensive it is to add a feature after the project is complete. Just like a house, it's easier and cheaper to move a wall and extend the foundation if it's decided at the start, than it is to go back post-construction, and try to add-on. Adding it from the beginning also ensures the feature or option is seamless in the design, instead of feeling like a post-addition or afterthought. Your web project customers also know this holds true for their websites, and they will make their decisions based on this.

Transparency

Let's start this off by quickly knocking this out: depending on the stats you read, somewhere between 30%-60% of projects fail to complete on time and meet budget goals. This isn't just web projects, but government infrastructure, large-scale IT, commercial and residential construction, etc... What this means is, there is a good probability your project will get delayed or blow it's budget.

Project delays are not the end of the world, however. It's true that no customer wants to hear "delayed" in a meeting, just like they don't want to hear "that will cost more", or "that's a change order". But not hearing those phrases is worse when they are happening behind the scenes. It may be the elephant in the room, but it's better to address that elephant than it is to act like it isn't there.

As mentioned prior, our house was sold with a 5-6 month timeline. About 10.5 months later, we moved in. That's almost double the amount of time initially sold for the project, and, in all honesty, that wasn't the huge ordeal for us. Sure, it created turmoil with our family we were living with, and it meant not celebrating our sons birthday in our new house. But the bigger issue, was the lack of communication about the delays.

We were visiting the construction weekly, like a customer regularly checking status on a QA site, so we could see progress, or lack thereof. As a developer, things like that used to annoy me a bit about customers. Now that I have experienced it, I completely understand. Doing that allows you to judge how transparent a company is being with your project, and, in our case, they weren't being transparent at all.

We sent several emails, made several phone calls, and had to constantly question what progress was being made, if any. Our house sat, unchanged, for 2-3 months. We had an interest rate lock set to expire at a specific number of days, as per the builder contract, so we had to pay attention to timelines. Yet, throughout the process, we had no idea what was happening, until we hit our closing date, our rate expired, and we finally got through to the owner of the company.

The original lead contractor left for a family emergency. A late winter freeze halted development. The electrician was poached by another firm. The building inspector requested changes. The wrong product was delivered. Another contractor was delayed because of internal staff changes. The cleaner had a health issue and never came to our house.

Stuff like this happens, and it's often out of the control of the company and the project manager, but it's best to be open and transparent about those incidents as they occur. Sure, there are some customers that will not handle the news well and may react negatively, or even cancel a contract as a result. But most will be understanding and will appreciate the communication. This doesn't mean they will be happy and thankful about the delays or issues, but they will at least be happy that you understand how to communicate these events with them. It's much easier to deal with delays and issues when you know about them, and it definitely builds trust in a relationship when you know the company you are working with is being up-front and honest.

Warrantying Work

The first year of a newly constructed house is it's weathering period, where it experiences settling and drying. Because of this, reputable builders typically offer a 1 year follow-up to repair and patch the small cracks, nail pops, and gaps that appear. The same thing applies to newly launched websites.

Depending on the amount of traffic and use your site gets, it can take anywhere from a couple months to half a year for this same "settling" period, where users report usability issues and bugs, and functional limitations appear. This period is one of the most critical periods for the relationship between an agency and a customer during a web project, because it shows how responsive the agency is after launch, and how willing they are to stand behind their product.

In our case, this period has been a struggle and breakdown for us. The builder is slow on responses, new developments have stolen their attention, and, honestly, just like a web project that has been drawn out, that "let's be done with it" mentality has probably kicked in. We've all experienced that point where you feel good a site launched, because it seems like it took forever to get out the door, and when the customer comes back with an issue list, your response is not "Woohoo! More for this project!". Instead, it's likely a sarcastic, "Oh great, more for this project?"

During that warranty period, it's important you put those feelings aside, and handle the work as your legacy. The warranty is the opportunity for an agency, or developer, to show the customer that their patronage is still valued, and the developer is willing to support what they produced. It's also a chance for the relationship to stay strong, or rebuild by showing that any difficulties, delays, and other bumps along the way, are not going to impact the opportunity for success of the project.

There will always be a relationship that will not be saved because of one parties stubbornness, or hardened attitude, but many can still be salvaged by providing a satisfying warranty period. In our case, this period is still ongoing, and the current course does not look like it's going to redeem the relationship between the company and customer. But we're also only halfway through, so there is still time for redemption.

The Experience

All of these items lead to one specific thing: the experience. Customer service is all about providing an experience for a customer, and the experience is directly related to the type of service provided. If you provide good service, typically the experience is good. Likewise, bad service leads to a bad experience. And this experience is where the reputation of a product is created.

When I worked in retail sales, I sold all types of electronics, but computers were the best example of this idea. When a customer would express interest in "Brand A" for a computer, and they would never again buy a computer of "Brand B", I would ask them why. 9 times of 10 the reason came down to the overall experience. The hardware of "Brand B" would be sufficient, the reliability could be great, and they may have used it successfully for 5-10 years. But the overall experience was enough to deter them from that same brand, or even a specific ecosystem.

Apple has built its new empire on this exact concept. What has built their following is the experience they deliver with their ecosystem. From hardware, to software, to accessories, they tailor the experience a user has within their product families. That is what gives their products a certain "social image" to users, and makes them attractive. It doesn't matter how "sexy" or "sleek" their product designs are, or how distinct their packaging is. It's all about the success of the experience they deliver to their customers.

This is the same recipe for a successful web project, or new house construction. Despite being oversold on features, not being delivered the full feature and option list, countless delays, lack of transparency from the developer, and a less than stellar response to warranty issues, the real reason I said "No" is because of the overall experience. We have a really well designed house that meets our needs in a neighborhood full of great people. Despite the issues, we do have a good product.

Good products, however, don't save bad service. In the end, the bad service delivered a bad overall experience, and, just as a good experience can sell you for a brand or company, a bad experience will sell you away from them.

Delivering a good experience

I can't tell you exactly how to deliver a good experience to a customer; it depends on the customer. In my years of sales and development, I learned that each customer is unique. Even when you categorize them into profiles, or personas, you are only identifying certain traits and behaviors. But traits do not always represent the individual personalities that each customer has. You have to get to know who you are working with.

What I can tell you is, along the road to delivering a good experience, talk to the customer, and maintain good communication. Present all the options and be up front about costs and levels of effort. When delays or issues surface, explain what happened and why. And always stand behind your work; don't consider a product launch as an opportunity to wipe your hands clean and walk away.

Occasionally your quotes may be higher, and your timeline may be a bit longer than the competition, but your reputation will grow, as will the trust your customers have in your abilities. Providing a good experience delivers more value than a low cost, short timeline, or good product.