Joining an Existing Product: Learn Before You Change

I joined BrandChamp in June 2025.

After spending so much time building my own product, stepping into an existing one brought a different kind of challenge. There was already a team, an established customer base, and a lot of decisions made before I arrived.

There were also plenty of things to learn before I could make useful decisions of my own.

When you join a product team, you naturally notice things you would do differently. A screen feels crowded. A workflow takes too many steps. A setting seems to be in the wrong place.

Those observations are useful. But they are also incomplete.

You are seeing the result of past decisions without necessarily knowing the circumstances behind them.

The product has a history

An interface can look strange because the design needs work. It can also look strange because it supports a customer workflow you have not encountered yet.

Perhaps a setting was added for a group of customers with a specific requirement. Perhaps the team wanted to improve a flow but had to prioritise something more urgent. Perhaps an apparently redundant step prevents a mistake that used to happen regularly.

None of that means the existing approach should stay forever.

It means that understanding the reason gives you a better chance of improving it without accidentally removing something valuable.

I find “What led us here?” a more useful starting point than “Why is this like this?”

The first question makes room for context. The second can sound like you have already decided someone made a bad choice.

Different teams see different parts of the problem

In a product like BrandChamp, there are several perspectives to understand.

Admins are running ambassador programs. Ambassadors are participating in those programs. Sales hears what prospective customers expect. Customer success sees where people need help. Engineering understands the constraints and dependencies behind what appears on the screen.

Each perspective reveals something the others might miss.

A request that sounds small in a sales conversation may involve a large change to how the product works. An issue that seems minor in a screenshot may create repetitive work for an admin every week.

My job is to bring those views together well enough to make a decision.

That requires more listening than a quick product review can provide.

Early observations should stay flexible

One thing I am trying to be careful about is turning an early impression into a fixed opinion.

There is a difference between noticing that something feels complicated and knowing which part of the complexity is unnecessary.

I want to be able to say, “This is my current understanding,” and then change it when I learn more.

That matters when joining a team with years of experience in the product. People should be able to give you context without feeling that they have to defend everything that came before you.

It also makes the work better. An idea that changes after a conversation is often more useful than the one you brought into it.

You still need to make progress

Learning does not mean waiting until you understand every corner of the product. That could take forever.

There are usually improvements you can make with reasonable confidence: clearer wording, an obvious usability issue, or a repeated problem that the team already understands.

Working on those can help you learn how the team makes decisions and delivers changes.

For larger decisions, I want more evidence. Who experiences the problem? How often? What do they do today? What might a change affect?

I am still early in my time at BrandChamp. My understanding will keep developing.

For now, I want to be useful in a way that respects what the team already knows and gives us a clearer view of what should come next.