Bits and bobs of thriving in uncharted domains as a PM

With the rise of AI, we PMs might face many scenarios where we will manage products where we just do not know their full context or domain. Just yesterday, Petra Wille and Leah Tharin discussed a topic in a conversation that we would often be facing at the following times:

Do you need to understand your domain before you can work on your product?

So I decided to share some experiences and learnings of dealing with domains or situations you know nothing about.

PMs do not necessarily need to know the domain before working on their product. Jumping into any new domain can be frightening and way out of our comfort zone. However, you need to have fundamental skills and some additional factors that I cite along the article.

Here is how I went through unknown and life-defining situations and what I learned to help anyone face uncertain times.

A New World

Ten years ago, after finishing Computer Science and one month before I finished Informational Design in Cuba, I packed two small bags and flew to Berlin. This was my first time ever in an aeroplane. When I left, I had no idea what a credit card, a metro, a supermarket, or anything else was and is now part of the day-to-day in Germany or any other country. I also had a way different understanding of what problems are. And most importantly, how to solve them.

I grew up knowing using the minimum necessary to live and solving problems with what you got. For instance, many other colleagues and I finished university without a computer. How? We just had deal with it. There is always a way. Something that you learn when you are in harsh conditions is to have clear and aspiring goals. In our case, either you do it, or your future might look like it could be better.

We learned early in our lives that “If there is no solution to the problem, then don’t waste time worrying about it. If there is a solution, don’t waste time worrying about it.”

Once I arrived in Germany, there was a massive cultural shock: different language, ways of living, learning, working, etc. Everything was new. And I had to get it. I had only one clear thing: there was no comeback for me. And that became my unique goal.

How to get there?

I had to learn to feel uncomfortable with uncertainty in an unknown environment.
You need to understand what success looks like in your context or domain. If you do not, you must observe, learn and reflect on similar cases. If there are different cases, create your idea of success. Set a goal and push hard to get it.
You do need a vision. Without it, it is very easy to get lost.
It would help if you were radically focused. Things that do not contribute to your vision do not matter. Put them aside. If they are so important, they will get back.
Sense of urgency. You do not necessarily need this, but this will help you order your priorities.

I did struggle in between as I had to deal with alternative strategies. Upon my arrival, I decided to graduate and become a designer in Germany, but in the meantime, I had the chance to become a full-time product manager. So, I was pursuing two different strategies towards my goal at the same time. After finishing my studies, I chose to be only a Product Manager (another unknown domain to me then, but this is a topic for another article).

To make it short, I graduated from my 3rd university, learned German up to C1 in a bit over seven months and about two years ago, I became a German citizen. I also failed to understand a shorter path to get there. I did not research enough.

In the following two examples, I will get a bit deeper into how to deal with real examples of unknown domains or situations in software development.

The Unicorn Project

Around my 4th year as a product manager, I was working for a travel company. Then COVID started, and we saw ourselves in a business-life-threatening situation from one day to the next. Revenue dropped 95% from one week to the next, and the future looked darker by the minute. We took it hard. But it also brought new challenges to keep the business running, at least to its core.

All products accumulate debt, technical, business, and data debts. I call all of them product debts. In normal times, this is something that you can manage to pay using different tactics. Eventually, you can make it. But this can be even more dangerous when your company’s and your job’s existence is on the line.

During such an unprecedented time, companies almost inevitably shrink (due to uncertainty and insecurity of the companies’ future). So, people are no longer in the company. With them, their knowledge and experience are gone in a matter of months, if not weeks, bringing an additional problem: How to keep developing our product or even maintain it? Does it even matter to keep developing the product?

On that, consider all the fears you had during COVID. I had them too.

As I said, the situation was worsening day after day. So, many companies went either to Kurzarbeit or inevitably started reducing costs. Or both. What could our future look like in 1 year? We had to do something, and I had no idea what. We were bracing for impact.

Fortunately, I stumbled upon one idea; one of our team’s most talented software engineers was writing for a couple of days. He focused on three things:

Find problematic services
Find out what costs money x2
Find everything that is not automated yet but CAN be automated

This work was brilliant. This engineer was focusing on what customers were willing to pay for radically. You can find more about this in The Unicorn Project.

“A hundred years ago, most large factories had a CPO-chief power officer- who ran the electricity generation processes. It was one of the most important roles in manufacturing, because no electricity, no production. It was a Core process”, he says. “But that rule has disappeared entirely. Electricity has become infrastructure that you buy from a utility company. It is interchangeable, and you choose suppliers primarily on price. There is rarely a competitive advantage to generating your own power. It is now merely context, no longer Core. You don’t want to be the organisation that has a large staff providing internal power generation.”

He was identifying what Core was and what was Context to us. Context means parts of your product that you can unload, freeing yourself from years of technical debt. “Even though it may be more painful in the short term, you will find some unexpected and critical dividends long term”. The core functions were straightforward, our customers. None of them knows or cares about how your product is built, just the value it provides and the problem it solves for them.

Inspired by how fitting his research was to how I believe software products should be built, we prepared a business case and presented it to the C-level suite. We were about to pitch rebuilding the whole product from its ground to the last button.

It was scary. We were full of hopes, and cost calculations, stepping into a radical change that might go wrong. But, there was a sense of urgency in doing this.

