Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How to onboard yourself to a new product/industry in a new job?
216 points by sujdes 8 months ago | hide | past | favorite | 77 comments
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?




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.


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.


> 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.


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.


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.


> 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.


It can work really well but you can sometimes find individuals who won't play along.


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.


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.


I feel like this is easier to do as a junior developer than a mid to senior level developer.

Also, I have tried this on a team and one or two would do it but everyone acted like they are too busy. Basically, it was hard to get one on one time to talk to people on the team outside the manager.

Depending on how toxic the job is too, this could be used against you. I don't think it should, but if they expect a mid/senior developer then they could see this as not being senior enough.

How do you handle the above concerns? Both to make people make time for this and also how do you defend against it being used against you? Yes, there is a grace period. But then it feels like even with a grace period, some still find a reason to use it against you.


I almost always hate it when people give the following advice because it’s almost always given too freely, but:

Do you really want to work for a team that looks down upon you for trying to learn/appearing like you don’t know something?

That’s like a Petri dish for growing imposter syndrome.


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.


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.


> 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.


subscribing to everything, rco8786 let me know if you are hiring anytime soon :rotfl:


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.


> 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!


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.


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.


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!


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


Second Anki!

Joining an industry/domain/organization also means learning the language there. The acronyms are vocabulary.


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.


> 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


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.


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


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.


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...


Your point 1 has been my experience and I DO NOT understand why the most upvoted post in this post is saying to have one on ones with every team member on the team and also to have one of ones with related teams. I can't think of a time when that has ever been able to happen, especially on outer teams. Yes, it is ideal. But most teams and people feel like they are too busy all the time and also I have found that if you ask too many questions, sometimes that can be used against you if you don't know the team dynamics at play.

Your point 3 validates that as well.


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?


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.


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.


> I left that job immediately after the interviews.

Why?


If you read between the lines, it would seem no one was keeping the place clean.


Well, when you want the cleaning crew to spy for you, you better get chummy with them. My parents were janitors, so I got a start point at least. We're all just cleaning crews in the end.


It is sewerage all the way down.


You would know


Why? none ya biznuts man. Read between the lines, I talked to people and it was a dumpster fire. Interviews are lies. Always treat hiring as YOUR opportunity, interview THEM.


Sounds like you had FU money or can easily get into another job quickly.


The assumptions. No FU money here- My luck is zilch buddy... many attempts and nothing but blood sweat and tears. My thing. I was homeless once... I dont give a fuck.


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


> 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.


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.


OP is in marketing, not eng, FWIW.


Oop, nevermind then


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.


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.


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.


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!


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!


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.


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.


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.


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...


OP isn’t new to marketing, just this particular industry.


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.


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.


> 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.


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.


9 years and you consider yourself a „senior” and you still think about how you „feel” left behind? What do you expect? Processes take time - all of them.

I ventured into a new domain 3 years ago and got comfortable within one year. Then found out I know nothing around year two. Then again. Back and forth. True seniors, experts, whatever you call them - they don’t get comfortable.


Just realizing the above comes off super grumpy.

To clarify, sometimes I get the sense that the sort of people, also like myself, who come on here, have this delusion that this tech stuff will cheat reality. That you do this and that, you play your cards well and you will skip ahead of everyone else in all the other professions in society. A sort of technocratic megalomania.

I absolutely do not know that the OP is like this. My experience „switching” domains is that it can help to find the common familiar denominators with what you know in the new thing. And then, like an anthropologist, to develop a respectful understanding of the people who are experts in this domain. You keep it respectful by recognizing that you’re not going to catch up with them. It’ll be their job to convey to you what their problems are, and yours to listen carefully. You might be good with that hammer you’re holding from your earlier experiences, but they might not even have nails for you to bang on. That’s where the discomfort comes in.


Ignore that this blog post says as a CTO / VP, some great role agnostic advice https://lethain.com/first-ninety-days-cto-vpe


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.


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.


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.


If you're curious, you'll learn.

If you're not, you won't.

Nothing else to it.


You should join the product marketing alliance which has frameworks & an active slack community that can help you out.


I'm assuming you're a member; what is the value you enjoy most from PMA? I've been on the fence.


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.


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?"


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.


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.


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.


LLM Agent support


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.


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.


You'd learn, wouldn't you? Other marketers were not born with the knowledge either.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: