Ask HN: How do I prepare for a job as an Implementation Consultant?
33 comments
R&D ML software dev --> Implementations Consultant seems like a pretty drastic change in roles. You're going from a very technical role to something that is very fundamentally soft-skills based. You'll be a communication pipeline between your company's sales and product teams, and your clients. You'll need to learn how to deeply investigate a client and figure out their needs, in a short amount of time, and then translate that foreign data into your internal company "language" and goals framework. You'll be dealing with two sets of politics at once, and be expected to move and translate seamlessly between the two. You're fundamentally a diplomat. Your technical background will help you establish authority for what you're talking about, and your problem-solving skills will be invaluable when investigating new clients.
(disclaimer: This is all assuming that "implementations" works the way it has at the several B2B software companies I've worked at as a developer. It sounds the same from the short description given, but you never know with a new employer.)
(disclaimer: This is all assuming that "implementations" works the way it has at the several B2B software companies I've worked at as a developer. It sounds the same from the short description given, but you never know with a new employer.)
Really good points above. Having worked in SW Consulting for >9 years, the communications part is essential: you will need to 'translate' (see above) between two very different entities, acting as a conduit, and be able to switch context quickly.
Re: technical background, it will certainly give you authority, but a soft skill I lean on every day is you'll need to learn how to educate/explain in brief sentences, while still sounding enthusiastic and without any hint of eye-rolling or annoyance, even if it's a basic concept to the project or something you have a deep knowledge of.
Re: technical background, it will certainly give you authority, but a soft skill I lean on every day is you'll need to learn how to educate/explain in brief sentences, while still sounding enthusiastic and without any hint of eye-rolling or annoyance, even if it's a basic concept to the project or something you have a deep knowledge of.
Yes, it is indeed a huge shift for me. I do prefer still working on Computer Vision / ML / AI projects but my current job is not offering much in terms of growth or learning. Since I dont have that much experience in the domain of Data Science, its currently hard to land such a profile in a good company in my country.
I see this new job as a chance to explore more opportunities while building my AI/ML profile on the side.
What would be some tools or processes that would help me keep track of all the client's concerns and effectively communicate with the clients and make sure there is progress when it comes to implementations?
I see this new job as a chance to explore more opportunities while building my AI/ML profile on the side.
What would be some tools or processes that would help me keep track of all the client's concerns and effectively communicate with the clients and make sure there is progress when it comes to implementations?
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.
"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.
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?
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 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.
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.
[deleted]
You won't find the tools or processes for this in a downloadable form on a web site.
The things you'll need for this sort of job are things like:
* Clearly explaining highly technical facts and concepts in an easy to understand manner
* Reading people to understand their motivations, needs, and expectations
* Setting clear boundaries and communicating them early
* Connecting with the people you're working with and getting them to like you even if you don't really like them
* Consistently presenting an appearance of calm, control while simultaneously being excited and enthusiastic
* Learning the map of the organization and discovering who can help you, who is a waste of time, and who will actively oppose you
* Listening to bad ideas or ideas you fundamentally disagree with and handling them without being dismissive, possibly even going along with one because it gains you a position or relationship of value
All those things while being knowledgeable about your product or solution.
The things you'll need for this sort of job are things like:
* Clearly explaining highly technical facts and concepts in an easy to understand manner
* Reading people to understand their motivations, needs, and expectations
* Setting clear boundaries and communicating them early
* Connecting with the people you're working with and getting them to like you even if you don't really like them
* Consistently presenting an appearance of calm, control while simultaneously being excited and enthusiastic
* Learning the map of the organization and discovering who can help you, who is a waste of time, and who will actively oppose you
* Listening to bad ideas or ideas you fundamentally disagree with and handling them without being dismissive, possibly even going along with one because it gains you a position or relationship of value
All those things while being knowledgeable about your product or solution.
I'm not really an authority on expert implementations consulting, but off the top of my head:
>tools
A notebook. An excel/sheets spreadsheet. An open mind. People skills. A sense of humor.
>processes
Regular check-ins with stakeholders. Actually having a well-structured, end-to-end implementation plan at some point for any given client. Being willing to dramatically shift said plan on a dime in order to keep everyone happy and maintain the business relationship.
You can also work for a few years and then get a job at whatever client company you liked working with the most, pretty easily. I've seen that happen a lot.
>tools
A notebook. An excel/sheets spreadsheet. An open mind. People skills. A sense of humor.
>processes
Regular check-ins with stakeholders. Actually having a well-structured, end-to-end implementation plan at some point for any given client. Being willing to dramatically shift said plan on a dime in order to keep everyone happy and maintain the business relationship.
You can also work for a few years and then get a job at whatever client company you liked working with the most, pretty easily. I've seen that happen a lot.
My recommendation is to hone your "soft skills": make sure you're on top of communication (be quick to respond to clients and don't let emails sit for more than 24 hours), be patient (working with clients means a wide variety of team dynamics and work paces), be humble yet confident (clients like help but they also want to "be right"), and prepare for the politics inevitably dumped onto outside consultants (consultants often are called in to make hard calls that internal teams don't want to make for political reasons).
Go round up every elderly family member you have and teach them and all of their friends. Tell them you have a work project they can help you with. Interview them to see if there's some new capability they would want their phone to have. Then teach them how to use the new app or solve their issue. Try to do this all over the phone (don't give your elderly family the COVID) and guide them through it without being able to look at their phone screen. I give this advice because you are already highly technical and communicating with the engineers should be pretty easy for you.
This might sound a bit silly, but there's a significant overlap with your new role. You'll be needing to work with a lot of people with a vastly different level of technical knowledge. You'll need to do this without a guarantee that you'll get much face to face time with them at all. There will be limits to your client's attention span and willingness to participate. Your patience will be tested. You will be doing your best to communicate with each other, but it will be like ships passing in the night.
It's also a hugely rewarding role, in my opinion, since you will be helping to shape a client's future success with the product in a big way. Congratulations!
This might sound a bit silly, but there's a significant overlap with your new role. You'll be needing to work with a lot of people with a vastly different level of technical knowledge. You'll need to do this without a guarantee that you'll get much face to face time with them at all. There will be limits to your client's attention span and willingness to participate. Your patience will be tested. You will be doing your best to communicate with each other, but it will be like ships passing in the night.
It's also a hugely rewarding role, in my opinion, since you will be helping to shape a client's future success with the product in a big way. Congratulations!
Realise that you will be a translator who is paid to understand the technical enough and the business enough that the project can have a conversation.
As far as tools and methodologies - you have to use what your customers use to communicate. It may just be emails as some of the other commenters have said - have a meeting, write up the notes, email the notes.
Once you are past design stage and into user acceptance test and go live you will need an issue tracking tool. Maybe your customer’s IT department has a help desk system that you can integrate with. Be very cautious of using unsecured SAAS products - only document security issues about your implementation on Google sheets if you are 100% confident of who can see it. I am never that confident and want to work somewhere the customer’s IT security is happy with.
I would recommend the book Flawless Consulting by Peter Block. It’s about management consulting at a more senior level than implementation consulting but the points about agreeing with the customer what they need to provide to you for you to do your job are very valuable.
You need to explain to your customer the consequences of choices. Sales are often happy to say “yes we can build that”. But really the standard configuration takes 1 month to implement, 30 custom features take much longer.
Disclaimer I moved from functional into implementation (accountant into implementing finance systems) which is different from technical into implementation.
As far as tools and methodologies - you have to use what your customers use to communicate. It may just be emails as some of the other commenters have said - have a meeting, write up the notes, email the notes.
Once you are past design stage and into user acceptance test and go live you will need an issue tracking tool. Maybe your customer’s IT department has a help desk system that you can integrate with. Be very cautious of using unsecured SAAS products - only document security issues about your implementation on Google sheets if you are 100% confident of who can see it. I am never that confident and want to work somewhere the customer’s IT security is happy with.
I would recommend the book Flawless Consulting by Peter Block. It’s about management consulting at a more senior level than implementation consulting but the points about agreeing with the customer what they need to provide to you for you to do your job are very valuable.
You need to explain to your customer the consequences of choices. Sales are often happy to say “yes we can build that”. But really the standard configuration takes 1 month to implement, 30 custom features take much longer.
Disclaimer I moved from functional into implementation (accountant into implementing finance systems) which is different from technical into implementation.
Yes, thank you for giving a heads up over the security issue especially for a startup working on data privacy
So this is a pretty wide-ranging role, although that's not unusual for small companies/startups.
Typically the skillsets for a sales engineer/consultant and a post-sales engineer/implementation consult are overlapping but different.
In many organizations the pre-sales engineers are there to answer technical questions during the sales process - "will this integrate with X?" "can I solve Y problem?" "how many concurrent users does this support?"
The post-sales consulting team is there to actually wire up the integration with X, solve Y problem, and tune the performance to support Z concurrent users.
The challenge with a hybrid role is balancing zooming out to being aware of the strategic "making the sale" parts of being a sales engineer to the super low-level nuts and bolts connecting things together of post-sale consulting.
In either case clear communication and listening are the key skills I would work on. The ability to actually hear what a customer wants, and clearly communicate that you understand what they want and can deliver it is a difference maker on either side of a sale.
I've worked in both roles, both are rewarding and frustrating for their own reasons - good luck!
Typically the skillsets for a sales engineer/consultant and a post-sales engineer/implementation consult are overlapping but different.
In many organizations the pre-sales engineers are there to answer technical questions during the sales process - "will this integrate with X?" "can I solve Y problem?" "how many concurrent users does this support?"
The post-sales consulting team is there to actually wire up the integration with X, solve Y problem, and tune the performance to support Z concurrent users.
The challenge with a hybrid role is balancing zooming out to being aware of the strategic "making the sale" parts of being a sales engineer to the super low-level nuts and bolts connecting things together of post-sale consulting.
In either case clear communication and listening are the key skills I would work on. The ability to actually hear what a customer wants, and clearly communicate that you understand what they want and can deliver it is a difference maker on either side of a sale.
I've worked in both roles, both are rewarding and frustrating for their own reasons - good luck!
Thank you, since i'll be one of two consultants in my country for the said startup, I will need to take up a wide-ranging role.
I have a huge learning curve ahead of me and want to prepare beforehand, so I don't get too overwhelmed.
I have a huge learning curve ahead of me and want to prepare beforehand, so I don't get too overwhelmed.
One thing I've learned about startups is that things are always in flux. I would expect your responsibilities to move and shift with time and with different clients.
The position sounds like it will lean heavily on communication and social skills. You will likely want to build a strong relationship with your sales staff and your client.
If in the course of work changes arise make sure you coordinate with your company and do not over promise or move too far from the core solution.
The best thing that will prepare you is to go in with an open mind and do your best. Try not to stick to preconceived ideas of what the job is.
And most of all, be prepared to work hard.
The position sounds like it will lean heavily on communication and social skills. You will likely want to build a strong relationship with your sales staff and your client.
If in the course of work changes arise make sure you coordinate with your company and do not over promise or move too far from the core solution.
The best thing that will prepare you is to go in with an open mind and do your best. Try not to stick to preconceived ideas of what the job is.
And most of all, be prepared to work hard.
I'm considering a similar opportunity. The implementation role I've been offered will be crucial in securing longer-term contracts for my employer. I'm curious what variable-compensation structures others have seen for this sort of position. Is it reasonable to expect a percentage of successfully secured longterm contracts, or something based on retention? Aside from an equity package, how can someone in this position be incentivized in a way commensurate with their value?
It depends on whether you are expected to participate in those sales cycle discussions or not.
If your role is to hang out at your desk until someone sells your implementation services, then no, you will probably not get commission on sales. You should demand a fixed salary comparable to if you were a SWE working on the product directly.
If you are expected to participate in the sales cycle in some way (like stitching together a demo), you will probably receive some sort of commission.
This is a pretty fair thing to ask about in an interview or in comp discussions. "Am I expected to be involved in sales efforts, or am I simply deployed after the sale?" Adjust salary/commission demands accordingly.
If your role is to hang out at your desk until someone sells your implementation services, then no, you will probably not get commission on sales. You should demand a fixed salary comparable to if you were a SWE working on the product directly.
If you are expected to participate in the sales cycle in some way (like stitching together a demo), you will probably receive some sort of commission.
This is a pretty fair thing to ask about in an interview or in comp discussions. "Am I expected to be involved in sales efforts, or am I simply deployed after the sale?" Adjust salary/commission demands accordingly.
Hey OP,
I'm a technical account manager / CSM and your role honestly sounds a lot like mine. Did a writeup of my role here: https://www.careerfair.io/reviews/customersuccessmanager
Hope you find it useful. Lmk if any questions :)
I'm a technical account manager / CSM and your role honestly sounds a lot like mine. Did a writeup of my role here: https://www.careerfair.io/reviews/customersuccessmanager
Hope you find it useful. Lmk if any questions :)
You are switching from a technical to a non-technical job.
your job role and responsibility will be fully changed. communication skills(Kindness, Politeness, Empathy) will play a key role here. But as you are from a technical background this is a plus point with you.
The best person to answer that question is your future manager.
how did you get the job without really knowing how you were going to fulfill the requirements?
I know the job requirements. I was asked to interview with them, thanks to my technical background and presentation skills, I was offered the role.
I'm just asking to make sure I'm prepared. There's always something to learn from other people with significantly more experience.
I'm just asking to make sure I'm prepared. There's always something to learn from other people with significantly more experience.
[deleted]
so you're essentially going to become a Technical Project Manager. that's interesting - i'm searching for TPM jobs, maybe i should include implementation consultant postings as well.
They have told me that my title will be "Implementation Consultant" but im expected to do sales, integration, support etc.
Thats also mostly because they dont have a team in my country as such. I have only one other co-worker who does everything but doesn't belong from a technical background.
I will be doing everything he does and also handle the technical issues.
Thats also mostly because they dont have a team in my country as such. I have only one other co-worker who does everything but doesn't belong from a technical background.
I will be doing everything he does and also handle the technical issues.
qualifier: i don't know anything about anything.
that said, here is my _expert_ advice:
* 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'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'm assuming that you are not stupid and/or lazy.
* there are some sales and even sales engineering books/course/etc. out there. most are terrible, or worse, especially the ones that people 'highly recommend', but i do feel like learning to sell/sales is double-plus-good. one core aspect is learning to ask good/probing questions, and then learning to shut up and listen. ask follow-ups. rinse/repeat. asking about 'business goals' to the higher-ups is generally a good-ish thing. and you can't avoid nerding out with the nerd team from the other side - but that's easy/fun, and they will dig that you are technically sound. but the business folks won't necessarily care about bits/bytes -- learning their actual uses cases, business model, etc. will go a long way towards earning their respec/trust.
* like hostage negotiations, 'no' is generally a word you want to avoid. better: "I don't know if we can do that out of the box, but I will check into that and get back to you." basically, don't throw your salesperson under the bus. you might see some stuff about the importance of qualifying leads to make sure you don't sell to the wrong customer, etc. -- ignore it -- it's just puritanical, nonsensical grandstanding.
* don't slack/teams/email/text to folks (like a teammate) during a demo -- because.
* being responsive is really cool, but like any position, be careful of burnout.
* 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't count on it happening. else, you'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.
* if you can get access to and own the documentation/training process, you will actually save yourself tons of time. at least the API/dev/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're not going to die. even small improvements will keep you motivated/hopeful.
* 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've never done it, but...i feel like most people are lazy idiots. and/or scared. so it prob won't happen unless you do it, or unless you have a competent customer success department already (do they exist?).
* with your documentation, spell it out. you're _right there_. your 'customer' is 'in market'. 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.
* i like the idea of filing feature/change requests, especially for usability things. Product Managers have 8 trillion things to worry about, and even if they'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's ok - you can fill the gap. this doesn'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/c once you file a Jira - it's like an affront to the PM. not sure why - it just is. in fairness to the PM, they've usually considered a feature request from 20 diff angles, so even if they have an obvious blind spot, their expertise/experience can help you clarify your own thinking.
best of luck! please give yourself a calendar reminder for 1 year from now and tell us how it's going! :-D
that said, here is my _expert_ advice:
* 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'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'm assuming that you are not stupid and/or lazy.
* there are some sales and even sales engineering books/course/etc. out there. most are terrible, or worse, especially the ones that people 'highly recommend', but i do feel like learning to sell/sales is double-plus-good. one core aspect is learning to ask good/probing questions, and then learning to shut up and listen. ask follow-ups. rinse/repeat. asking about 'business goals' to the higher-ups is generally a good-ish thing. and you can't avoid nerding out with the nerd team from the other side - but that's easy/fun, and they will dig that you are technically sound. but the business folks won't necessarily care about bits/bytes -- learning their actual uses cases, business model, etc. will go a long way towards earning their respec/trust.
* like hostage negotiations, 'no' is generally a word you want to avoid. better: "I don't know if we can do that out of the box, but I will check into that and get back to you." basically, don't throw your salesperson under the bus. you might see some stuff about the importance of qualifying leads to make sure you don't sell to the wrong customer, etc. -- ignore it -- it's just puritanical, nonsensical grandstanding.
* don't slack/teams/email/text to folks (like a teammate) during a demo -- because.
* being responsive is really cool, but like any position, be careful of burnout.
* 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't count on it happening. else, you'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.
* if you can get access to and own the documentation/training process, you will actually save yourself tons of time. at least the API/dev/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're not going to die. even small improvements will keep you motivated/hopeful.
* 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've never done it, but...i feel like most people are lazy idiots. and/or scared. so it prob won't happen unless you do it, or unless you have a competent customer success department already (do they exist?).
* with your documentation, spell it out. you're _right there_. your 'customer' is 'in market'. 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.
* i like the idea of filing feature/change requests, especially for usability things. Product Managers have 8 trillion things to worry about, and even if they'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's ok - you can fill the gap. this doesn'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/c once you file a Jira - it's like an affront to the PM. not sure why - it just is. in fairness to the PM, they've usually considered a feature request from 20 diff angles, so even if they have an obvious blind spot, their expertise/experience can help you clarify your own thinking.
best of luck! please give yourself a calendar reminder for 1 year from now and tell us how it's going! :-D
Thank you so much for the comment (I chuckled quite a bit).
The biggest worry I have right now is after a while I might just start getting bored or frustrated. I love learning new things and building too.
Lets see, how it all turns out.. HN wont let me update you after a year though, the post will get archived :(
The biggest worry I have right now is after a while I might just start getting bored or frustrated. I love learning new things and building too.
Lets see, how it all turns out.. HN wont let me update you after a year though, the post will get archived :(
I have been told, I'll need to handle the following tasks: - Presenting the products to the client - Helping with implementation / integration - Helping the clients with after-sales etc. - Maybe to conduct workshops every now and then.
I'm currently working as a software dev on an R&D team for building ML prototypes. I understand the job role mentioned mostly is similar to sales engineer.. but this is the first time I will be taking on such a role.
Is there something I need to prepare in terms of tools/methodologies etc before starting the new job?
PS: The startup is not based in my country, I will be mostly working with just a single other coworker, so mostly on my own