Liljana
Dimovska
Product Manager with 5+ years experience in building B2B products.
Product Manager with 5+ years experience in building B2B products.
My work spans technical integrations, API platforms, and SaaS products. What energizes me most is a problem still to solve, a product that's evolving, not just a system to maintain. Data drives my prioritization calls and I use it to anchor the conversations around them. I talk to customers even when a project doesn't strictly require it, and I translate technical complexity for whoever is in the room, from engineer to customer to investor.
Four projects from across my career. Each one chosen because it taught me something I still use. Discovery, delivery, strategy pivots, and the decisions in between.
JWX. Post-acquisition product integration
Led a multi-year integration in four phases. Unblocked a $500k ACV deal. Delivered JWX's first native subscription and identity stack.
Read case study →InPlayer. Merch & NFTs
Built a white-label digital goods marketplace from scratch in 4 months, across the entire company. Modelled ROI, led discovery with NFT practitioners, and demoed the finished product to investors.
Read case study →InPlayer. Viewer engagement
Added live chat to a broadcaster paywall. Validation mid-project changed what "MVP" meant and probably saved the launch. Hit the 8% activation target on time.
Read case study →InPlayer. Live streaming infrastructure
Integrated Amazon IVS into a broadcaster paywall, removing OVP friction for 46% of the customer base and automatically renewing the AWS partnership.
Read case study →Not the polished ones from PM frameworks but the ones I reach for, refer back to, and would share with another PM if they were sitting next to me.
When someone tells me something is urgent, I don't move on it until I understand what urgent actually means. What's the business opportunity? What changes if we ship in two weeks vs two months? Most urgency dissolves under questioning. The urgency that survives is worth acting on and it's usually a different shape than the original ask.
This is the principle that's saved me from the most wasted work.
I refuse to give a date before the engineers building the thing have agreed it's a date they can hit. Most PMs commit to something a stakeholder asked for and then turn to engineering to figure out how. I do it the other way around. The result is fewer broken commitments and engineers who trust me, which compounds over time.
Non-negotiable for me. I've watched too many PMs lose credibility by committing on behalf of teams they hadn't talked to yet.
I don't scope something alone and hand it over to engineering and design. The product trio shapes the scope together before anyone's attached to a specific solution. The most complex scope calls got made by working through real customer scenarios together.
This is the principle that's saved me the most rework. It wasn't because the scope was wrong, but because of cross-functional input and visibility.
When a project starts struggling, my first instinct is to check alignment, not execution. Is leadership aligned with itself? Are the teams aligned with each other? Most stuck projects are stuck because people are quietly working toward different versions of the goal, not because anyone is executing badly.
Across the multi-year InPlayer integration, the work that held the project together wasn't delivery work, it was making sure everyone was reading from the same picture.
When a stakeholder disagrees with me, my first move is to understand their reasoning. Not to counter it but to actually understand what they're seeing that I might not be. Then I bring data or a customer story to the conversation. Disagreement usually means one of two things: either I'm missing something they can see, or they're missing something I can see. Both are useful.
This is the principle that's grown the most as I've gotten more senior. Earlier in my career I'd reach for data first. Now I reach for the question first.
I don't spam engineers with meetings. I'm fine with them working async, generating their own docs and thinking through problems at their own pace. Engineers do their best work when they have uninterrupted time to think. A PM whose default mode is more meetings is usually getting in the way of the work they're trying to support.
The clearest signal that this works is when engineers become proactive about surfacing product implications, not just executing tickets.
Sharing how I think about product discovery, stakeholder alignment, and building in complex, multi-team environments with real examples from the work.