My job as a hands-on Product Owner

This is 100% one of the most difficult blogs I ever put on digital paper. And I must say, during my internship and part-time job after that, I have written quite some content. I am not a very confident person and having to share my way of working with other people feels vulnerable to me. It is very personal and for me, it feels like a normal day-to-day thing to do. Therefore I am not saying my approach is the best approach or even if it is a good approach, it is simply my approach.

TL;DR: I make sure that I am involved in the different cycles of the Product development process by communicating with my team, writing clear documentation, and being involved in testing the different phases and telling the story.

Being involved in the process from start till end

As the title says, I like to see myself as being hands-on, I’m more a do-er than a leader honestly (at least that’s what I feel myself). This means that whenever we start up a new project, whether this is data-driven or management-driven, I am 100% involved in it.

The schedule above roughly shows or current cycle when it comes to developing new or improved features. I try to be involved as much as possible in every step of the process and I show you how.

The Product Alignment Document or PAD

Documentation is key for me when it comes to starting a new project. I was once granted the format of a Product Alignment Document, an approach that was introduced by Miro and I stick with this with every new project we start.

A Product Alignment Document is used to be your bible during the entire project: you describe the problem you are going to solve, research possible solutions, pick one, and document everything there is related to the product.

As you might have learned within this blog already, my documentation is quite elaborate. So were my first PAD existed of one very long (notion) document, including a table of contents, I learned to transform it into a TL’DR. That reminds me, I should probably include one for this blog as well ;).

This means that with every new project I launch, I create separate pages for the Problem analysis, Customer research, Stakeholder research, competitor research, and all other parts of the analysis and I write a summary in my PAD.

This way I have it my way in having a complete overview of data, problem statements, and documentation while giving everybody that is involved a chance to quickly grasp the goal of the project.

And what I can’t put to words, I try to draw with maybe not the best designed ever screenshots or schedules.

Low fidelity and High Fidelity: Let’s design it

After I have created my document, it is time to hand things over to people that are way more talented in making nice things than I am: the design and development team. Since there is no real design yet, with the development team I am just doing a quick Technical Check, or the so-called Bob the Builder check: Can we build this?

If the answer is yes, I step on to my design team, quickly discuss the problem and what I think the solution should be, and set them off to the drawing table, or in our case Figma. While making sure that everybody is on the same page, we have (and I suppose many other companies do this as well) two main phases here: Low fidelity, where we merely outline a rough solution, and high fidelity where we make this solution look very good.

Even though I am far from being a designer, I love to be involved in the thought process. This means that we organize Ideation sessions in which wireframes and ideas are shared just as long as we think we find the ideal solution.

And once the wireframe can be transformed into a working (but still plain) prototype, we share it with a few in-house shareholders. These are people from different (customer-facing) teams within or organization that can click through our solution and shares feedback. After such a session, it is often fine-tuning the wireframes and moving over to the high-fidelity, where we start to make things look even nicer. And then the whole process starts over: sometimes we hold an extra ideation session to process the feedback, but for sure we have another Bob the builder check and another feedback session so we can deliver the best we can.

Working in Milestones

After the design has been completed, tested, and approved, it is time to hand it over to our development. And I must say, I only have done a few projects right now, but since we are a Start-up / Scale-up organization, these projects often are HUGE! And my very rookie mistake with my first few projects was: “Let’s build ALL of this just at once.”

I can tell you we were able to deliver these features eventually, but please don’t ask me how long this took. All I can say is that it was a bit far from the Scrum idea to deliver value in every sprint. But hey, I’m a very new and junior Product Owner, I make mistakes to learn. So from now on, whenever a project is ready to be coded, together with my entire team (developers, designers, and QA) we come up with a way to spread the workload. How can we split up the project in smaller steps or milestones as we call them for now, to start shipping faster and delivering value sooner?

As a Product Owner and a decision-maker I could have made this decision on my own, but we are such a young and ambitious team, I value and need the input from my developers here. I want to know how what they feel they can achieve in a fixed amount of time and what is technically needed, from my design team I’d like to know how features can best be split up and my QA’s help me to determine whether a step we build is already delivering value for the customer.

Once we have decided which milestones we are going to do and in what order, we move this into JIRA by creating user stories and technical cards, refining and planning them.

Let’s build this

And then the moment starts that we are going to actually build a feature. As little as I can design, even less knowledge I have of writing code. So how do I make sure that I stay involved in this process? First of all, by having the Bob the build meetings already during the design phase, not only are we checking “Can we build this”, but I also love to know “How are we building this”.

