I'm currently joining a small product company based in Barcelona. The company released the first MVP some months ago, therefore there's already a product and users in place. Plus I already knew them before joining, that's super! 🎉

Even though they have already an on-boarding phase, I try to follow the next phases to become as familiar and productive as soon as possible with the product and team dynamics. In summary, it's all about making learning phase as short and valuable as possible.

Before joining the company:

1. Become familiar with the product

I become a user right away. I use the product each day to be familiar with the experience, benefits and drawbacks of the product.

By doing that, I identify:

• 🚶 User Journeys/User Flows

Being familiar with the application and the information in each page helps me to create a mental map about the pages, the interactions and the data.

• 😄 Value Proposition

Which are the benefits for the users, why the users pay for that solution.

• 📊 Business Models

How the company win money, and where they might be investing resources to make the product better.

• 🔄 Possible feedback loops

I search for ways that the users can give feedback to the product team, and how they are doing to listen in order to improve the product. It can be in the product itself or in the social networks.

It helps me be aware how much they care about the users feedback and how they involve them in the product development cycle

2. Become familiar with the market

• 🔤 Be familiar with the market language/jargon

As developer, I want to use a language that it's as near to the product people as possible. Sharing the same understanding on wording is crucial!

• 🔎 Be familiar with the important actors of the market

Competitors, regulation, ... whatever that has an impact in the market and the company's product is valuable to be familiar with.

Either because some product features addresses some already visible problems or because some features/user flows are inspired on some of those products.

---

After joining the company:

3. Assert that what I learned in the steps 1 and 2

Having the first conversations with the team about what did you learn, and expanding the product knowledge with those conversations.

It's important to not limit those conversations with the development team, I strongly suggest to have that conversation with all team members, like marketing, product, finance, ...

It will help you to have a better picture about the product, but also it will help your teammates to know how the product is perceived from outside. Both parties learn from this exercise.

🔡 Give importance to the Glossary. On the second step, you became familiar with the business language. It's time to assert that learning by creating a Glossary.

In case you're not familiar with the "Glossary", it's a list of wording and meaning for each thing that your team-mates refer to.

When you start speaking with your team-mates, they start saying stuff like, just check the XYZ, and you are like... what does XYZ mean?. In this step, you are recording all those new concepts because you will use them in your day to day job.

The Glossary will help the next person that joins the company to not get lost in all this new jargon.

But also helps you to know if the product people speaks the same language as the developers do. And that's super important. If you start finding that the product people say XYZ and then developers say, oh, that means ABC in the code... you will hard a time translating between tech and business, and that's something you could start investing energy and time to correct overtime.

What you aim to do is to create a shared and ubiquitous language between business and developers. It's a common concept in Domain-Driven Design.

4. Become familiar with the systems in place

Once I understand the product, the users and the value proposition, I try to understand the different systems that the company manages. To do so, I do somehow the next questions:

• How many independent systems do you manage?

Having a big picture of all the systems, and how they are connected between them helps me as a starting point to organize all the concepts in my head. I do need to know and understand where everything belongs and which is each system purpose.

• Are those systems self-managed or a third party manages them?

Knowing which systems are self-managed gives me an overview of the approach of the company/teams to develop software. Like, if they prefer to setup a self-managed Redis cluster over using the Cloud provider solution. I also ask the reason of why something is self-managed when there are good third party managed solutions when I consider that some tool might not be a core-business system.

• Which are the deployment steps for each self-managed systems?

An important thing to know is how those systems are deployed. Is it manual? Continuous Deployment? you need other systems to be deployed when you deploy X system?

• Which teams are in charge of those systems?

After knowing the systems, I ask for which teams are in charge. Here I tend to identify how the teams are structured. By domain-bounderies or by layers (frontend, backend, ...).

Also, identify which dependency there are between teams. It's important to know if there are a lot of dependency between teams to release something or they are quite independent.

5. Which tools do they use in their day to day?

Any tool that are uses during the day to day to deliver work. Not only related to development, but anything around that.

• [ ] Development tools? Ex: VSCode, IntelliJ, GitHub, AWS, ...
• [ ] Monitoring tools? Ex: Kibana, Grafana, ...
• [ ] Design tools? Ex: Figma, Sketch, Adobe Suit, ...
• [ ] Analytics tools? Ex: Google Analytics, Matomo, ...
• [ ] Management tools? Ex: Jira, Trello, ...
• [ ] Communication tools? Ex: Meet, Slack, ...
• [ ] Other tools? Ex: hotjar, Google Drive, ...

Knowing the tools in place, plus if they are being paid or the free version, gives you a vision about how those tools affect your way of working. Also, if there are paid tools, trying to propose an alternative might be harder to convince people about the benefits vs replace a free tool.

I try to understand what all roles uses like the designers and marketing team, so I can have a better understanding on their work and how much I need to understand their tools to have a good communication between us.

Disclaimer: I don't say that the tools are the only thing you need to understand to have a good communication. Indeed, I consider that you need to do an extra effort to understand all the disciplines and areas of the company. Don't think that this a low effort task. By far, communication is still, at least for me, the where most of my energy goes.

6. Team dynamics/methodologies

Common stuff here:

• Are you using some Agile methodology? If so, which one and which and how?
• How do you provide feedback? Do they have 1:1? Retrospectives?
• How do you plan a backlog?
• How is a week in this team?

---

Conclusions

Doing this steps you have the "base knowledge" about:

• The product value proposition and jargon. Spending less time during Development time trying to understand what people means about XYZ.
• Which systems do what, and which teams manages them.
• Which tools you should use in your day to day basis, and also tools from your colleges that you need to collaborate with.

I think those steps happen naturally in any company, some in a structured way others in a unstructured. This guide is only a way to give a way to gather the knowledge faster.

Open for Feedback

This is a live article. I'm more than open to other experience from people in a similar situations and practices 😄

Attributions

Photo by Element5 Digital on Unsplash