Comment by richem | Hacker News Reader

Comment by richem | Hacker News Reader

Parent Full thread

I've been in a similar position for close to a decade now. One of the most effective things I can tell you to do is make sure that you document and ask for verification of any deliverables or requirements. Send summary emails (either after each meeting/or weekly) to make sure that everyone agrees with your understanding in writing and that nothing is missing. I've had multiple clients say something along the lines of "We never agreed to that" but when I've been able to show them an email it helps change the mood of the discussion. Then it becomes a change to the project rather than something you initially missed and now have to finagle. "If it's not documented it didn't happen" is an effective phrase to live by when dealing with clients, even the nice ones. You don't have to be aggressive, always be polite but firm. You can see how the engagement progresses and change things up if the client is more laid back. Additionally, keep track of the overall schedule, and make sure to point out things that will take you away from delivering on the schedule. I've had multiple clients ask for 1 or 2 side things and then complain when schedules slip. If you ensure they understand what the implications of additional work are (in writing) then you'll save yourself some hassles down the road.

commending this post for some of the biggest callouts in the "Implementation consultant" role - notes, notes,m and more notes, diagrams whenever possible and sending them out after meetings. The general rule of that world is "silence means acceptance" - so if you send out notes and a diagram detailing how to proceed and nobody responds you are free to proceed in that direction. The only issue is the C-levels who wont read any notes, gather any data, and come in with preconceived notions of how things should proceed - all you can do is get on their good side and convince them your idea was their idea

When you need to push back against a client with that kind of "we talked about it, here's the documentation", what kind of language do you use... I guess when being "polite but firm"?

I try to take the stance that they simply forgot about the previous conversations or agreements. That generally has worked for me and keeps people from losing too much face which additionally helps keep everyone on the same side. Everyone forgets sometimes, sometimes its a genuine memory lapse and other times not so much. I've used variations of the following numerous times to decent result:

"Hi <so and so>, we talked about this matter last in <this email chain or that meeting>, I'm attaching the last <email/meeting summary>. If there's a need to readdress this <situation/decision>, please feel free to let me know and we can setup a meeting to further discuss."

That establishes what you consider to be the facts, based on whatever evidence you are attaching, and doesn't necessarily place you at odds with the client. You always need to figure out how to balance your client relationship with your project needs. Sometimes you may need to give a bit on the project needs to keep the client content but that is surprisingly less than most consultants think.

I've had several clients come back to me after an engagement has completed and mention that they were being intentionally difficult to see what else they could get but documentation helped prevent too much excess on my part. I've even been in the situation where I have acted as the client when dealing with vendor implementation teams and told specifically to be difficult to see what else we could get.

Interesting. Thanks for the insight and advice!

To reflect back what I'm seeing in your language use - to see if I've gotten the gist of it - your subtext / authoring attitude is "ah, you just forgot, let me simply re-inform" but you also don't bother mentioning any particular reason.

That makes sense, I will surely follow up with a summary of the discussions.

Also, do the dev teams listen to the feedback that you provide to them regarding the features that would be helpful / useful according to the client's suggestions?

Good teams do.

I employ a team of implementation specialists at a B2B SaaS company. We heavily rely on that team to help guide future product development. But you’ll likely need to be able to translate the ask from 1 customer to something applicable to many customers for the product team to really listen.

One other tip for you- our culture is one of transparency with customers. We encourage our implementation team to be on the lookout for “deal breakers”. It’s best to identify those early and get them a refund than to waste weeks/months only to find that one show stopper right before going live.

You’d think that would be the sales team’s job. I did too, until I hired sales people ;).

I would definitely second the suggestion of identifying "deal breakers" as early as possible. It's much easier to highlight a shortcoming and come up with a reasonable solution when a few hours/weeks have been committed vs 100/1000's of hours.

Sales people can greatly mis-state product capabilities so be on the lookout for where they let themselves get carried away with selling a solution. I've even worked with them before and gotten called down for correcting their "misunderstandings" in front of the potential customer.

Sales people live for the sale, you should be living to deliver the final solution to a happy/content client.

Reply on news.ycombinator.com