[HN Gopher] Ask HN: How to onboard yourself to a new product/ind...
___________________________________________________________________
Ask HN: How to onboard yourself to a new product/industry in a new
job?
E.g. I've never been strong at finance (always at the bottom of the
class) but I've joined a startup 2 months back that makes a b2b
saas fintech product, to lead marketing (first mktg hire in in a
total 12 member team). I've worked with the founder before and I
like the company. The founder has mentioned that it'll take time to
learn the nuances of the product/industry but since I'm a somewhat
senior person (9 years exp.), I wanted to see if there are any best
practices out there to increase the speed of knowledge
transfer/onboarding so that I can connect the dots faster, so to
speak. We do have a set of required reading material that I've
gone through, along with product demos, and even 2 VC books that
have been recommended on the subject. But unfortunately, I still
feel left behind. I need repetition to understand something deeply.
Kind of like rote. The lack of knowledge is obviously going to
affect my growth somewhere down the line as well as in identifying
opportunities for the company's growth. I'm looking for advice on
what can I do more from folks who joined a company/product/industry
that they knew nothing about and how long it took you to get
comfortable with it?
Author : sujdes
Score : 169 points
Date : 2024-03-21 11:28 UTC (11 hours ago)
| sebstefan wrote:
| I've found that these two tips help
|
| * Putting in time to learn the product as a _user_ of it before
| trying to develop for it is time well spent. In my experience it
| makes it easier to read the code afterwards
|
| * When a codebase is old and you're reading a file where 10 to 20
| developers have done a pass of bugfixes on it, it may not
| immediately be obvious what everything does and why some checks
| are being done. Going through the history and checking earlier
| versions of the file sometimes helps me getting the basics of it
| down
| tetris11 wrote:
| The first point is one I strongly agree with. It is
| bewildering, trying to understand a codebase from the bottom
| up. The best part of learning it as a user, is that you can
| also make meaningful edits to the product page or user
| documentation that is often completely overlooked by devs.
| rco8786 wrote:
| OP is in marketing, not eng, FWIW.
| sebstefan wrote:
| Oop, nevermind then
| epr wrote:
| > Putting in time to learn the product as a user of it before
| trying to develop for it is time well spent
|
| This should always be priority #1 when you first arrive. Not
| only is it beneficial for understanding your work, but you can
| never get back that opportunity to see through the eyes of a
| real user. Once you get used to a product, the warts will be
| less apparent.
|
| Put the product through it's paces, and take notes on what's
| confusing or unintuitive. You don't want to tell everyone their
| baby is ugly immediately, but you can slowly address at least
| some of the issues over time.
| rco8786 wrote:
| I have a very specific (and pretty easy) strategy for this when I
| join a new org. Technically you could do this at any time, but
| you generally have a "grace window" when you're new where people
| are happy to go out of their way to meet you and teach you.
|
| First, meet 1 on 1 with every member of your immediate team. This
| of course serves as a "get to know you" meet, but your real goal
| is to get them to explain their work to you. Have them go into as
| much detail as time allows on whatever they're currently working
| on. Ask followup questions that start with "why" on _everything_.
| Have them show you their part(s) of the product, have them share
| as many docs as they 're willing to (for you to read async
| later), etc.
|
| Put aside whatever ego you may have, and just get into a
| beginner's/learning mindset. Ask all the stupid questions.
|
| Then, at the end, ask them who else they're working with from
| other teams. Put those names on a list, and rinse and repeat with
| them. This way you'll start local to your role and work your way
| outward in the company. Eventually you'll find people that are
| doing nothing particularly relevant to you and you can decide to
| stop.
|
| If it's a larger company, this is also where you establish your
| understanding of the org chart and who does what in it, and also
| makes you known to a ton of folks who may want or need to work
| with you in the future - which is invaluable in and of itself.
| b-karl wrote:
| I have not done the 1 on 1 method before, it sounds interesting
| and will try it in the future, but I agree with utilizing the
| grace period to explore, ask and learn as much as possible
| about the organization and industry.
|
| My additional recommendation would be to try to identify
| limited-scope projects that contribute to your role and where
| you can start delivering some value. For me this helps set a
| clear goal and it is usually easier to identify the specific
| skills/knowledge/information/contacts I need to complete the
| task. It also usually feels motivating to check off those early
| projects.
| gamepsys wrote:
| > My additional recommendation would be to try to identify
| limited-scope projects that contribute to your role and where
| you can start delivering some value.
|
| If you are in a leadership role over a team then having a
| pre-chewed problem ready for new members of your team is a
| very useful thing you can do. I'm talking well defined
| problem with a clear path towards success. This helps the new
| member become use to the team and processes, and gives them
| an easy win to put some wind in their sails. Also, this can
| serve as a litmus test to their on the job performance.
| PaulHoule wrote:
| It can work really well but you can sometimes find
| individuals who won't play along.
| maroonblazer wrote:
| In which case that's good feedback to give to management.
|
| Unless they have very good reasons and offer an alternative
| ("I'm on deadline so can't talk now, but after this sprint
| I'll have time.") those individuals are actively sabotaging
| the team and should be dealt with accordingly.
| PaulHoule wrote:
| Often management knows all about it and does nothing for
| one reason or another.
|
| I had two cases of having a toxic coworker and only being
| able to get them fired after leaving myself. (Step 1 is
| "oh shit, we lost an important team member", Step 2 is
| "aha! we haven't been able to replace that team member in
| six months because of the behavior of the toxic
| employee"). Next thing I see the person is on LinkedIn
| looking for a new job.
| efxhoy wrote:
| Completely agree.
|
| It's also a fantastic way to get to know how the org is doing,
| many people will be happy to share what parts of the product
| they're happy with and where the dumpster fires are.
|
| I also think it's useful for the people you're talking to as
| they get an opportunity to reflect on what they're doing and if
| it makes any sense. It's like an external auditor or reviewer
| coming in. Just pronouncing what you're doing in a way that's
| understandable to an outsider can be very helpful in building
| your in understanding imo.
| rco8786 wrote:
| > Just pronouncing what you're doing in a way that's
| understandable to an outsider can be very helpful in building
| your in understanding imo.
|
| Totally. It's the same idea around rubber ducking!
| mannycalavera42 wrote:
| subscribing to everything, rco8786 let me know if you are
| hiring anytime soon :rotfl:
| jimberlage wrote:
| This is fantastic advice! One additional thing I do is
|
| Identify people they don't work with, that you would naturally
| assume they would. Typically this means:
|
| Your understanding of how processes flow in this industry has
| some gaps, or some thing you thought was crucial is a solved
| problem that people don't think about; or
|
| There is tension and some history here, tread lightly while you
| figure out the office politics; or
|
| You've identified a legitimate opportunity! Be careful here
| though, you need to understand if some higher ups have
| misaligned incentives to keep the status quo before you suggest
| changes.
| DavidPeiffer wrote:
| This process was mandatory at my last company, and it was
| really helpful. People are _way_ more likely to respond to your
| email or do something for you as a newer employee if they 've
| met you, particularly so if you can meet in person.
|
| Taking notes during or immediately after the meeting, then
| synthesizing them to form a narrative is also helpful when
| you're meeting so many people.
|
| The other thing I do is start a file literally titled
| "Everything I know about <company>" and just write everything
| down. I make diagrams, write sentences with highlighted blank
| spaces for gaps in knowledge, etc. As you get to the 10th
| meeting, you have a decent mental model of how things are
| intended to work, and have probably heard about some of the
| systems the 11th person works with. When you communicate some
| of your understanding of the system to them, they can fill in
| gaps or correct misunderstandings.
|
| The other thing I always ask about is what a cadence or work
| looks like? Is there seasonality in their availability?
| Finance/accounting are best left alone the first week of the
| month as they're dealing with month end. Some people are
| slammed Monday and Tuesday, catching up from things that
| happened over the weekend. If an entire business is seasonal,
| it makes sense to prioritize heavy lift projects to the off-
| season.
| KineticLensman wrote:
| > If an entire business is seasonal, it makes sense to
| prioritize heavy lift projects to the off-season
|
| One form of seasonality is associated with financial years,
| in some industries. I found this working on contracts for UK
| govt agencies, where the FY runs from April to March. The
| customers usually procrastinated about letting contracts,
| which sometimes wouldn't appear until after the summer or
| even just before Christmas. Then there was a mad panic from
| Jan to March to actually spend the money and submit those
| deliverables. It followed that the time to do training,
| internal projects, housekeeping etc, was in April and May.
| robviren wrote:
| 100% support this approach. My knowledge of product has always
| been less important than my knowledge of the people, resources,
| and structure of my organization. I don't need to know things,
| I need to know who knows things. At least at the start.
| j45 wrote:
| This is a nice summary. Being an innocent beginner helps convey
| your ability to lead yourself and work with a team at the same
| time.
|
| One tweak I do is assume your grace window is half the length
| you're told or believe. Building up a bit of momentum in case
| it's needed if something comes up is helpful.
| samstave wrote:
| I've always done this as well!
|
| Another strategem is to ask the people you meet with 1:1 how
| they feel you may help them be more successful. What can you do
| in their current workflow that will spread load, help you
| learn, help them succeed.
|
| Most times you get "just happy to have you on board" but you
| can get valuable feedback as well as an understanding of stress
| levels of others on and off team.
| epolanski wrote:
| > Put aside whatever ego you may have, and just get into a
| beginner's/learning mindset. Ask all the stupid questions.
|
| This so much.
|
| Play fool to catch wise sung Bob Marley and it works wonders.
| spacecadet wrote:
| Talk to people. Interview your entire team, with detailed
| questions, avoid solutioning out of context, just listen. Next
| extend those interviews to stakeholders your team supports- go as
| deep or as high as you can, adjust questions for context, execs?
| business/strategy questions, the janitor? the dirt questions...
| yes interview the cleaning crew...
|
| Ive done these rounds at every job and 2 times I left that job
| immediately after the interviews.
| jstanley wrote:
| > I left that job immediately after the interviews.
|
| Why?
| omarhaneef wrote:
| If you read between the lines, it would seem no one was
| keeping the place clean.
| zabzonk wrote:
| to be honest, if you are in marketing and you don't understand
| the market you are trying to sell into i don't see this going too
| well.
| chasd00 wrote:
| It can if they have time to get up to speed but if they're
| thrown right at clients/customers probably not. I consult and
| develop on a very complex platform, both in breadth and depth.
| I routinely have to correct their sales/marketing people and
| account executives on platform capabilities and even
| pricing/licensing. I try not to do it in front of clients but
| sometimes have to. You're right in that it doesn't go well.
|
| edit: actually, i've seen this work. The marketing person has
| to be honest and upfront about being new and take down any
| questions they can't answer and then follow-up. I've found
| clients/customers to be sympathetic, everyone has been thrown
| into the deep end at some point in their career. A humble and
| honest approach can even endear them to the customer. So, it
| can work but the you have to upfront, honest, and absolutely
| follow-up.
| esafak wrote:
| You'd learn, wouldn't you? Other marketers were not born with
| the knowledge either.
| tedhallez wrote:
| I'm facing a similar challenge, but for Sales within the defense
| industry.
|
| I've approached it by reading and thinking about the company's
| relationship to it's stakeholders. Understanding and writing
| mini-essays on the current customers and their pain points, the
| main competitors and their products, the history of the
| industry/segment and more.
|
| Information sources include YouTube, podcasts, press releases,
| news articles from niche sites, research paper summaries and
| various websites.
|
| Networking of course plays a role, where I've sought out friendly
| people a few years ahead of me when it comes to industry
| knowledge. Mostly through existing contacts I'd do this again if
| I needed to, and would make sure to leverage each new contact to
| introduce me to further relevant people.
|
| I've asked ChatGPT specifically to detail out how a MBB-
| consultant would approach the knowledge acquisition challenge, as
| they are adept at quickly navigating and learning a new field in
| a short amount of time. This has helped somewhat and suggested
| I'd sit down a perform a few different types of analyses.
|
| As for rote learning, I've bought into the Anki flashcard system
| where i study acronyms, enemy materiel NATO designations,
| specifications and more.
|
| To wrap up, I've studied finance myself and I have a strong
| feeling that there's a low correlation between financial-academic
| success and proficiency in marketing in the industry... Best of
| luck!
| wikidani wrote:
| If you don't mind me asking, what does a sales role within the
| defense industry entails? I am only familiar with the big expos
| and (sort of) public tenders for specific things like PPE
| qznc wrote:
| Second Anki!
|
| Joining an industry/domain/organization also means learning the
| language there. The acronyms are vocabulary.
| joby_surge wrote:
| You should join the product marketing alliance which has
| frameworks & an active slack community that can help you out.
| joloooo wrote:
| I'm assuming you're a member; what is the value you enjoy most
| from PMA? I've been on the fence.
| kerkeslager wrote:
| As a freelance software developer, I've worked in finance, law,
| logistics, pharmaceuticals, cable TV, food sales, and probably a
| few more I'm not remembering off the top of my head over the
| years. I provide the best service to my clients when I understand
| the domain well enough to make suggestions that marry the
| capability of the computer and the web to their domain. It helps
| that I have repeat clients often, and referrals within the same
| industry so I can re-use knowledge from previous contracts, but
| often I'm working on software for a domain I have no prior
| knowledge for. So it's a high priority for me to be able to
| obtain a lot of information about the domain quickly.
|
| Here are my tips:
|
| 1. Schedule time to ask questions. Domain experts' time is
| valuable, and you don't want to be interrupting their other work,
| so if you can build up a list of questions and schedule a 30
| minute period to ask all your questions, that uses their time
| more effectively, and also gives them the opportunity to take the
| time to answer the questions you didn't ask. (OP doesn't appear
| to be a freelancer, but for any freelancers reading this, I don't
| bill for this time, which helps clients to feel they're getting
| something worthwhile from it).
|
| 2. Ignore "rank". The people on the bottom of the totem pole are
| often the people who know the most about the domain because they
| are actually working waist-deep in the domain. There have been
| cases where I have used my seniority to escalate problems or
| promote ideas from, say, an intern or junior, that were likely
| more valuable than the development work I was getting paid for.
| When you do this, be sure to give credit where it's due--people
| remember that sort of thing.
|
| 3. There comes a point somewhere in the 3-6 month mark at a job,
| where I start getting a lot of anxiety because I feel like I
| should understand the domain better than I do. This has never, in
| my experience, been anyone else's expectation. It's just impostor
| syndrome.
| koliber wrote:
| In addition to the 1:1 suggestion that rco8786 wrote (
| https://news.ycombinator.com/item?id=39777488 ), immerse yourself
| in conversations. Watch recordings of standups, all-hands, sales
| calls, and whatever you can get your hands on. Attend meetings
| and sit quietly in the corner. Listen.
|
| Much of it will be foreign. Over time, more and more will make
| sense. It will begin to gel.
|
| Take notes on words and phrases that are unclear. Google them.
| See who you can ask about help (see the 1:1s strategy).
|
| Repetition is important in learning. Everyone learns differently.
| I like multi-modal reinforcement. Listen in groups, QA in 1:1s,
| read books, search Google, try by doing. It all somehow comes
| together and all of a sudden you're riding the bike without
| paying attention to your feet and hands.
| RecycledEle wrote:
| Look at the training materials, and look up every word in them.
| research until you can give an example of how everything is used.
|
| There are probably old time finance people running the company ir
| advising it. Find out what they did back in the day and look at
| things from that point of view.
| ipnon wrote:
| I have a simple method that worked well for me in my last job,
| where I switched industries completely and was definitely
| underwater. First I became friends with everyone I could. Then
| identified the most mature teammate with the most tenure, and the
| smartest teammate who clearly generated the most value for the
| company.
|
| Anytime I got stuck on a problem for more than a few hours, I
| asked the greybeard for a quick chat. He was pretty always
| willing to hear me out, let me break down my understanding, then
| rebuild all my faulty assumptions. His time was relatively cheap
| but his knowledge base relatively valuable, so with him I did
| deep dives.
|
| The smart hacker guy I watched from a distance. Any time I saw
| him merge some ludicrous Rube Goldberg type commit I'd send him a
| quick DM, knowing his time was precious. I'd fire off a few quick
| questions and try to glean as much insight into his critical work
| before he scurried off to the next apparently invaluable task.
|
| I think approaching the problem this way, leveraging the
| "implicit theories" embedded in the teammates heads, is the
| surest and most efficient way to ramp up, besides the obvious
| advice like RTFM and gloss over the relevant textbooks. Always
| remember to make yourself useful first. No accomplished engineer
| will ever turn down a well intentioned and friendly favor! "Team
| work makes the dream work," as they say.
|
| Good luck!
| VladimirGolovin wrote:
| Take my advice with a grain of salt, but:
|
| Get a ChatGPT4 subscription and ask away. It may hallucinate, but
| it lets you ask questions and immediately clarify points you
| don't understand. When you get the basic understanding, check it
| against a more reputable source (e.g. Investopedia?)
|
| Here's an example question (which I obviously made up):
|
| "Hi! I'm about to get a job in finance but I feel that I don't
| fully understand some of the important concepts, such as compound
| interest. Can you explain compound interest to me?"
| Kon-Peki wrote:
| These books, which are expensive because I don't think they're
| printed anymore, are going to be far more useful than GPT:
|
| https://www.amazon.com/Dictionary-Finance-Investment-Busines...
|
| And since the resale value is extremely high, so you can always
| resell if/when you don't need them anymore, possibly for a
| profit.
| Roelven wrote:
| Regardless of your job or responsibilities, if you are new to a
| certain domain, find users or customers to talk to. If you can't
| talk to them directly, find colleagues who do, and ask to be a
| fly on the wall. Meet at least 10. Write down their day to day
| jobs, their challenges and their frustrations. Even from just
| listening to others talk, you will get a good perspective.
|
| To speed it up, write an interview script with a set of
| questions. Use an LLM to make the questions non-leading if you
| want, but point is to show colleagues who have customer contact
| your script. If you manage to do the interviews, record them,
| transcribe them and share them around. You are now a customer
| advocate who knows the customer's needs and wants.
|
| Don't wait with doing this only after you've met the team, start
| immediately. Let this be your driving force to meet colleagues.
| It's useful, offer to share the results, or ask for question
| ideas to whoever wants to listen to you.
|
| You now have laid the groundwork for your success. Now you can
| focus on the organisation, the team, the mission, the
| proposition, etc. Everyone you now meet, talk about how customers
| want to do A or B but can't, or about their challenges. People
| will appreciate your insight and you're off to a great start!
| newsclues wrote:
| Read. Trade publications, textbooks, news. Ingest everything,
| take notes and ask questions.
|
| Showing an interest is important, learning the lingo is important
| but it will be a learning curve and it's important not to expect
| too much from yourself too soon.
| enjoyitasus wrote:
| LLM Agent support
| itqwertz wrote:
| Make friends with the people around you. You'll pick up things by
| osmosis, be able to ask "stupid" questions without revealing your
| lack of knowledge to anyone who might see this as weakness.
|
| whenever you see a term or concept you don't understand, WRITE it
| down. The brain-body connection works well for your memory.
|
| I'm gonna get flak for this, but going out drinking and to the
| smoking area will give you an inside track to how the company
| operates.
| decafninja wrote:
| Controversial take from me. Also this was more in the context of
| legacy finance tech whereas you are in fintech.
|
| I used to work in tech at an investment bank. When I first joined
| I was all starry eyed and eager to learn about the business, even
| to the point of trying to get a CFA (which some of my colleagues
| apparently had done).
|
| Fast forward many years, I came to the conclusion that the
| limited time I had was best spent becoming a better
| technologist/engineer instead of a halfassed
| banker/trader/investment professional. Of course it's still
| useful to know the basics of the industry and anything specific
| to your role, but beyond that the returns diminish sharply.
|
| FWIW most of my engineer colleagues that spent all that grueling
| time and effort to get a CFA no longer work in the finance
| industry, so it's arguably all down the toilet unless they ever
| go back. AFAIK none of them want to
| eitally wrote:
| I think this isn't controversial on the tech side, but on the
| business side it is absolutely 100% more important to deeply
| understand the business and build a meaningful, useful network
| than it is to half-ass your way on the tech side. As careers
| advance in business, doors to new opportunities open primarily
| based on one's reputation & network, so it pays dividends to
| focus on cultivating those starting as early as possible.
| "Managing up" should not be an epithet, but a way of life.
| rohanm93 wrote:
| I covered this in a recent issue of a career newsletter I write
| [1]. Some snippets from it that I think would help new joiners
| (not only those joining a new industry):
|
| 1. No-one's going to go out of their way to guide you. Esp at
| smaller companies, the fact that you've been hired means you're
| joining a time-poor company, and there likely won't be a formal
| onboarding process. So...you've got to onboard yourself.
|
| 2. Adopt a mindset of personal responsibility. This isn't going
| to be a passive process, but an active one.
|
| 3. Don't meet everyone for the sake of it. The goal isn't to set-
| up endless meetings and become a burden. Limit yourself to a few,
| and make the most out of them. Make your ask clear when you ask
| someone for their time -- e.g. 'I'd like context on X and what's
| been done so far'
|
| 4. Get some small wins on the scoreboard. Although your priority
| is to learn the key skills of the job, you also want to make a
| great impression during your first 60 days by showing you've made
| an impact. To do that, identify some smaller projects you can
| knock out to get a few small wins under your belt.
|
| 5. Be 'seen'. Make your presence known. And communicate upwards
| so people know you're busy. How? Tell your manager, "Can I send
| you a list of 5 things I think I need to hit the ground running?
| I'll then set up a 1-1 and we could go through that."
|
| the full essay's here [2] (and plug: the newsletter I write is
| called Coached. If occasional career strategy is your thing, feel
| free to check it out)
|
| [1] https://coached.com
|
| [2] https://careersupplement.beehiiv.com/p/cs233-onboarding-
| hard...
| UncleEntity wrote:
| This is also sound advice for someone wanting to join an
| established open source project.
|
| Pluck some of the low-hanging fruit so they can get to know you
| and try not to be a burden on the core maintainers. And...have
| fun?
| sevagh wrote:
| I think starting off with the impression of being a small
| wins person sticks, and people will think of you as "does
| small tasks well." No promos and whatnot.
|
| It's why being a loud jackass that deploys something
| horrendous has better outcomes for your career.
| omarhaneef wrote:
| All these suggestions are great but I would add two more:
|
| 1. find a good text book in the field as narrowly construed as
| possible, and just browse the table of contents.
|
| This will give you a quick map of the field, and a place to put
| all the info you gain.
|
| 2. Read the management discussion in the 10k of a public version
| of the company you work at and 2 leading customers, and the
| transcript from the earnings call.
|
| Fastest way to get up to date on challenges.
| bzmrgonz wrote:
| Nice, we are going macro now. This is often overlooked, if you
| did a lateral industry shift, you have to get conversant in the
| industry lingo asap, so don't forget the jargon and concepts.
| Most standard industries are well documented, even though the
| documentation may be less than stellar (I'm personally looking
| for IP industry material to binge on, nevertheless, because
| it's IP(intellectual property), they don't publish much
| training/guide material). I tend to do the book thing but on
| subreddits of the particular sector/industry, I think that
| browsing topics on reddit is the fastest way to get conversant
| and begin to absorb knowledge, or more specific, awareness of
| existence of knowledge.
| galdosdi wrote:
| > 2. Read the management discussion in the 10k of a public
| version of the company you work
|
| YES! Management's Discussion of Risks section of 10ks is
| amazing, and really easy to read.
|
| I think it's nuts to work at a public company and NOT follow
| your employer's 10ks and earnings calls (at least on and off,
| or at least when newly hired as well as for context any time
| there's Big Corporate News)
|
| It really helps cut through management's BS when you can just
| read how they're describing the situation to the shareholders
| rather than the spin for internal audiences. It's the One
| Secret Trick that will give you an idea of what the motivations
| and interests of your company's leaders are, as opposed to what
| they claim or you guess that they are, which then ends up being
| super useful for say, judging which project has a better
| likelihood of becoming important, how to sell things
| internally, etc
| infamia wrote:
| Your lack of experience and absence of preconceptions is a golden
| time. _First_ , interview your customers (internal and external),
| to see how the team/company are perceived and what is important
| to them. Explain to them that you are talking to them first to
| avoid forming any preconceptions. Spend a bit of time organizing
| and summarizing your findings before moving on to interviewing
| your team. By interviewing your team last, you will be able to
| ask better questions and avoid being locked in to your
| company/Dept's group think and culture.
| vipshek wrote:
| In the past year, I've gone from near-zero understanding to
| pretty deep expertise in the domain of electrical grid
| interconnection as a product engineer. Here's how I went about
| it.
|
| I think all the other comments saying "read a lot" and "talk to
| everyone" are correct first steps, but for me, consuming
| information has diminishing returns after a short while. After
| you've reached a point where your brain feels like it's
| exploding, you should switch your focus to _outputting_
| information.
|
| If you're a "write things down" person, then write a synthesized
| document explaining everything you've learned, and then ask a few
| trusted coworkers to tear it apart.
|
| If you're a "talk out loud" person, schedule time with coworkers
| to have a "teachback session" where you give a presentation about
| everything you've learned. Again, ask them to tear it apart.
|
| It's crucial to build trust with a few coworkers who are willing
| to critique your output. Get them to rip everything you've
| created to shreds. Whenever you write or say something that's
| even slightly off compared to how someone in the industry would
| say it, make sure you learn about that, and learn how someone in
| the industry would say it.
|
| This focus on getting the language right - especially the
| colloquial language of how people actually describe things day-
| to-day - is important for every role, but I assume it's
| especially important in marketing, where you need to be able to
| use the precise language that your customers use.
|
| tl;dr: Read/talk to people at first, but switch to
| writing/presenting ASAP. Solicit and internalize as much critical
| feedback as you possibly can.
| slotrans wrote:
| If you're curious, you'll learn.
|
| If you're not, you won't.
|
| Nothing else to it.
| ilc wrote:
| I've done this a few times.
|
| 1. Immersion. I learn more German in Germany when I visit for a
| week than I do in months of study. Why? Because I can see it all
| context. I can guess what a Hauptbahnhof is context, and other
| words. You start to see the patterns. Work is much the same. Get
| in there and learn! There is a reason why the first thing every
| software developer should do is fix a pretty easy bug. It gets
| them to do so many essential things they will need to do day to
| day as part of their job.
|
| 2. There are no dumb questions. "What is Alpha?" "What are the
| Greeks?" etc. All VERY valid questions. If in Star Trek parlance
| if someone says to "Tech, tech the tech." ask some questions. :)
| (Tech was used by the writers as a stand in to allow them to
| write the script without looking everything up.)
|
| 3. You have time. Nobody expects you to know anything. Ramp up
| for an industry to basic levels is usually about 6 months.
|
| 4. Suffer. Try to learn the concepts. This won't always work, but
| it'll teach you tons of extra concepts you will need later. Time
| spent learning is rarely totally wasted. It just may be the
| knowledge you need to cross a gap later. Also it makes it obvious
| to the people around you, you are trying, thus you are more
| likely to get help.
|
| 5. Don't be afraid to be stupid. When I used to work with TLAs a
| wise boss once told me if he didn't know what some word/acronym
| meant. He'd just ask.
|
| It was amazing how many times nobody in the room could expand it.
| Despite us all working with it ;)
|
| I've picked up this habit from him. It hasn't hurt me... But it
| can be a great way to rattle people.
| hn72774 wrote:
| > We do have a set of required reading material that I've gone
| through, along with product demos, and even 2 VC books that have
| been recommended on the subject.
|
| What were some of the reading material and books? What area of
| fintech?
|
| I went the other way, from finance into non-finance. And from
| bigco to smallco. It took a solid 6-12 months to start feeling
| competent. It was worth it. I now have a lot more breadth on the
| business side, and technical depth from having to read code to
| learn a bunch of new stacks and end to end integration flows. At
| the smallco there wasn't much for docs to read, and the ones they
| had were out of date.
| cableshaft wrote:
| I work in consulting and have been working for a client in
| finance for the past two years working on greenfield applications
| for them.
|
| I haven't gone too far out of the way to learn aspects of finance
| other than through exposure and osmosis. As long as there's
| someone on the team that really understands it on a deep level,
| you don't have to be that person to be effective, at least on the
| frontend (which has been my focus for this client, although I am
| doing a bit more backend now).
|
| Hasn't stopped me from implementing complicated features as
| requested and discussed, just asking questions for what's
| expected, what the data should look like when it's done
| correctly, etc, but now I do understand it a lot better and I can
| mostly follow along during deep discussions (some of it still
| goes over my head though).
|
| That being said, you can pick up books on finance to help you
| understand things better. For me, I discovered recently (stumbled
| upon it at a used bookstore, actually), that I should probably
| pick up textbooks on Quantitative Investment Analysis and
| Portfolio Management in order to understand those deeper
| discussions better, but the focus of your startup might be
| different.
| j45 wrote:
| I've learned to work in multiple industries and verticals and
| transferring what I know that can.
|
| Generally, there's no hack around learning, other than learning
| more efficiently. The faster you dive in, the sooner you'll have
| a sense of what you know (more than you think) and where to
| actually focus in the next 3-6-9-12 months.
|
| There is a course called learning how to learn that focuses on
| how adults learn differently that's worth checking out before
| going into fintech or other topics. Highly recommend checking it
| out as a first stop.
|
| Fintech is a broad and vague category, not specific.
|
| In this case if it's new to you, focus on first principles
| learning whether it's in finance, banking.
|
| If you can saturate your time, consciousness with meaning full
| content, there is a good amount of passive spaced repetition from
| hearing different explanations of concepts. Podcasts can be
| helpful, but for learning you will probably find some things on
| youtube to subscribe to and work through. Have a playlist ready
| to go, whether it's in your ears, or on a speaker while getting
| ready in the mornings.
|
| First principles learning means learning the basics and using
| that to build up to the other concepts. Luckily it also can mean
| learn it like you're 5 and don't expect to learn it as quickly as
| something that is partially familiar or similar. When you do
| this, your brain will point out what's familiar or similar
| anyways.
|
| What's nice is if you're not great at math, there's still a lot
| of people and process interactions that can have value added too.
| The math can be learned too.
| volkk wrote:
| ctrl-f "use the product" -- and haven't seen one mention of this.
| dogfood your product. shadow people using it if you're not the
| target demographic, understand it inside out, and you will catch
| up very quickly.
| alephnerd wrote:
| Are you Product Marketing or Content Marketing/Demand Gen?
|
| First - recognize that there is a significant difference between
| the two.
|
| Second - chat with peer PMMs, Field Marketers, Growth PMs, etc to
| get good tips and advice.
|
| Finally, I recommend reading Monetizing Innovation [0] in order
| to understand the Packaging and Pricing portion of Product
| Marketing. For Content Marketing/Demand Gen, I found Hacking
| Growth to be useful, but honestly there are a number of YC and
| adjacent podcasts that are fairly useful for that.
|
| Finally - if you feel you don't like the role or the space, make
| sure to let you CEO know ASAP and make a transition plan with
| them. In my younger days I burnt a bridge with a good friend when
| I became an inexperienced VP Marketing/Demand Gen at their
| startup.
|
| [0] - https://www.simon-kucher.com/en/insights/monetizing-
| innovati...
| toddmorey wrote:
| OP isn't new to marketing, just this particular industry.
| h0bb3z wrote:
| As a new engineer (engineer #2) at a startup decades ago, I was
| asked to teach the new incoming engineers about the company
| product.. Next week.
|
| Forcing myself into the mindset that I had to explain it to
| others in a meaningful and comprehensive way - AND to be prepared
| to answer questions - I learned and understood the product in
| record time. It wasn't perfect, but holy moly was I motivated to
| know it well enough to explain it.
| DontchaKnowit wrote:
| Honestly, define key terms and make anki flashcards. Not gonna
| give you deep understanding BUT will make the roadmap lf
| terminology and probably thw structure of the company and the
| product very concrete very quick and so the nuance will come much
| faster.
| Simon666666 wrote:
| https://x.com/erfolgreich2020/status/1765008049809314248?s=2...
| attah_ wrote:
| When i have joined a new project, i have asked for a "safari"
| from one or a few senior people. Show me "the big five" of your
| area. Pretty simple to find time and willingness for generally,
| and it's been a good amount of info to digest at once.
| epolanski wrote:
| I start taking notes and have endless questions for everyone.
|
| By the end of the first days it is clear to me that most people
| there, even some veteran product managers have a very incomplete
| ideas.
|
| By the end of the first few weeks I generally end up being the
| most knowledgeable person in the team (or at least among the top)
| because generally most people don't give two damns and are there
| for the paycheck so I'm reminded of how low the bar is in pretty
| much any environment.
|
| A nice side effect of my approach is that you end up learning a
| terrific amount about the other team mates and you force people
| into questioning their knowledge themselves.
| austin-cheney wrote:
| You should always be aligned to the revenue mission of the
| company. The mission is to earn money AND enhance the reputation
| of the company.
|
| Scenario 1:
|
| My first job out of college was developing automated pretty HTML
| for emails for this marketing company in the hospitality
| industry. It was still start-upish at that time, so the business
| was centered around account management and business relations. I
| was hired to be a developer, so I found problems to solve. When
| those solutions saved business relationships I could walk on
| water. I got good at task lists and account management even
| though account management was handled elsewhere.
|
| Scenario 2:
|
| I once did cyber defense for the US Army back before Army cyber
| was a thing. I started getting pretty good at it until I was
| promoted out of that organization into a logistics organization.
| All that cyber expertise didn't matter so much anymore, I had to
| be a manager in a group that different things. I was basically a
| people manager of a help desk plus other stuff. In order to
| protect my staff I had to learn logistics. I had to know how to
| do other people's jobs so that I could push back with better
| answers when leadership made decisions or other managers tried to
| poach my people. I have now been in logistics long enough I know
| the management of logistics operations better than many of the
| logistics managers even though I am just the IT guy. This
| provides me a lot of pull.
|
| Scenario 3:
|
| I spent a lot of time as a developer in the online travel agency
| space. I learned a lot about the retail side of e-commerce and
| the behavior of travel planning. As a junior developer I was
| promoted to a senior in about 2 years because I the A/B test guy
| for this major .com brand. I learned to master DOM traversal
| without abstraction layers so I could write tests really fast
| that did amazing things and were often more durable than the
| actual real code later released to production. Because I had also
| learned the business of e-commerce and the travel industry I
| could also design better tests and than many of the business
| owners recommended. So long as velocity, durability, and quality
| of test remained high I could walk on water.
___________________________________________________________________
(page generated 2024-03-21 23:01 UTC)