R084 – The B-side of Product Management, with Jesica Wulf

What do you want us to know about you?

My name is Jessica Wulf. I'm Argentine and I've been in Spain for six years. I came for product work. I'm an industrial engineer and have been working in product for over 10 or 12 years. I've worked in B2B and B2C companies and products. Besides having many failures and many victories, I've built a career in event organization and community creation: I organized TEDx events, recently created a community for women in product, I'm in Producta in Barcelona, and as if that weren't enough, I also produce theater plays.

What professional mistake taught you more than any success?

More than a specific mistake, there was a moment that marked me deeply and built the “armor” for how I face failure. It was in a job several years ago, in a company with a global reach, where I had to manage a product with considerable exposure. I was paralyzed: I was terrified of making decisions because I felt it was very easy to mess up.

A friend who was then my mentor and manager told me something key: everyone makes mistakes. You have to trust yourself and your ability to react to failure. You're going to try to do your best, but you also have to be good at reacting when things go wrong. That conversation changed me: I started facing those situations with more confidence and building a framework and structure to find and face errors before they explode. It marked my career significantly.

Everyone makes mistakes. You have to trust yourself and your ability to react to that failure.

Have you felt that fear other times?

Yes, but each time it decreased more. I built that counterface: knowing what you might encounter on the other side and how to prepare. But fears and mistakes, all the time.

Does culture influence that fear of making mistakes?

Totally. Many things influence: the country you come from, the company culture, and the surrounding environment. A culture around error is built that changes depending on the profile of the people in that company. I think in recent years this has advanced a lot: it wasn't the same to make a mistake 10 or 15 years ago as it is today in technology.

There's also the concept of psychological safety, but it has to be on each person's side: daring to make mistakes and being able to say “I made a mistake”. I think that's improving, although there's also something very personal about each person.

The role of a product manager is not to have all the solutions, it's to know where to find them.

What has changed over the years regarding mistakes?

Culturally, more space is given to it, and it was understood that a good way to move forward is also by messing up, but minimizing risk. It's not the same to make a million-dollar mistake as a tiny one.

I experienced something that marked me: at a job, we weren't asked for business objectives, we were asked for learnings. It wasn't outcome or output, it was learning. The goal was: “How many learnings did you have today?”. And we laughed, but it was real. You could say: “I made a content change in production and saw it didn't work”. Done, learning. Even the manager said: “You can bring me five learnings in a day, no need to change the world”.
That structure sets the path and organizes the culture.

I don't want to do my job well, I want to make good products.

How do you ensure the team doesn't see not validating a hypothesis as a failure?

There are people who, when a hypothesis isn't validated, think “I'll look for something else to validate it”, and others who think “I'm a disaster”. Going back to product, for me the key is how you minimize risks and how you make learning cost as little as possible. There you find more certainty and less frustration when you don't validate the first time.

You will surely have the error; the point is when you realize it exists.

What do you think about the MVP?

The concept of MVP is very misused. Everything is an MVP if you want, but the point is to understand what is the minimum you want to validate. I know six-month MVPs, and for that company it might be “minimum”, but there are companies that can't afford it.

Also, each company has its own “minimum”. It happened to me recently: I wanted to release a new interface in a very basic version to validate that the screen was visible. For me, it was minimal because it validated what I wanted, but I work in a company with a lot of exposure and it can't afford something so basic. There I understood that the MVP mindset changes depending on where you are.

What do you do when you have to decide under pressure?

Back to basics. Something we learn late in product is understanding the objective. If you have many things ahead, you need to understand where you're aiming and why one thing is more important than another.

I see a lot of people (even senior) with the feeling that the product manager has to know everything and have an answer for everything. I also experienced it: I would go to sleep on a Sunday stressed because on Monday I didn't have a backlog for the planning. Until someone told me: the role of product is not to have all the solutions, it's to know where to find them.

That learning connects with the fear of failure: “I don't have a backlog, I'm a disaster”. No: you have to know where to look for problems and solutions. Do benchmarking, talk to customer service, talk to developers. I always say: “I'm not technical; if you don't bring me technical problems to prioritize, I can't create a technical backlog”.

How do you generate impact in your work?

I generate impact when I find problems that need to be solved. Sometimes I annoy because I'm the person who, if you tell me “I need the red button”, I ask “why?”. It's not a lack of trust: it's to avoid falling in love with an idea without reviewing the objective. It's in those moments where I break the structure and reframe: why? what objective are we seeking?

How do you decide when everything seems important?

Sometimes having so many things generates “empty backlog” in the sense that planned work gets stuck. In large companies, with upstream and downstream (dual track), you can end up with little ready for execution not because there's nothing, but because there are so many priorities and dependencies that the upstream gets blocked.

How do you understand dual track so it's not disguised waterfall?

