Creating a product process in a North American corporate culture

Do you like to read in Portuguese? Click here

Every time we choose change, we choose to step out of our comfort zone. Isn’t that right?

Well, that’s exactly how I, a Brazilian, ended up in a North American corporate culture company. I chose change.

I wasn’t happy at my previous company anymore. I wanted recognition from my leadership, to work with a different language, and face new challenges. So, I decided to embrace change and explore new opportunities in the job market.

I began flirting with recruiters and reaching out to my network to share my goals. That’s how I got to know my current company, a Brazilian startup founded in 2013, which was acquired by a large group of North American companies in 2020, initiating the M&A process. As I got to know them, I started to understand more about the product, the team, and the opportunity, and that’s when I fell in love and decided to join. (Yes! I was interviewing the company before the actual interview process, haha. And I recommend more people do this — feel free to connect with me on LinkedIn to exchange experiences.)

When I joined, there were quite a few challenges, you know?! Besides changing companies, I faced three other challenges on a personal and professional level:

Shifting to a different market.
Taking on a leadership role with direct reports (no longer just influencing but responsible for career development).
Working more with English in my daily tasks.
And if that wasn’t enough, there were two more additional challenges within the company’s context:

Stakeholders complaining about a lack of visibility into what the teams were doing.
(This was because the team was afraid to show what was in progress, fearing it might seem like “not enough” work.)
Teams complaining about a lack of autonomy.
(This was because stakeholders wanted to micromanage to understand what was happening within the teams, desiring involvement in decisions.)
That’s when I started to analyze the situation and the context, figuring out where I, as a Group Product Manager, could make an impact in my tribe.

I began having 1:1 conversations with everyone to introduce myself and gather more historical information. I realized there was also a clash of cultures between the American and Brazilian work styles. As I delved deeper into this context, it became clear to me that all these conversations converged at one common point.

Looking at it from a systemic perspective, everything my stakeholders, business owners, team members, engineering, and design teams told me converged on the fact that:

Not having a clear and universally known product process.

And that’s when I understood where I could intervene! The product process doesn’t need to be rigid. I want to emphasize that here and now with you. However, it needs to be clear and have its stages minimally structured and respected in teams with low maturity.

After this analysis and understanding of this point and the company’s current situation, I began to identify which stages had the most issues: the discovery (Upstream) or the delivery (Downstream). As expected, both had many problems.

However, I noticed that when it came to delivery (Downstream), numerous problems still stemming from the discovery (Upstream) phase. Therefore, I chose to start with the discovery (Upstream) because it was where we, as product teams, would have more autonomy and fewer dependencies. With this, I brought various process references to the team, such as Design Thinking, Triple Track Agile, Continuous Discovery, and so on.

Drawing from these sources, we began to design our process, little by little, with the product, business, design, and engineering teams. In approximately one month, I was able to finalize the first version, which looked something like this:

And in this process, I started to include some fundamental ceremonies, which were weekly or bi-weekly meetings with stakeholders. From then on, we began to shorten the periods without contact between everyone, and this was good because it increased the visibility of demands in the discovery phase.

We also started to have Agile review meetings every two weeks for the teams to showcase what software was being delivered and was in operation, which also helped with visibility.

It may sound simple, but it’s not. I lived through it, and I can say there were days when I questioned if it would work. There were days when I worked extensively on the process and then erased everything, thinking I couldn’t make it or solve the problem.

Looking back now, I have some additional tips for you in this process: Gain buy-in from your stakeholders and team members, and build good relationships from the start, as they will help you with communication and negotiation, both with your team and stakeholders. Be clear about the trade-offs of each decision, be honest, document, and communicate every step. This process I went through was much more about soft than hard skills. I had all the technical knowledge I needed, but imposter syndrome was right there, so emotional self-management was crucial.

So, overcome yourself! This is the last tip, but it is extremely valuable. Step out of your comfort zone, and believe in your potential. My first meeting with all my stakeholders in the room, 100% led by me, was in English, discussing a product process.

If someone had told me that one day I would do this in life, with just over a month in the company, in an American company, or any company on the face of the earth, I wouldn’t have believed it. So, take the plunge! I’ll be looking forward to hearing your stories and exchanging experiences.

Until next time!