Ask HN: How do I prepare for a job as an Implementation Consultant?
qualifier: i don&#x27;t know anything about anything.<p>that said, here is my _expert_ advice:<p>* no, you do not need to prepare. if you have a heartbeat and a tiny bit of common sense, you can do this role extremely well. and most other roles. it&#x27;s glorified customer service, with some extra nerdiness thrown in. not hating - some roles do require special skill sets outside of the obvious - this role is not one of them. i mean, there are non-proactive folks littering every position in the enterprise -- which cracks me up -- but i&#x27;m assuming that you are not stupid and&#x2F;or lazy.<p>* there are some sales and even sales engineering books&#x2F;course&#x2F;etc. out there. most are terrible, or worse, especially the ones that people &#x27;highly recommend&#x27;, but i do feel like learning to sell&#x2F;sales is double-plus-good. one core aspect is learning to ask good&#x2F;probing questions, and then learning to shut up and listen. ask follow-ups. rinse&#x2F;repeat. asking about &#x27;business goals&#x27; to the higher-ups is generally a good-ish thing. and you can&#x27;t avoid nerding out with the nerd team from the other side - but that&#x27;s easy&#x2F;fun, and they will dig that you are technically sound. but the business folks won&#x27;t necessarily care about bits&#x2F;bytes -- learning their actual uses cases, business model, etc. will go a long way towards earning their respec&#x2F;trust.<p>* like hostage negotiations, &#x27;no&#x27; is generally a word you want to avoid. better: &quot;I don&#x27;t know if we can do that out of the box, but I will check into that and get back to you.&quot; basically, don&#x27;t throw your salesperson under the bus. you might see some stuff about the importance of qualifying leads to make sure you don&#x27;t sell to the wrong customer, etc. -- ignore it -- it&#x27;s just puritanical, nonsensical grandstanding.<p>* don&#x27;t slack&#x2F;teams&#x2F;email&#x2F;text to folks (like a teammate) during a demo -- because.<p>* being responsive is really cool, but like any position, be careful of burnout.<p>* i think having realistic expectations about what you can get Engineering to do in terms of easing onboarding is important. e.g. 15 min of ENGR time can cut your customer onboarding time from 2 weeks to 2 hours? yeah, don&#x27;t count on it happening. else, you&#x27;ll pretty quickly mentally check out. lobby and document, make your case, but stay measured. find a way to tie the shorter onboarding time to increased revenue, etc., and now you got something.<p>* if you can get access to and own the documentation&#x2F;training process, you will actually save yourself tons of time. at least the API&#x2F;dev&#x2F;integration docs. you want to be able to go to the source doc and fix something immediately without overhead process. kind of obvious, but....same thing, temper your expectations. if you have to do some things manually with each install, you&#x27;re not going to die. even small improvements will keep you motivated&#x2F;hopeful.<p>* assuming you do get a new customer up and running -- it would be nice to survey them and get their feedback on what could have been better. yeah, asking for work, and i&#x27;ve never done it, but...i feel like most people are lazy idiots. and&#x2F;or scared. so it prob won&#x27;t happen unless you do it, or unless you have a competent customer success department already (do they exist?).<p>* with your documentation, spell it out. you&#x27;re _right there_. your &#x27;customer&#x27; is &#x27;in market&#x27;. just tell them how to use your stuff. in detail. if you want to link out to supporting docs, fine. but why deliver them only 73% of the way to the promised land? take them all the way there.<p>* i like the idea of filing feature&#x2F;change requests, especially for usability things. Product Managers have 8 trillion things to worry about, and even if they&#x27;re geniuses, they are going to lose the ability to see the product with fresh eyes. they will _not_ be able to comprehend how _anyone_ could possibly not understand exactly how to fill out fields x, y, and z on some page - that&#x27;s ok - you can fill the gap. this doesn&#x27;t really matter except that it will annoy your PM and make your product a lot better. kind of up to you if you want to go that route. helpful to have these conversations offline before you document, in the (virtual) coffee room, if you can, b&#x2F;c once you file a Jira - it&#x27;s like an affront to the PM. not sure why - it just is. in fairness to the PM, they&#x27;ve usually considered a feature request from 20 diff angles, so even if they have an obvious blind spot, their expertise&#x2F;experience can help you clarify your own thinking.<p>best of luck! please give yourself a calendar reminder for 1 year from now and tell us how it&#x27;s going! :-D