Did you just fake your product demo?

Picture the following scenario – you are the CTO of your organization, in charge of the flagship project ‘Bob’: a super-smart personal assistant that can hold a perfectly natural conversation with anyone.

You’re running your first product demo. All the stakeholders are present, your product manager is showing off an early beta and things are going great! The assistant is communicating fluently, cracking jokes, and it easily picks up subtle meaning in the most complex sentences. The crowd loves it and is going wild.

Afterwards, everybody is in a festive mood. You ask the product manager for a nightly build so you can play around with the prototype. But he is oddly evasive and mumbles something about installation issues. Not to be deterred, you head over to Github and run a build directly from the latest source code. You fire up the assistant on your mobile, and this happens:

You: “Hey Bob. How are you doing today?”
Bob: “Haha John, you’re such a comedian!”
You: “Uhh…. Can you give me the weather forecast?”
Bob: “Okay, I got one for you. Why did the chicken cross the road?”

With a sinking feeling, you realize what’s happening: the assistant is ignoring your input and giving the exact same answers it gave in the product demo. The entire demo was faked.

Welcome to the Smoke & Mirrors anti-pattern.

The three root causes of Smoke & Mirrors

At this point, your first impulse might be to start firing people. But let’s try to analyze what happened and why it happened.

The product manager was obviously in on the whole thing. He needed to stick closely to a prepared script to pull off a perfect demo. And remember how evasive he got when you asked him for the prototype? He knew the prototype wouldn’t hold up to scrutiny.

The dev team had to be in on it too. Instead of allowing the software to run the conversation on its own, they must have added a patch that forced the software to run through a list of hard-coded answers.

So why did they do it? Why would an entire team commit willingly to a massive deception?

Here’s the brutal truth: your team has given you exactly what you asked for.

Let me explain. There’s an old quote in IT that goes something like this:

You can have Good, Fast, or Cheap. Pick two.

The quote suggests that it is impossible to quickly and cheaply deliver a good product. Products that are good and cheap require lengthy deadlines. If you cannot move your deadline, you can choose to either deliver an average product, or a good product if you’re willing to spend a lot more money (i.e. by expanding your team)

As a CTO, you can easily get into trouble with a product demo. The dev team has no power to change the demo date, so ‘Fast’ is locked in. All the stakeholders will be present and need to be wooed, so ‘Good’ is also a given. That only leaves ‘Cheap’. If you’re running your team on a shoestring budget and do not bring in new talent, you’re forcing your team to deliver Good, Fast, and Cheap, which is impossible.

The team cannot move the demo date or increase their own budget, so the only leeway they have is to reduce the quality of the product. They will fake the demo to hide the fact that the product is low-quality.

In a normal company, someone would have escalated this a long time ago. The software is obviously not capable of running a natural conversation so you’ll have to re-think the architecture. Maybe you need to bring in a new speech library or use a different kind of deep learning algorithm. This kind of refactoring happens all the time when you’re operating at the very edge of what is technically possible.

So why didn’t the team come to you? Because you’re operating in a culture of fear.

Does your organization have bullying executives who blame, demean, and belittle others? This is a fertile ground for the Smoke & Mirrors anti-pattern. In a culture of fear, nobody will dare to come forward with bad news. You will be the last to find out that your product architecture doesn’t actually work in real life.

So your team has to reduce the product quality to hit the demo date within the budget, and they’re all afraid to come forward with this bad news because they know there is going to be hell to pay. With the team backed against the wall, they see only one way out: by faking the demo.

And finally, the fact that the team resorted to deceptive practices suggests that your organization has a weak moral compass.

Google used to have a code of conduct which was: “don’t be evil”. So if a Google product manager had asked their team to implement a shady practice, they would probably have refused. “Don’t be evil” is a powerful argument for employees to overrule their managers and escalate a complaint up the corporate ladder.

In your company, your team has just pulled off a huge deception so I’m betting you don’t have a strong code of conduct to guide your team.

How to fix the anti-pattern

It’s not hard to fix this anti-pattern, but it requires some bravery from you to help your organization step out of its comfort zone.

The first thing you need to do is give your team some freedom to achieve their goals. You need to give them the power to either define the functionality of the product, set the milestone dates, or give them control over their budget.

This is a painful step for traditional organizations because these responsibilities are usually scattered all over the corporate hierarchy. Empowering the team means disempowering the product manager, the project manager, and the VP of Engineering. But it’s the only way to give your team full control over ‘Good’, ‘Fast’, and ‘Cheap’.

If you’re hesitant to make these changes, please do realize that the company behind Basecamp is already organized in this way, with teams having full control over their schedule, roadmap, and budget. It really is the way of the future, and you do not want to be left behind.

The second thing you need to do is tackle the culture of fear. Executives who rant, criticize, and blame will create a toxic and fearful work environment, and you should have a zero-tolerance policy for this kind of behavior.

A culture free of blame is a very empowering work environment. In the absence of blame, everybody is free to try out experiments, move outside of their comfort zone, and be secure in the knowledge that mistakes will be treated as learning opportunities. This will stop your team from covering up technical problems and resorting to deception.

And finally, consider introducing a formal code of conduct for your entire organization. What sort of conduct do you consider unacceptable? Write it down, and get the entire organization to back it.

A formal code of conduct is a powerful guideline for your organization, and it is hugely empowering for your team. It will help them escalate technical issues all the way up the corporate ladder without fear of reprisal.

This will encourage open communication in your organization, and bring a lot of hidden problems back into the spotlight where you can work on resolving them.

Have you seen Smoke & Mirrors in your organization? What did you do?



Would you like to know more? I’ve created a series of blog posts that look at each anti-pattern in detail. Each post is loosely inspired by actual events that happened during my 20-year IT career.

Take a look:

Also published on Medium.