Do you think being a product manager means you’ll finally unleash your creative genius? Sorry to burst your bubble, but solution development is way less sexy than you imagined.
If you haven’t read the previous article, Sergii Gudkov, a Product Lead with over 15 years in software development, shared his take on how associate product managers can approach their professional growth.
This time, we’re shifting the focus to more experienced product managers (PdMs). Many believe that once you’ve nailed execution as an Associate PdM, the next step is creating solutions.
Yet, in reality, most of “developing solutions” is about gathering everyone else’s ideas, choosing the most promising one, and making it work. You are not expected to be the smartest person in the room, but to run a tedious, systematic process that actually delivers results.
So, let’s hand it over to Sergii as he explains how to turn this unglamorous work into steady wins and why your “brilliant ideas” can sometimes be your biggest liability.
Solution Development – unglamorous big lie
Here’s something that took me embarrassingly long to figure out:
Solution development isn’t about having the best ideas. It’s barely about having ideas at all.
To clarify this, let me share my own experience.
I once took a PdM job with a very unusual compensation model — no regular salary, just a percentage of monthly revenue. My income literally rose and fell with the business results. At first, I saw it as the perfect chance to prove my creative genius. When the team shared their ideas, I barely listened. Why would I? I was the PdM. I was supposed to have the best ideas, right?
A couple of months of insignificant revenue growth later, I had a moment of clarity: “What the hell am I doing? Why am I ignoring good ideas that could increase my income just because they’re not mine?”
A few more months in, another realization hit me: the CEO didn’t care whose ideas we used. He cared about one thing — revenue. The more I generated it, the more teammates I got, the more resources, the more responsibility. Nobody tracked or cared about my personal creativity score.
That’s when it clicked:
My job wasn’t to be the idea person. It was to be the idea collector.
Tip: Think of yourself as a talent scout. You need to wander around, listen to everyone’s solutions, pick the best bits, and orchestrate them into something that works. Your personal ideas should go into the same pile as everyone else’s without special treatment.
What “development” means for a product manager
In fact, “development” means running a process. It is actually a boring, systematic, and often tedious process. Here’s what solution development looks like:
- Monday: Talk to customers about their actual problems
- Tuesday: Research what competitors are doing
- Wednesday: Collect ideas from the team
- Thursday: Synthesize everything into options
- Friday: Test the simplest version possible
Not exactly the creative explosion you were expecting, right?
However, when I think about it logically, I start wondering if it might be better. Instead of betting everything on your own genius, you’re using the collective intelligence of the people around you. You’re the conductor, not the whole orchestra.
Skills that matter (spoiler: not what you think)
Make reading minds systematic
As an associate product manager, your primary role was to learn — keeping a diary, capturing observations, and getting the basics right. Now, the expectation shifts: you need to ask users to improve their use of your product or prototype.
Customer research sounds fancy—until you realize it’s mostly just asking ‘why’ five times in a row, like a persistent toddler.
“Customer research sounds fancy—until you realize it’s mostly just asking ‘why’ five times in a row, like a persistent toddler.”
At first, you should learn to work with the basics, for example:
- Customer interviews: Not as scary as they sound. Just call five users and ask them to show you how they use your product. However, be prepared that it will be tricky. For instance, I was almost crying at my first session when a user struggled for 10 minutes with something I thought was “intuitive.”
- Surveys: Great for quantity, terrible for understanding why. Use them to spot patterns, not to make decisions.
- Heat maps and session recordings: Watching users rage-click on the wrong button teaches humility fast.
Tip: Start with one research method and get proficient in it before adding more. I know PdMs who’ve built entire careers on just doing excellent customer interviews and leveraging psychology. There’s no prize for using every research tool in existence. On the other hand, the more tools you know and can use, the more tasks you can do.
Bewitch Money: Revenue is your North Star (even if you pretend otherwise)
Ask yourself the uncomfortable question: Does that beautiful feature you’re building actually move the revenue needle, or is it just another expensive decoration?
I’ve watched teams celebrate shipping features that nobody used. They had launch parties, sent company-wide emails, and updated their resumes. However, after six months, they got zero impact on any metric that mattered.
That’s why every solution you develop needs to answer:
“How does this make money?”
And if you can’t draw a clear line from your feature to revenue (even if it’s indirect, although I truly don’t like indirect impact), you’re building a charity project.
This doesn’t mean being ruthless. It means being honest.
Users don’t pay for things that don’t provide value. So if they’re not willing to pay (directly or indirectly), maybe your solution doesn’t solve their problem.
Foresee the future: ship fast or die trying
Time to market isn’t just important – it’s everything. Unfortunately, it’s often where PdMs slip up: most assume the solution they’ve chosen is guaranteed to work. Spoiler alert: it probably won’t.
Your job is to test hypotheses, not just ship. This means:
- Breaking solutions into tiny pieces. Instead of redesigning the entire checkout flow, ask yourself: what’s the core thing that could validate my hypothesis? Ship that first and cut ruthlessly.
- RICE and KANO aren’t just prioritization frameworks. They’re also tools for keeping your team engaged and on the same page. When everyone understands why X comes before Y, there’s less drama, less politics, and more focus.
Tip: simplify ideas. As a leader, people will bring you ideas and ask for resources to test them. Your job is to show how they can be tested with fewer resources rather than rejected.
Practice the voice: Sell and don’t become a salesman
You’ve picked a solution. Now you need everyone else to believe in it, too. This is where the stakeholder communication matrix becomes your best friend. Yes, it will be boring, but absolutely effective.
For this map out:
- Who needs to know what
- When they need to know it
- How they prefer to hear it (Slack? Email?)
- What their specific concerns are
The CEO cares about growth. Engineering cares about technical debt. Customer success cares about support tickets. So frame your solution differently for each audience, but keep the core message consistent.
When PdMs usually screw up
- Trust own gut over data
“I just feel like users would love this feature.”
Famous last words. Your gut feeling is just one person’s opinion in a world of millions of users. Sure, sometimes your intuition is right.
“But betting the company’s resources on your feelings is not product management; that’s gambling.”
- Becoming a solution dictator
Some PdMs push only their ideas and ignore everyone else’s input. They might get away with it for a while, but eventually they hit a wall. Nobody’s right all the time.
Remember that nobody’s right all the time. When you stop listening, you stop learning. The best PdMs I know have strong opinions, loosely held. They’ll fight for their ideas but change their mind instantly when presented with better evidence.
- Forget the money
“But it’s such a cool feature!”
Cool doesn’t pay salaries or keep the lights on. I’ve been in too many meetings about amazing features that had zero connection to business metrics. I’ve even seen teams build a “great product” and then run out of money to keep it alive.
- Burn bridges with stakeholders
You might have the best solution in the world, but if you’ve pissed off the people who control resources, you’re done. I knew a brilliant product manager who treated stakeholders like obstacles instead of partners, which ultimately didn’t help.
So stakeholder management isn’t optional. Their opinion can give you the difference between ideas that ship and ideas that die in Google Docs.
What’s Next? The Problem hunt begins
You can deliver features, develop and test solutions. However, it still doesn’t mean you can find the problems yourself.
When you do move to this step, that’s when product management gets really interesting. You’re not just answering questions but figuring out which questions to ask. You’re not just building solutions but discovering what actually needs solving.
Yet, that’s a story for the next article:)
For now, remember: solution development isn’t about being a creative genius. It’s about running a systematic process that turns collective intelligence into shipped features.
