Contact us


9 min read

Product Ownership — Rights and Wrongs

Product Owner

Several years ago, I applied for a job as an Android developer at COBE, right before the job ad expired. The position was already taken but I was offered to work as the company’s first QA engineer. Soon, having a defense line became inevitable and we decided to grow our team — the second QA place was soon filled out by my best friend, and I was as happy as I could be.

From QA to PO

At that point, we thought that we were working by Scrum, except: we didn’t have a Product Owner, nor a Scrum Master and neither of the ceremonies except dailies that lasted for one hour. But we had iterations, which were, let’s say flexibly time-bounded, with crazy unrealistic deadlines cause it was believed to motivate.
The Scrum we had was broken, and we thought introducing roles would fix it. It turned out that Android development was long behind me as I was given the role of a PO with an explanation “You already write all the cases to check, now just write it before it’s implemented.”

Spoiler alert — it didn’t work quite well.

Product Ownership — how NOT to

I struggled with the acceptance criteria.

I would specify the requirement by defining what should happen by tapping on a button, going to the background while the screen is loading and returning in less than 100 milliseconds, all the while having a crappy internet connection. Although it made sense to cover this case as a QA to make sure the app doesn’t crash, it was painfully obvious that the criteria was far from the useful guideline a PO would give to the team.

I struggled with prioritization.

Before, we would start with a registration requirement. Then go on with the forgotten password functionality (depending on the social flag), and editing the profile screen (including custom crop on profile picture). Finally, we would proceed to the feed implementation of items that can be added to the wish list after authentication.

You can see right away something’s wrong here. There’s no use of registration unless users gain some significant advantages by logging in, e.g. the ability to save the items they love for a later purchase.

12 projects later, it looks much different

Fast forward to today, the main focus is value (which is aligned with a vision), that a certain functionality brings to end users, making them curious to proceed with all kinds of scenarios.

Also, we figured out there’s a few things to be careful about:

  • what we communicate to users, through pure strings, crazy animations or even white-spaces
  • what we research about the market
  • what encourages users to start their journey, stay on track, to search for more or to even buy more

Value is key

As mentioned in my previous article, we work by agile. And in agile, value is directly related to priority — most valuable goes first. So we start with the core, making sure we provide quality on a simple yet valuable flow and build just in time, exactly what we need to wrap it all up. Next, we release it as soon as possible, collect feedback and keep following the vision. The focus is on what really matters — results.

It’s a complicated process and to make it work, you’d need a winning combo — a perfect feature selection, a careful UX/UI approach, highest technical quality and QA validation until the products are bulletproof.

Sure, it’s not easy but it’s all possible through great teamwork.

It takes a team to win

Even when things didn’t look so bright, my colleagues always gave me a reason to stay. We built trust brick by brick and that helped us through the tough times.

And trust doesn’t just fall from the sky, we gained it and now we own it. It took us a lot of compromises, lots of understanding but disagreements too, dozens of small victories, some broken words and all promises kept.

One thing that made us stand out in the crowd is — always caring full hearted. About the product, about each other, about the quality, scope, user experience or our culture.

Wrapping it all up

Want to hear a secret that will resolve all your PO problems? It’s 42!

I know :). It’s all about the experience, good or bad, about getting smarter along the way, learning to focus on the right priorities, putting a lot of work into making things happen, and even being lucky enough to be able to show improvement. You see, every piece fits into the puzzle.

And no matter what you do, you should love it. It doesn’t make sense otherwise.

This is my story about getting it all together, from scratch, from the point I didn’t know the hell I was doing — to the point where there’s always room for dessert.

Everybody has their own problems and solutions, and I would love to hear about yours!

Like what you just read?

Feel free to spread the news!

About the author

Josipa is a Product Owner at COBE, working with both the development team and COBE partners, to ensure good strategy, which results in great products that customers love. In her free time, she enjoys playing with her kid. She also loves books, cakes, and music. Oh, and beer, she loves beer.


Product Owner

Write COBE
Related Articles

Still interested? Take a look at the following articles.