And I feel this is the hardest part of being a Product Owner (at least for me), as I am inclined to say I have too little technical knowledge for this. But I always make sure to talk the project or the relevant milestones through with my front-end team and my backend team. I tell them the goal I wish to achieve and both of the teams tell me how they are going to build this.

This already learned me to recognize tasks that involve backend developers and tasks that involve frontend developers (most of the time at least). Why is this important? When it comes to planning a sprint, I know how many backenders and frontenders I have available, and I also know whether a project is frontend heave, backend heavy, or both. So I know how much of a project I can embark on and what I can ask from my developers besides the project. It helps me in monitoring the workload and task load per developer and being on top of the progress we make.

Testing

I feel testing is a crucial part of building and improving things. To see if it is working, how it looks like, and how your feature interferes with other features. Up until very recently (about 3 months ago) we had no QA engineers, which means that I did a lot of testing myself.

Is this ideal? Far from, because we missed out on things like automated testing and especially with larger updates: you are easily overlooking things.

Was it a lot of fun? Definitely! I enjoy testing features, it feels as if the stuff that was in my head before finally comes to life. Next to the fact that it is fun, it was also very useful (or I believed), because once again it increases my product knowledge, I understand how it works and as a product owner it is also the best opportunity to check up on the quality of the developer and design work. So even though we have two amazing QA engineers at hand now, I still feel that I should be involved in testing and have clicked through the features at least once, to see if it matches with what we agreed upon from the beginning.

Go to Market

As exciting as testing and playing with a feature yourself is: you are not building this merely for your entertainment, the eventual goal is to make your customers happy and therefore you should spread the news of what is coming not only to your customers but also to the entire organization.

I love to work closely together with the Product Marketing team on this, discussing the strategy for release:

• What are we going to tell?
• How are we going to tell this and what channels are we using?
• Who are we going to tell this?

During multiple sessions, we try to answer these questions and come up with a cool go-to-market strategy. And I don’t only like to discuss the strategy, I’m keen on participating as well.

Once again, there is only so much you can do of course. I like to keep the video-making part to our video creator and I know our marketers are way better at writing than I am, but I’m still fond of writing a blog now and then, making small announcements, or even hosting webinars. And when doing this does not fit my schedule, I’m at the very least available for brainstorming sessions on the content.

Shipping

Even more exciting than testing a feature is shipping a feature! Publishing and sharing the feature with my colleagues and our users. I must say that in the scale-up life of our organization there is a lot of cowboying in this phase. When it comes to bigger features or changes, we sometimes launch it internally first (only visible for our account to let the entire company test it) and we have done a little experimenting with Beta-testers, but for most features, we have an all-or-nobody approach.

We are getting more towards working with beta-testers and here as well I am involved in spreading the news, collecting feedback, and so on, once again with a hands-on approach: trying to quickly qualify the feedback as bugs, must-haves, or nice to have and make sure my development team is ready to hotfix any upcoming issues as soon as possible. At these moments I try to be available and reachable not only for the feedback providers but also for my team, to make sure we are all working towards the same goal.

So where does this get me?

Well, I think in the past half a year (or even a bit longer) I have grown as a Product Owner and as a person. If I take a step in the past and look where I was a year ago: a Senior Product Specialist that felt she had outgrown her current position but also was not quite sure if she was capable of taking the next step. I mean, I knew I had a passion for our Product and a great wish to make work of the customer feedback I have been collecting in the past years, but I definitely did not think I had the capacity to become a Product Owner. (I’m far from Pippi Longstocking’s “I’ve never tried that before, so I think I should be able to do that”), Because being a Product Owner meant that I had to manage and monitor a couple of really really really smart developers and designers, people with much more skills than I do, what I wanted them to do. No way they are going to listen to this small and simple Product Specialist, right?

And yet, here I am, “Tamara Berner — Product Owner”. And even though I still feel I have to learn a lot I can proudly say that I’m a full member of our Product team, who works together with a great group of coders, designers, and QA’s to build and improve cool features. And I’m not much of a bragger, but I cannot deny that my team expresses that they like to work with me, and our Head of Product (who deserves a lot of credit in my growth process) even shared with me that I’m a great asset of the Product team and that he loves my documentation (though the TL;DR is very much appreciated). And I think that my main asset to this is simply being involved in the process, making sure I’m aware of what’s going on, but also: talking with my team. Listen to them and make sure they feel at their best to do their job.

And yes, you might already have read that in between the lines of the last paragraph: I still feel (maybe a little less now than a year ago) that I am not there yet. I can’t overcome that sometimes I still feel stressed, especially when I have to share my opinion or make a decision. There are still quite some days that “What if [insert negative thought here]” crosses my mind. But I’m also going to be a Product Owner of my Personal Development Process and that’s just the next part I am going to learn to deal with.