The Product Manager in the Middle: Converging, Diverging, Not Working
Product Voyagers presents our first guest writer - featuring Ines, a Senior PM who shares her experience of embracing individuality while navigating the constraints of product frameworks.
is a Senior Product Manager based in Berlin and working at Delivery Hero, where she builds complex global products in the Q-Commerce space, focusing on Assortment and Pricing. Known for her unique perspective and fearless approach to both challenging and being challenged, we are excited to welcome her as our first guest writer in the Product Voyagers community!
As someone who’s often felt like I was swimming against the current, I want to share how I've sometimes deliberately done so —and why it worked.
Conflicting Guidelines for Fresh Product Managers
When you're just starting out as a Product Manager, the amount of conflicting advice can feel overwhelming. Throughout my career, I’ve read more books, guides, and tips than my brain can recall - and while these are great for fostering a product mindset, they can also be confusing.
Beware! Less experienced peers might take these guidelines as fact, leading to harmful practices by blindly following them. Some might even brute force advice into situations where it doesn’t fit, leading to unnecessary struggles or, worse, bad Product practices.
My goal in this journey is to highlight some of the most common guidelines and suggestions that fresh Product Managers, like myself when I first dipped my toes in these waters, often hear during their first steps into the role. I want to join you in challenging and embracing advice that truly suits us as individuals while building our own path through Product.
Hence, I felt compelled to challenge the trendiest of Product "To Do's" based on my experience facing them. And I start with the one which has been a pebble in my shoe for the last few months: “The Double Diamond” or Divergent <> Convergent Framework.
The Double Diamond: Helpful, but Not a Law
For starters, the Double Diamond is a great framework for any Product Manager to understand how any thought process in the Product World should originate. I’m not going to fight anyone on that.
It trains your brain to avoid jumping into producing features because they sound like a great idea and end up wasting resources on a shiny trinket that doesn’t add true value.
If a solution did not come to you while looking at a problem, there’s a high chance that you’ll fall prey to confirmation bias when trying to apply this framework. The human mind is great at finding reasons for things, even when there might be none.
Those are the reasons why the first step of this framework is truly vital to any initiative you want to plan - always start at the beginning: “What problems am I surrounded by?” From there, you are less likely to make the mistakes described above.
However, the issue I’ve encountered is that many apply it too strictly. You’ll find peers along the way who will chastise you if even a hint of a solution enters your mind when addressing a problem. And whilst they might be truly concerned that having a solution in mind will generate a confirmation bias in your reasoning, they are missing out on a very important detail - this is simply human nature.
Problem solvers naturally think about solutions when they see a problem. They will not be able to simply look at a problem and go “Ah yes, this is indeed a problem, and yet I have abstained myself from the temptation to think about how it might be solved”.
That’s because the natural pathway is “I see a problem, which can be possibly solved by A, B, and C”. If your brain did not generate any hypothesis, then that might be more concerning for your road down the Product career.
Trying to completely abstain from thinking about solutions can be counterproductive. It might give you a harder time gathering support and clearly explaining to your peers what we are trying to solve at hand. More abstract problems can become clearer once you hint at their next steps. And then again, there’s not a lot of value in simply stating a problem exists.
Non-linear Thinking: Breaking the Rules
Now for the “based on a true story” part of my rant.
I’m a non-linear thinker. My brain bounces ideas around at hyperspeed while I try to make sense out of it and - form an output. I don’t rationalize approaches in a traditional 1-2-3 steps but rather when I look at a problem within my scope which needs solving, the next steps all appear at once and I’m set to order them out so I can start solving it.
The double diamond gives you a template on how to think:
I found a problem
There is indeed a problem
This might solve it
This is how we try to solve it
But this didn’t work for me, and I failed or got confused when I tried to religiously stick to it.
I was absolutely annihilated when presenting the initiative to my peers, being consistently challenged because they felt that I was jumping steps, always addressing a solution and not showing them the problem.
It was incredibly frustrating - because to me and my team, the problem was so evident, why were people pushing back so much on it?
This frustration led me to a chat with my mentor. I started realizing that when I spoke freely about the initiative itself, my ideas made more sense and it seemed easier for people to see where I was coming from.
So where was the disconnect? Was it truly wrong of me to generate solutions, sometimes even subconsciously, when identifying the problem?
Guidelines as Tools, Not Rules
The obsession with following the template and guidelines was holding me back. I was focusing so much on the path and its tenets, that I could not communicate it properly. It was stifling my output. So I decided to respect the core concepts of the Double Diamond but give it my own spin:
I stopped hyper fixating on how everyone else was doing it.
I focused on explaining it my own way to yield more consensus and more understanding.
I realized that, for some of us, guidelines should be exactly that, guides. Putting us in a place with just the right amount of tools for us to make our way through the path, not herd us towards point A to point B.
I invite you to do the same. Use guidelines as guides, not rules. If you get stuck, take a step back and try approaching it instinctively, rather than the way people expect.
So… in a true PM article cliché fashion:
Do: Start your thought process from an existing problem within your scope, and follow your instinctive thinking.
Don’t: Hyperfocus on compartmentalizing your thought process to match a template or guidelines, nor abstract yourself from any solution ideation during the problem-space discovery and mapping. Just keep your communication and documentation as clear and straightforward as possible, without fighting the solutions that pop up in your head.
Key Takeaways:
Start from the problem, but don’t be afraid if solutions enter your mind early.
Guidelines should be flexible - adapt them to your natural way of thinking.
Over-compartmentalizing can stifle communication and hinder collaboration.
Communicate clearly and confidently, and don’t fight the solutions your brain naturally generates.
Use frameworks like the Double Diamond to guide, not dictate, your process.