Product Ownership in Practice: Beyond Processes and Backlogs
- Alexander Abramovich
- 2 minutes ago
- 12 min read
After a year working as a Senior Product Owner at the Platform Engineering Division at CyberArk (acquired last week by Palo Alto Networks), I wanted to reflect on the unwritten reality of this role.
This article details the soft skills, techniques, and principles for preventing future debt, scaling team thinking, and ensuring that the problems we prevent matter as much as the features we deliver. Think of it as diving beneath the by-the-book surface — into what no job description will prepare you for.
Guest Writer Introduction
Alexander Abramovich — Senior Product Owner at CyberArk, working with platform teams on tenant lifecycle, authorization infrastructure, and partner ecosystems. Also makes electronic music as Total Reboot.
Find me on LinkedIn, Instagram, Telegram, X (a.k.a. Twitter), and Farcast.
Table of Contents
The Role of a Product Owner Persona
CyberArk splits it: Product Managers (PMs) face outward to customers and the market. Product Owners (POs) own a product domain in full — details, execution, technical leadership, and team orchestration. We move together — the boundaries flex, the accountability doesn’t.
PO responsibilities typically include backlog grooming, stakeholder alignment, and roadmaps. The actual work is about soft skills in disguise: shaping how people think about problems before solutions take form. Most of it is invisible, and the evidence lives in what doesn’t happen — architectural dead-ends not taken, edge cases that never multiplied, decisions made calmly rather than under pressure.
At its core, a PO masters three things: knowing what to build, delivering it on time, and motivating people without authority. I’ve organized the lessons around four facets: Shaping Thinking, Shaping Delivery, Shaping Influence, and Shaping People & Teams.
In my day-to-day, I work with four teams across tenant management, authorization infrastructure, licensing, and partner ecosystems — core platform capabilities that everything else builds on. High importance, high urgency, multiple teams depending on your calls. Stakeholders range from developers and architects to product managers, support, and leadership — each with different timelines, vocabularies, and definitions of success. Lots of responsibility and impact, I love it.
The job description might seem simple enough, but it requires nuance and a mixture of soft skills and, in many cases, leadership. Let's unpack these concepts.
Shape Thinking
Seeing What’s Coming
There’s a Hebrew saying: אֵיזֶהוּ חָכָם? הָרוֹאֶה אֶת הַנּוֹלָד — the wise one sees what’s coming.¹
Seeing the full picture of system usage matters more than the requirement in front of you. As POs, we’re not just delivering today’s feature — we’re shaping how quickly tomorrow’s roadmap becomes reality.
A “Tenant” in SaaS is the customer’s isolated environment with services that each provide dedicated security capabilities: Privilege Cloud for secure credential vaults and automated password rotation, Privileged Session Manager for session recording and audit, Endpoint Privilege Manager for enforcing least privilege on endpoints, Secrets Manager for machine and application credentials, and CyberArk Identity for single sign-on and workforce access.
Beyond these, there are platform-wide infrastructural capabilities — authorization, audit logging, notifications, and AI bot integrations — that span across services. Take “Notification” as an example. Services send notifications to customers and internal operators, but so does Tenant Management itself. By defining each capability as a self-consistent building block — distinct from any single service — we avoid duplicating logic everywhere and gain a unified way to handle email, in-app alerts, and other channels.
For the math nerds: think of it like linear algebra. Two vectors on the same line just give you a longer line. Two vectors pointing in different directions give you an entire 2D plane. Add a third independent vector, and you’ve got 3D space. (more precisely: I’m looking for a basis set — the minimal linearly independent vectors to span the maximal functional space.)
The right core abstractions give the whole team — product, dev, architecture, UI — a shared language of decoupled reusable primitives. Velocity goes up as independent capabilities are built in parallel, and fewer meetings are spent aligning on fundamentals — that’s scaling the organization’s thinking.
Sanity Checks
Before locking in a design, I pressure-test it against a few criteria:
Invariants. Does the order of operations change the result? If “Upgrade to paid” then “add seats” yields a different outcome than “add seats” then “upgrade” — that’s a time bomb. When behavior depends on when users act rather than what they intend, you’ve designed unpredictability into the product.
Consistency. Same input, same behavior — regardless of the flow. Not “works here, breaks there.” Design for intuitive predictability and ease of use. Even a consistent bug is better than an inconsistent one — at least you can fix it in one place.
Exceptions. Systems collapse under the accumulated weight of special cases, each implemented “just this once.” Don’t patch the rule to allow the exception — expand the model until what was an exception becomes a naturally supported capability.
The Unifying Abstraction
When you find the right abstraction, it works across the board — customer journey, business logic, architecture, and team structure. That will feel like an aha moment.
Building the right model requires understanding the full lifecycle: how a capability is marketed, sold, provisioned, implemented, maintained, and expanded. The goal is a clean model — from end-user need through technical implementation to executive reporting, everyone recognizes the same structure. When everything aligns, edge cases fold into patterns and code shortens. Part analysis, part inspiration — you keep rotating the problem until it clicks.
Validation Through Analogy
Any concept can be tested with a familiar analogy — if it holds, you’re on track. I use what I call the Tree Test.
Imagine your architecture as a tree. Grab it by the trunk — its center of gravity — and the whole structure lifts coherently. Feels stable. Now try lifting the entire tree by a single branch. It swings wildly, twists out of your hand, unbalanced.
A developer was building notification logic, organizing everything by email type first (Welcome, Reset Password), then handling tenant type (Production vs. Trial) inside each one.
We applied the test. With “email type” as the main container, we were holding the tree by a branch. The heavy business logic — how a Trial tenant behaves — was scattered and duplicated inside every email template. Top-heavy, hard to maintain.
The fix: flip it. Tenant type became the trunk. We defined “Trial” behavior once at the root; all email types branched off naturally. Suddenly, the architecture felt light. The code balanced — dependencies flowed the right way.
The right analogy can help reveal that your system is structured around the wrong axis.
Shaping Delivery
Creating Space for Decisions
Platform teams face everyone’s urgency, and the instinct is to react immediately.
A better instinct: slow down first. What’s the proper way — the king’s highway, as we say in Hebrew (בְּדֶרֶךְ הַמֶּלֶךְ נֵלֵךְ)?²
You define the ideal solution — minimum building blocks, maximum coverage of scenarios — not necessarily to build it today, but to orient yourself. Once you know the destination, a shortcut becomes a calculated decision rather than a wrong turn — even a partial implementation points in the right direction, saving you from “temporary” fixes that require a total rewrite later.
Create the space to think. It pays back. The shortcuts will still be there — but now they lead somewhere.
Closure at Every Step
Every iteration should bring some usable value to the user. Smaller scope, fully finished: deployed in production, documented, no open questions.
“Users can now export their data” means the full stack is validated. The risk of components not fitting together is exposed and resolved early.
Compared to “we built the database layer” — that’s a risk hidden in the gaps between layers, waiting to surface only when you try to connect the UI weeks later.
Ship less, ship right.
Signal Over Noise
The Product Owner sits at the busiest intersection in the company. If you don’t control the flow, meetings derail into debates without decisions, and loud voices drown out the actionable plan.
Your job is to force convergence.
Agendas sent ahead of meetings, the “this could be a chat” filter, and strict timeboxing might look like administrative nagging. They aren’t. They are the infrastructure for clear thinking. By stripping away the noise, you ensure that every interaction ends with clarity — a decision, a direction, or a defined next step.
Right Place, Not My Place
When a new request lands, the immediate instinct is to ask: “How do we build this?”
But before scoping the work, we have to scope the ownership. Guided by “what’s best for CyberArk” — a principle we return to often — the real question becomes: “Where is the natural home for this?”
The goal is to leave stakeholders with a path forward, not a dead end.
A business request came in that would have required redundant development work on our part. We redirected it to the analytics team — they already had the infrastructure to build the dashboard in days; we would have taken weeks. The business got its answer faster, our team stayed focused, and the company avoided building the same tool twice. Everyone won.
Shaping Influence
One Door Opens Another
Sometimes you sense the right technical direction, but the organization isn’t ready for the big fix. The risk seems too high, or the business case isn’t clear enough yet.
That’s not the end — it’s a cue to switch tactics. If the front door is locked, find a window.
We needed to integrate with a service running legacy patterns. Pushing that team for full migration immediately would have failed — no appetite for that scope. Instead, we focused on building just the POC using our modern API patterns: low stakes, low friction.
Later on, when they came to empower the legacy integration with new capabilities, the suggestion came naturally: “This piece should follow the new architecture too. The POC already works that way.” One successful pattern created the path for the next. We didn’t win the argument — we just made the right path the path of least resistance.
Smart Persistence
Treat “no” as the start of exploration. Why did they push back? Is there a hidden constraint? A political concern? A technical risk you missed?
Coming back with the same argument is stubbornness. Coming back with a proposal that addresses those specific concerns is a strategy.
And sometimes, the data you gather changes your mind. You might realize their “no” was valid for reasons you hadn’t seen. Adapting your view based on new facts isn’t losing — it’s aligning. That’s how you build trust — by showing you’re listening, not just pushing.
High-Leverage Expertise
My background is multidisciplinary — I’ve served as a CPO in startups and in Product roles in international corporations in multiple industries, led development and design teams, shot photography, and produced music. That experience builds a specific kind of intuition: the ability to spot “anti-patterns” before they become disasters.
I don’t sit on the sidelines — but having the skills to do the work means knowing exactly when to step in. The art is not in holding back, but in finding the right point of entry. I give the team space to own the “How,” but I remain an active co-pilot. I don’t intervene to prove I can code; I intervene to unlock the flow.
For example, an architect was building his first analytical dashboard. The initial draft was disjointed — just widgets on a screen. Instead of redesigning it for him, I sat down for fifteen minutes and downloaded my BI experience: dimensions, real-time aggregations, and visual storytelling. The next day, he produced a dashboard so engaging that data validation — usually a slow, painful process — happened almost automatically. The stakeholders were so eager to “play” with the new tool that they validated the data without even realizing they were doing the work.
In another case, we needed a department to execute actions they knew how to do, but triggered by events they didn’t want to own. It was a wall. I used my architectural background to design the key: a generic implementation where they owned the mechanism, and we controlled the policy via config files. With the right decoupling, the deadlock dissolved, and as a group, we pursued “what’s best for CyberArk” yet again.
This is the balance: I let the team drive, but I watch the road. When I do grab the wheel, they know it’s not to micromanage — it’s to keep us out of the ditch. That credibility turns you from a boss into a mentor people actually seek out.
Synergy Over Victory
In a large company, agendas rarely align perfectly. Prioritization meetings can get heated when resources are scarce, and pressure is high.
The goal is to find synergy. By remaining trustworthy and constructive, you become the person others want to help. You can crush a colleague with superior arguments and lose the relationship, or you can find a shared path and build an ally for the next ten projects.
I’ve learned that in disagreeable moments, your demeanor matters more than your argument. I’ve watched mentors who, when the temperature in the room rose, didn’t raise their voices — they smiled. It wasn’t a smile of dismissal, but of invitation. It signaled, “We are on the same side, we just have a puzzle to solve.”
Shaping People and Teams
Knowing Your Instrument
Sometimes I’m the conductor — coordinating, setting tempo, keeping everyone aligned. Sometimes the composer — creating structure, writing the “score” of criteria and philosophy. Sometimes a musician — playing my part, proposing specific solutions. Sometimes just the listener — absorbing, not intervening.
The skill isn’t mastering one role. It’s sensing which instrument the moment needs—first violin today, second violin tomorrow. The smartest person in the room is often the one who knows when not to speak.
Criteria, Not Answers
The highest-leverage move is to tune how people make decisions rather than making decisions for them.
This means explaining why certain things get prioritized, e.g., what makes a good architecture or a great user experience. Answers create dependency. Criteria create healthy judgment, and people feel driven when they get the “why”.
This is especially critical when working with team leads — they pass on whatever mental models they receive. Calibration cascades through the organization.
(Related: Developing Manager Handbook)
Validation as Fuel
My job is to be rigorous about the “What” — the UX, the requirements, the business logic. I ensure these are clear, documented, and unambiguous.
When the team brings an approach that meets those requirements, I validate it — even if I would have done it differently.
Why? Because the moment they designed it, it became their plan. Validating it seals that ownership and signals trust in their judgment. That is what turns simple execution into true engagement.
Transparency, Not Micromanagement
Visibility into what’s happening matters. Control over what’s happening doesn’t. Stay close to the tricky parts, but let people navigate. Offer help when they’re stuck, not before — that’s how experience-based judgment develops.
Tuning the System
The approach that scales: tune one part of the system, verify it works, move to the next.
When transferring principles that will be replicated — what is the core issue we are solving, how we make data-driven decisions — go deep. You’re calibrating someone’s judgment, not assigning a task. Take the time to ensure the thinking is internalized, not just acknowledged.
When it’s executed within established parameters, the touch is lighter. Define the outcome, step back, and check the result.
The rhythm resembles spaced repetition: intense focus during setup, then periodic check-ins that grow less frequent as confidence builds. You’re building a system that runs correctly without constant attention.
Descent for Ascent
There’s a Hasidic principle: sometimes you have to go down to go up — יְרִידָה לְצֹרֶךְ עֲלִיָּה.³
In practice, this means letting people make learning mistakes rather than preventing them. Not catastrophic ones, but the kind that teaches. Being there afterward matters — understanding together what happened, fixing it, and extracting the lesson.
“Let’s figure it out” is where growth starts. When someone falls, we extend a hand and walk together.
Together We Stand
Every pushback teaches something — a blind spot, a constraint you missed, a perspective that strengthens the solution. Every like-minded colleague (and they challenge you, too) extends your reach. The patterns in this article emerged from countless conversations, disagreements, and shared problem-solving sessions.
No one scales alone. The work is too complex, the perspectives too varied, the load too heavy.
Every exploration is an adventure. Like making music — when I start producing an electronic track — I don’t know how it will end. You embrace the change as reality shifts around your decisions.
Formalize what you learn. Share it. That’s how organizations grow — not through individual brilliance, but through knowledge that compounds across people and time.
I’m grateful to work in an environment built on being Smart, Bold, and Humble — where the focus is on the work itself — quality, concepts, and craft.
To my managers, teammates, and colleagues across CyberArk’s Platform Group — from two teams a year ago to four today: thank you for the space to learn, the patience to teach, and the trust to let these ideas develop. Whatever value is here comes from working alongside you:
Ran Isenberg, Koby Aharon, and Prakash Premson Karkare — Architects whose technical vision and platform engineering thinking underpin much of what’s written here. Ran’s work on serverless architectures and reducing cognitive load across teams has been particularly influential — check out his blog at ranthebuilder.cloud.
Shlomi Shaharabani, Or Zimon, and Govind Haridas — Team Leaders whose day-to-day collaboration keeps these product principles grounded in engineering reality.
Meitar Karas and Tal Joffe — My leadership chain shaped not just what I deliver but how I approach growing others.
Tomer Iyar — Product Manager whose perspective keeps product thinking connected to what actually ships.
Footnotes:
¹ Babylonian Talmud, Tractate Tamid 32a. From a dialogue between Alexander the Great and the Jewish sages: “Who is wise? One who sees what will be born [the consequences].”
² Numbers 20:17. Originally, the main royal road through a territory; in modern Hebrew, an idiom for “the proper way” — doing things correctly rather than cutting corners.
³ Likutey Moharan II:12, teachings of Rebbe Nachman of Breslov (1772–1810): “When a person needs to ascend from level to level, there must be a descent before the ascent, for the descent is the purpose of the ascent.”