Some time ago, an opportunity came up for me to step into the Product Owner role in a project I was working on as an engineer. As a curious person, I was excited to discover new things and without much consideration, I agreed to take on the role. It turned out to be quite the ride, and I had to rethink my approach on many things. Here are a few points I've gathered to help other engineers like me who are considering this new business-related path.
Start thinking product-first, not solution-first
This was the hardest yet most important thing I had to realise. Fortunately, I had execellent Product Owners around me who helped me with this. Above heading are the words one of my previous PO (thanks Marc!) told me. As engineers, we tend to focus too much on the implementation, forgetting that we are building it for someone else to use. On the other hand, for a Product Owner, the most important thing is if the desired functionality is delivered. Of course, quality is also important, but it is our responsibility to balance when the right time to release is. We need to start thinking about what is the least effort that can produce the maximum value, not necessarily in terms of money, but in terms of customer satisfaction.
Itt was hard in the beginning. I often found myself constantly striving for the perfect solution. However, I quickly reminded myself that the product is what's most important, not the solution. Embracing the Minimum Viable Product approach was definitely helpful. Instead of focusing on what I can add, I started asking myself what I can cut out from the proposed solution.
Write down, you won't remember everything
As a developer, you often have the luxury of focusing on one task at a time. You're assigned a task, you work on it, and then you're done. There's no need to switch contexts or worry about other things, unless a bug related to your part of the application arises. However, as a Product Owner, this is no longer the case. You need to look at the bigger picture and handle multiple responsibilities, including:
- Aligning with stakeholders to understand their needs
- Collaborating with developers to determine what can be achieved
- Working with designers to define how the product should look
- Providing updates to stakeholders on progress and agreements
All of these interactions will raise questions and concerns from various individuals involved. When can we expect it?, What about this specific corner case?, Will this feature be supported on mobile?. The truth is, your brain simply cannot remember all the details and discussions. That's why being proficient in note-taking is crucial.
Every little-thing you agreed on needs to be stored somewhere. Either only for you, so you can get back to what you agreed or for everyone to know what was been already discussed. I prefer the latter option, as even if you're not there to answer the question, others will have reference point. If you have something like Notion or Confluence it helps to create dedicated page for the product. You can store there all decisions made, all future requests and all the discussions which are being currently in progress.
This is not a place if you don't like to talk to people
Despite the fact that I'm big fan of async work, PO work requires at least some meetings. And most often you will be the person facilitating them. It is your responsibility to make sure that everyone is on the same page. No matter if it is a product demo or short discussion with engineering team, you need to feel comfortable leading meetings. It is not an easy job, but only practice can help you.
Definitely, it is easiest to conduct a meeting where you have someone you already know. Leading team meetings is the best way to build up your confidence when speaking to others. For me it was definitely helpful to play Scrum Master role in the past. Organising retros and plannings will teach you how to prepare for a meeting.
Always have an agenda, and stick to it. There are some people who like to dominate meetings, which can lead to lack of agreement at the end. It is your job to remind what the meeting goal is, and that it is the most important thing to discuss.
Write down summary after the meeting. In here it can help to develop skills from previous point. For starters it can be only for yourself, to remember what was discussed and agreed. Later, if you will feel comfortable with your notes, you can share it with the members.
Make sure, that everyone knows what is expected from them at the end of the meeting. Leave no place for own interpretation - assign action points to every person who is expected to do something.
And thing that really maters - don't be afraid! We all make mistakes, so first meetings probbably will not be the best ones. With each one of them you will gain more confidence, and find your flow. Having your own schema of meetings which you will be leading helps you to prepare for them, and makes it easier for participants to know what to expect.
Listen others needs
Why do we need product owner? To listen. They should listen stakeholders opinion. They should listen customer opinion. They should listen engineers opinion. Take all of these opinions and combine into features. It is no longer that you can come to PO and ask for clarification, description, acceptance criteria. Now it's you who have to produce all of this as an result of listening. If you will not be careful enough, it may result with either product not tested enough or not fulfilling all the stakeholders needs.
It is really important so you will ask right questions when listening. If someone is telling you to create button linking to customers CRM page, in the end it may not be the solution. Maybe it is the fact that some information is not easily available in your system? Maybe stakeholders does not know that it is already available in other place, more suitable for them based on previous feedback? These are all the things you need to get out. People tend to focus on solutions rather than problems. It is your job to find the problem, and help to produce the best solution available.
When speaking with engineers, it may also be the fact that you will not listen to them. Maybe for you it is enough to link them to slack conversation where some bug was found out. But what about edge cases? What if API will not return exactly one result? Then they will start coming to you with all the things they lack. This is also an indicator what information engineers need to do their job. You were there in the past, you know how frustrating it was when there was not enough data available. Listen, and remove as much roadblocks as possible.
Summarize all conclusions and share it with others
As I've written in first point, you need to be good at writing things down. We will not remember anything, no matter how hard we try. To make the best use out of these notes, start sharing them with others after each meeting. This will be good referencing point to which everyone can get back.
Usually, there are a lot of brainstorming sessions which we set up to discuss about the problem. Lots of ideas and questions are being said, but after the meeting it is common case to forget about it. Because of the fact, a lot of misunderstandings pops up. Engineers may think of one way, whereas stakeholders thought of something completely different. Some people thought of rectangural button, where it should be squared. You need to be translator, making sure that everyone is on the same page.
That's why it is a good practice to sum-up all the meetings. Write down action points, and assign them directly to the person responsible for them. Create definition of problematic cases, so everyone will understand it. This is an life saver. I remember the first meeting I held as an PO, when I had completely 0 notes. After the meeting people kept coming to me with questions referencing to that, where I had to get back to others to get an answers. Since then, I've tried to make best notes I can, to make everyones work easier.
Was it worth it?
Definitely! I've learned a ton how product development looks like, not only from the engineering perspective but from business as well. You can expect a lot of misunderstandings. You can expect a lot of explaning. But in the end seeing happy customer praising features you delivered is the best prize. You not only take part in the process of building an solution, you are the part of the discovery process. This shows how important for engineering are techniques like Domain-Driven Design. It helps everyone to understand each other, and keep business really close to the code.
If you're wondering if this is for you - feel free to reach out to me!
Top comments (0)