How to Start Your Journey as a Product Owner

Two feet stand before a start line

*This is part of an ongoing series from Rezilion titled Enlightened Engineering: Reflections From Rezilion’s Tech Team

By: Yagel Sheli, Remediate and Mitigate PO, Rezilion

The gap between Product Managers (PM) and R&D managers has existed since the beginning of the software industry.

The PM wants to create the perfect product for their users, add shiny new features all the time, and support as many types of users as possible – while still maintaining a product that is well suited to them. PMs want to move fast.

Devs, on the other hand, want to close tech debt, maintain a stable, secure, and robust system, and test every change extensively.

They want to trust their codebase.

And of course, as a company, you have a combined goal of growing fast yet steadily.

In order to close this gap, many methodologies have been developed over the years. At Rezilion, we’ve implemented one invented and used by Google: the Product Owner.

A Product Owner, or PO, is a new role that acts as a bridge between PMs and R&D.

POs need to be able to understand both product and business requirements, then take them into consideration in order to allow an organization to make the best decisions while balancing complex tradeoffs.

So, who is fit to be a PO?

They’re not exactly developers, nor are they product managers. They’re something in between.

If you’re something in between, your challenge is not only to see both perspectives, but to marry them together and give adequate space for each to grow and nourish each other.

To do that, you’re going to need to speak two, often conflicting languages.

In this blog post, I will try to help you understand both sides and give you some of the tools and resources that helped me move from an R&D perspective to a broader PO perspective.

Know Your Enemy – Or How to Speak Product

If you want to understand a product, you first have to learn Productish – the lingo of product managers.

Similar to the development process, where we first have the system design, later the feature definition, then TDD and code review, the product management life cycle has a structured process as well.

Design sprints to understand the market and the problem, followed by persona definition and user interviews to validate them, then user stories and user flows before development, and finally user acceptance testing to ensure the developed product matches the needs of the users.

If you didn’t understand some of those terms, consider brushing up on your Productish using the recommended reading list 🙂

I’ve found these books to be really helpful: Jake Knapp’s “The Sprint” and Marty Cagan’s “Inspired”. I would suggest reading both of them for anyone who wants to learn the essential principles of Product Management.

For those who prefer videos over books, a series that I highly recommend is “Design Sprint 2.0” by AJ&Smart. It gave me some great tools to help conduct a design sprint the right way (the best version of brainstorming I’ve ever found).

Learn Your Team and Coordinate With Them

Most of the time, a great impact is not created alone.

You have a group of great minds in your organization, and when they work together, far bigger changes can be accomplished.

During your first few months of working as a PO, one of your first priorities should be connecting the dots in your organization.

You will have to understand what functionalities each team in the R&D organization can provide, who you should speak with, and to define a workflow to work together efficiently.

Here’s part of the flow we’re using in Rezilion:

Understand the Business Needs

You should also have a deep understanding of the business topics your product is related to:

  • What is the GTM (Go-To Market) strategy for your product? How will your customers learn about you and where are they coming from? – A new customer segment? An upsell? Maybe an alternative to a current product?
  • Where is your product placed in the company’s marketing strategy? What content can you create for them in order to create brand awareness and position your product in the competition?
  • Where in the company’s roadmap will your product be involved? This will help you to make better decisions in the R&D work plan

So Many Questions, Where Should I Start?

Answering these questions is best accomplished by communicating with the relevant people within your organization whether they are the Head of Product, VP R&D, or even the CEO if your organization is smaller.

Remember – the more stakeholders you involve, the greater the impact you’ll have.

Don’t Be Afraid to Ask!

R&D positions are mostly self-contained, so moving to a role that involves so many participants might be overwhelming in the beginning.

Just remember that you’re actually solving a big problem for your organization, and it’s in everyone’s interest that you succeed, since it will help the company as a whole to achieve everyone’s goals – move fast, trust your code and grow.


There’s always a learning curve when moving to a new role.

I advise you to check out my recommendations for books and video series that helped me learn the essentials.

I also encourage you to seek out answers on any of the other topics I mentioned that piqued your interest.

Good Luck!

Reduce your patching efforts by
85% or more in less than 10 minutes