Wrapping up what to prepare for when you’re new to a job, and the mistakes I made so I don’t forget them.

1. Get your tools set up

Find out what software the company runs on day to day. If IT already has it installed for you, great. If it’s something you’ve never used, learn the basics when you have a spare moment, or just ask a colleague.

2. Learn how the place actually works

Get a feel for the org chart, the general workflow — does product development run through an internal system, through docs, or through some third-party tool — and how the different departments coordinate with each other.

Get a rough sense of the engineering org too: their general skill level, their main tech stack, if you can find that out.

3. Meet your coworkers

No need to rush getting close to everyone — you’re not going to remember all the names on day one anyway, and honestly the more important thing here is for them to remember you. But do remember the people you’ll be working closely with, and make a good first impression with them.

Get a read on the team’s vibe and pace, and your manager’s working style.

If you get the chance, take a colleague or your manager out for a meal — it’s a good way to learn more about the company and what’s expected of you.

4. Get up to speed on the business*

A few things worth memorizing outright: the company’s main business lines, its values, the internal jargon, the key metrics, the main competitors, and the market and policy landscape. Most companies have a deck or doc covering this; ask around for anything it doesn’t cover.

Products worth actually using: for anything owned by your own team, walk through the main flows yourself and use it hands-on — a mind map really helps organize your thinking here. Do the same with the main competitors so you understand what’s similar and what’s different.

For the product you’re personally taking over, use every feature, hit every state, and draw out the flow diagrams as you go. Whatever’s unclear, go ask the person who was handling it before. If you’re confused about something or a feature seems overly complex, pull up the old requirement docs if the company kept them — that’s also a good way to learn the company’s conventions for writing requirement docs.

For the business your product touches, try to experience it firsthand if you can — or at minimum, understand the basics: current pain points, where it’s headed, what its core strengths or value are, and its business model.

Build a feel for the data — pull the relevant event-tracking and reporting data and actually look at it, so you have real numbers in your head, not just impressions.

5. Ground rules for writing requirement docs

Everyone’s busy, so don’t reinvent the wheel — if there’s already a mature product doing this, or a writeup online, go read it. It’ll also help you handle pushback later.

Explain the background of the requirement — it makes it easier for engineering to understand, and it shows you’re not just making up requests on a whim.

Spell out the entry point for the feature — engineering might be new to this part of the product too and won’t necessarily know where it lives.

Spell out every state and every transition — engineers often won’t catch these on their own, even when the logic seems obvious to you. Write it out anyway.

For anything involving numbers or options, be explicit: min/max values, defaults, format requirements, and how those formats should actually be implemented. This is the baseline, not optional.

Spell out how to handle edge cases — for anything you can reasonably foresee going wrong, write down how to prevent it or handle it. Every single step needs this kind of thinking.

And — this one matters a lot — always include diagrams.

6. How to carry yourself

Stay humble, keep a low profile, and be polite to both your colleagues and engineering. When something’s frustrating day to day, put yourself in the other person’s shoes — be mindful of tone and timing when you ask someone for something. Everyone’s stretched thin.

Always confirm requirements explicitly with engineering and QA — make sure they actually know what’s expected. Don’t just write the doc and consider your job done.

Once development is finished, test it yourself. Once it’s live, go check the actual result yourself too.