I totally agree that if you separate it by teams, it's a hidden waterfall. It's key to have technical people in the upstream. It happened to me once: a room full of people hypothesizing for an hour and a half, a technical guy (not even senior) passes by and says “this is a backend configuration, it's fixed”. And it was like: I can't believe it. Having a technical person in that conversation changes everything.

But it also touches a human fiber: roles, limits, and ego. I like getting into the technical side because of the logic, and not all teams tolerate me asking why a configuration is like that. And vice versa: when UX defines product, it used to bother me, and now I understand that you have to rise above the ego. I always say: “I don't want to do my job well, I want to make good products”. If the product is better by leaving room for the developer or UX, then I'm better, not worse.

What rituals or processes help you detect risks and blind spots before launching?

First, an idea of humility: Instagram tried to resemble TikTok, changed the feed, there was a huge reaction, and they had to roll back. If Instagram makes that mistake, why can't I? That already lowers the unrealistic demand.

Practically, I really like the dependency map: modules, architecture, teams. Visualizing dependencies shows you what you didn't see. In a project to reduce calls, we redesigned a process, everything perfect… but we forgot about the team sending confirmation emails. They weren't sent, and two days later the calls exploded: “I didn't receive the email”. That mapping of systems and teams helps prevent errors.

Then, when the error might already be occurring, we define thresholds in sanity metrics in experiments: you have a main metric, but also sanity metrics (for example: I increase conversion but don't want to destroy revenue or attachment). In sensitive projects, we define thresholds: “up to 1% down I tolerate, less not”. That aligns everyone to look at the same thing and stop quickly.

And another key tool: the Stop the Test Metric. If a metric drops, for example, more than 5%, no one asks: the test is stopped. In large companies, this avoids endless meetings while you keep breaking things. The point is not not to make mistakes: it's to quickly realize that the error exists. It's not the same to drop 5% for two hours as for three weeks.

When is it enough? When do you stop iterating?

It depends, like every product manager's answer, and for me, it's cost-benefit. How much benefit can that hypothesis give you and how certain are you that it will give you that benefit. I've had products where I was testing for a year and a half because the initial cost was very high and there seemed to be a “pot of gold”. But there comes a time when the cost and benefit no longer add up, and you have to invest that capacity in something else.

I don't believe in a fixed rule of “it's killed after two months”. There are metrics that say things (for example in video games), but there are also stories of games that started late. What is certain: you have to sit down with the team, manager, or direction and say: how much do we want to invest? until when? what signs do I need to keep investing money?

What was a risk or mistake that haunted you?

In another company, there was a functionality that everyone wanted to do, and I didn't see the value. It was months of development, and no one could explain the impact to me. I stood firm with the book in hand: “here you have to show me impact”. I fought hard against many people to stop the initiative… and then it was done and it worked.

It took me months to realize it was a big mistake of mine. I learned that sometimes you have to put the book away and understand the context. You can say “I don't think this will work”, but if everyone is aligned, sometimes you have to move forward. It was a tough lesson on when to choose battles and when to let go.

And I connect it with a myth: “you shouldn't make a roadmap”. We say that until you put yourself in the CEO's shoes and understand that they need visibility. Books are tools, but product is learned by doing, adapting, and accepting that you will make mistakes.

How do you balance intuition and data when there's no time or no data?

Not all companies can afford a strong database, and sometimes even if you have data, you don't have time to look for it. So decisions are made with less data. But I wouldn't go just with “I felt it”. For me, intuition is valid, but you have to know how to play it: you need some support, even if minimal. Today there's information everywhere: a quick research, a signal, a number. We sin by wanting “the best data”, but you need something to support you; otherwise, you're in the air.

I often use: “it smells like it's this way”. And yes: intuition comes from experience, but ideally, it triggers a hypothesis that you then validate.

What idea would you like to close with?

There's something cultural and human about failure and how to face difficult situations that we need to keep exploring. And for me, it's key to learn in community. Many people tell me: “in my company, product isn't done well, I have no one to learn from”. Look outside. There are product communities full of people available and eager to teach.

I was lucky to have managers who taught me a lot, and one day I realized that not everyone has that. Then I said: just as it came to me, I have to help others. Asking for help, going outside, moving away from the idea of “I have to be the perfect product manager” allows you to grow.

The conversation with Jesica leaves us with a fundamental lesson in pragmatism and resilience. True seniority in product is not demonstrated when everything goes well, but in the ability to maintain focus and calm when uncertainties surround us. Jesica reminded us that zero risk doesn't exist and that trying to achieve it is the fastest path to paralysis. The valuable thing is not having all the answers before starting, but having the right rituals to detect risks in time and the courage to say enough to perfectionism in favor of providing real value. In the end, managing product is not about never making mistakes, but about knowing how to correct quickly, deciding which battles not to fight, and learning to navigate uncertainty with determination.

A big hug and see you in the real world.