Just Say No

Technical sessions are easier than sales sessions.
There is no need to gloss over the truth or use smoke and mirrors.

One of the differences between an experienced techie and a newbie – is the knowledge that saying “no” to a customer isn’t always a bad thing.

I remember the panic I felt when I was a newbie, sitting in a technical session with a potential customer, and the customer would look at me and ask if the product has a certain feature (which it didn’t) – and I would panic.

The panic is from the worry that if I say no – the customer will decide it’s a deal breaker, I’ll get into trouble with my boss because I lost him the deal, the company will collapse because we didn’t get the strategic deal, and the world will come to an end… (ok..maybe exaggerating here but you get my drift)

One of the things that you learn with experience is that customers actually respect being told “no”.
First, it tells them that you are not trying to blow smoke up their backside..
Second, It helps them set boundaries and expectations.
Third, it keeps you out of trouble (legal aspects, project scope & delivery, rework..)

Now, I’m not advising to say “no” to everything.
The trick is knowing when missing product functionality is a deal breaker or not.
That is something that comes with experience.
Nor am I advising just to say the word “no”. Explaining why we don’t have the feature is just as important. (Is there a thought-out logic behind it, is it in the roadmap, is there a workaround)

A few examples:
Question: Can a user delete his/her workflow task?
Answer: No, only the process manager can delete tasks as we want to protect the audit trail

Question: Can the product connect to our proprietary database.
Answer: It should be able to, but we would need to physically check that it works. I’d advise setting up a session to check it.

Question: Can the reports module and tasks module run on the same server.
Answer: I wouldn’t advise putting them on the same server, as you would be running a risk of performance problems if the reports are heavy.

Training sessions are even better.
When I started training I felt obligated to gloss over problems. It came back to bite me, as I was the one sent to save the project when things went wrong.

Nowadays I spend time explaining the product limitations – what works, what doesn’t. Its pays off. One of the famous rules of development is the 90%/10% rule. 90% of the implementation is done in no time at all. 10% takes forever…
Knowing where the 10% is (usually happens when trying to build around product limitations) – is the key for a successful delivery.

Just say no.