The Monday Morning Building Product Advisor
Issue #140

Last month, I was at a red light and looked up at a building I worked on some 8 or 9 years ago.

The panels are chalking. They aren’t failing, just showing that dusty, faded look you see when a finish starts to wear out. It’s uneven, so the south side looks much older than the west.

And I remember the exact meeting that caused it.

It was a value engineering meeting about 5 weeks before bidding. As usual, we were over budget. There were 11 items on the list, including the panel system. The alternative would save us about $40,000, though we needed to cut a heck of a lot more than that.

I pushed back for about 90 seconds and then just let it go.

You probably never think about this part…

And I don’t blame you for it one bit, since no one has probably ever explained it to you.

Your mistakes disappear.

A product gets discontinued. A job falls through. A spec you fought for gets changed at the last minute. It’s just a line in your CRM or a bad quarter, but then it’s over. No one ever drives you past it.

As Frank Lloyd Wright said in his 1931 lecture, “The physician can bury his mistakes, but the architect can only advise his client to plant vines.”

Our mistakes are out there on the streets for all to see.

We drive clients and our own staff past our buildings. I sit at that light once or twice a month. Sometimes I don’t think about it, but other times, I remember that meeting and wish I’d pushed harder.

It’s not a liability issue. No one will sue over a chalked finish. It’s something smaller and more permanent than that. It’s just there… at a stoplight… taunting me… for as long as the building is there.

The uncomfortable part for me is…

I approved that swap.

It wasn’t the GC or the owner’s rep. It was me. I had my argument ready, but I didn’t push hard enough. I’ve spent some time trying to understand why.

The best explanation I can find doesn’t really flatter me… or any of us.

In the 1960s, researchers started testing a simple idea: how do people choose between a reward they can get soon and a bigger one they can get later? They expected a clear answer, but it wasn’t that simple.

George Ainslie’s work on this dates back to 1975, and the standard way to present his findings is to ask one question twice.

First time. Would you rather have $50 a year from now or $100 three years from now?

The majority of people go for the $50. Waiting two extra years for the larger sum just doesn’t seem worthwhile.

Second time round. It was the same question, just both options were now three years further out. Would you rather have $50 in four years’ time or $100 in six years’ time?

A lot of those same people switched to the $100.

Let’s look at what really happened. The gap between the two choices stayed the same. Two years of waiting for an extra $50. The only thing that changed was how far away the decision felt.

And once it was far enough out, those two years of waiting didn’t seem all that much anymore. So the larger number ultimately won.

In plain terms: things close to us are clearly different in size, and things farther away start to look pretty much the same.

Or put the way it actually stuck with me:

Once a cost is far enough away, it doesn’t matter how big it is.

Now, let’s put that in the conference room I was in five weeks before the bidding phase.

$40,000 this month was a number everyone at the table could feel. A chalking south elevation in Year 6 wasn’t a smaller number. It was just far enough away that none of us could feel the difference between it and nothing.

Which is why value engineering wins almost every fight

It’s not because the savings are huge. It’s because they’re right here, right now, in front of us.

I’m not saying VE is a villain here, by the way. It’s a legitimate process, and it’s often the only reason a project gets built at all. The issue is actually narrower than that:

Only one side of the ledger has a number attached to it.

And here’s what I actually want you to take from me sitting at that stoplight.

Every argument I made in that meeting was really just about preference. Our design team wanted to keep the better-looking panel. That’s a matter of taste. Taste loses to cost savings every time, and it should.

What I needed was someone in that room who could put a number on Year 6.

Nobody at that table could. The GC would be gone at closeout. The owner’s rep was in the process of measuring that fiscal year. And I was playing the losing hand in the argument over aesthetics.

You (the product rep) would have been the only person in the room with that information.

You know what that lesser finish looks like at Year 6 in this climate on a south elevation, because you’ve seen it on another building. That’s not a sales pitch. That’s the one piece of arithmetic no one else at the table has.

Of course, product reps aren’t usually invited to the VE discussions.

But you can make sure the architect has the right information. An architect in a VE fight who’s losing and gets a number, instead of just a feeling, to defend their design will always remember who gave it to them.

A word of caution, though…

Of all the things I’ve shared in this newsletter, that technique is the one that can go wrong the fastest.

“Your building will fail.” That’s fearmongering. It’s also usually not true, and we can smell it a mile away.

But what if the question is, “What does the owner’s maintenance budget look like 6 years from now with that alternative?” That’s arithmetic. Now that’s a number that the owner’s rep can start to visualize and appreciate.

The difference isn’t tone. Run two checks before you bring year six into a meeting.

Is it likely, or just possible? If you have to use the ‘worst case’ to make your point, then you don’t really have a point. That’s just a horror story, and that’s what other reps do.

Are you asking it or announcing it? We looked at that a few issues ago. The number only works for architects (or any stakeholder) if we’re the ones who say it. That’s why posing it as a question works best.

Notice what this doesn’t take

It’s not charm. It’s not three years of relationship building. It’s not a golf handicap. It’s not about being the rep who knows my kids’ names (though I have no objection to any of that).

It’s a number you can probably get your hot little hands on this month, shared at the one moment in the project when it really matters.

Here’s what to do with this

Find a building with your product on it that’s from somewhere around seven or eight years ago. Not a case study. A real building that’s within driving distance.

Then go have a look at it. If it’s in another part of the country, ask a colleague to do it.

Stand in front of the different elevations. Take a photo of what you see (include the bits and details that your company would never put in a brochure). Ask whoever’s maintaining it what it has cost them so far.

Or maybe you don’t represent a visual item. In that case, find another metric to demonstrate superior functionality over time.

Whatever it is, now you have the number.

And the next time you have an architect who is likely heading toward a VE meeting, share those numbers with them. Then, you’re less likely to see your product slide onto the alternates list, since the architect won’t just be arguing taste during VE.

They’ll be arguing arithmetic. And they’ll remember exactly who handed it to them.

​
That's it for this week!

Here's to building more than just buildings, and see you next week,

Neil Sutton
​Architect | Speaker | The Product Rep Coach

=======

P.S. Do you really want inside an architect's head?

When you’re ready, there are 3 ways you can start working with me:

• Product reps: If you want to be better at connecting with architects, reply, and let's chat.
• Business owners or Team Leaders: You can book an Architect Connections Training for your team. Reply, and I'll send you the details.
• Speaking: If you would like me to present at an upcoming group meeting, get in touch, and let’s talk!

=======
​If this was forwarded to you, go to → mmbpa-newsletter(dot)carrd(dot)co ← so you don’t miss the next lesson.
​=======