So, we did pitch the business case. It faced some expected resistance and uncertainty. My primary role was to make the C-level believe that the company’s future was in jeopardy (this was not hard, though, we did not know how long COVID would be ravaging humanity and when people could travel again).

Backed up by our company’s executives, we went all in and made it. We called it The Unicorn Project. And it was a success in general. We eliminated all the waste we produced for years and built a modular, lighter, maintainable and sustainable product with fewer costs that could help the company get through the pandemic.

Radical Focus by Christina Wodtke played an essential role in facilitating this. Even though we did not know it could help us, we tried it.

We also got rid of all unnecessary artefacts historically attached to product development:

We removed estimations of any type. We focused on creating certainty and alignment. Estimations are senseless if you have a full-aligned team that knows what problem we are solving and how we are solving it.
We removed any grooming. Instead, we focused on creating and providing the context of the problem we wanted to solve.
We removed the words scrum, kanban and backlog from our vocabulary. Instead, we focused on being the focus of our goals and what we could do now to solve the most important problems we had.

Along this journey, we made several mistakes too. We underestimated data migrations and how long they could take. I could have communicated better with some partners and aligned them with the Unicorn’s objectives. I feared this was not a welcome project as it was too wild and radical. I should have trusted and enjoyed more the decision and empowerment of the CEO in pushing towards it.

What learnings we had from this?

Do not be afraid of unknowns. Run discovery on them until you get more certainty and feel comfortable. Test your assumptions.
Be bold. Sometimes, you need to play with the guts. To make your team believe, you need to believe first.
Most importantly, trust your team and the people with more knowledge in your team. You, as PM, can only aim to have some answers. That will harm you and your career more than help you.

This last point is better explained in the next example.

Becoming a Platform Product Manager

About two years ago, I became a Platform Product Manager of the Risk Segment in my company, a B2B Fintech. I had just started in the company three months before that, and it was my first job ever in Fintech. When I joined the team, the complexity of all the domains was overwhelming, to say the least: Identification, Fraud prevention, Risk, AML, and some others….

Was I afraid to my core? You bet. But that couldn’t just stop me.

Ok, this time, the situation seemed very difficult. What can I do to pull it off?

I just talked to the team first. I wanted to know the team’s culture, each individual personally, who they are, how they work, their core values, and how psychologically safe they feel, among other fundamental questions. I wanted to listen to their problems as individuals and as a team.

Do you see what I did there? I did not ask them to explain the domains or to have a detailed view of how the services worked. I know they knew them well, or at least better than me.

Second, I tried to understand the synergies of the team with other teams and what strategic impact they had versus what they would have according to the company strategy.

What is the vision of the team? Their principles, how mission-critical it is?

So, I ran several listening tours with stakeholders and started to get a deeper knowledge of the different domains, prioritising what I knew less about; for the rest, I just trusted the team first as they had accumulated more experience and knowledge than myself.

We did identify together several main issues:

We lacked a solid product vision in the segment
The team was mainly delivering and not much involved in product discovery.
No clear definition of what customers we were solving problems for

Also, data scientists and engineers needed to be closer, trying to solve the same problems.

How did we get around this?

I started changing my language following “Leadership is Language“, a terrific book that helps you empower people instead of managing by coercion. Applying these techniques brought wonders, causing engineers to own problems and driving discovery independently. I also used the fundamentals of Team Topologies, which made us understand our mission as Platform-as-a-Product.

We brought data scientists and engineers closer and closer. We also eliminated senseless estimations, old-timed ceremonies, and unnecessary processes that could have been a better use of time.

Doing this brought Machine Learning to our services and brought me to unknown domains and situations. I haven’t built a model by myself. So I applied again the techniques described in this article.

We push. All together.

What were the learnings this time?

Focus on people, on your connection to them.
Embrace uncertainty and bring the problems to the team, create clarity, provide business context, and make them shine.
Learn the necessary to make informed decisions. Then learn a bit more. Identify who is the most knowledgeable person in the team and the company. Do hunt for information and new practices. Learn day after day.
Enable everyone, from the smartest to the least skilful people in the team, to solve problems. Leverage what they know. There is greatness in everyone. Show them how to frame problems and assess risks in product discovery.
Most importantly, do not be afraid of failure.

So, I take these three situations as examples of jumping into very unknown and frightening situations and dealing with them. So, you do not need to know the domain of the product you will be working on beforehand. However, you need to:

Have a method for how to solve problems.
Feel uncomfortable with uncertainty.
Learn enough and regularly. Then learn a bit more.
Identify what the most critical amount of information the team would need from you is
- What information would you need to make your first informed decisions?
- Where is this information?
- Who can provide this information?
Use enabling techniques where all the specialists on the team become leaders by themselves (Leadership is language, for instance). Make them the product.
Decrease the amount of process to the bare minimum and remove all obstacles.
Most importantly, believe in people, focus on the people, and work for them. Enable them to be the best versions of themselves.
It is super helpful if you have someone who can give you feedback regularly; thriving in unknown domains can be scary, and you can feel alone. If your manager supports and enables you, you have half the battle won.

That’s it. These are my thoughts and what worked well for me.

What else can help PMs thrive in uncertain times or unknown domains?