Starting in a new role can be scary, but even more so when you have no previous experience. Around one year ago, I was offered my dream job as a product owner, and while I have a background in tech, I had no formal training in this field. At first, this intimidated me but I quickly found that adopting a growth mindset and taking small, practical steps forward was the best way to gain confidence. Here’s how I did this and what I learned along the way.
I’ve always found the combination of business and tech exciting, and knew early on that I wanted my career to move in this direction. During university, I joined the Junior Enterprise of the Computer Science department, and this exposed me to providing software solutions for real customers. After that, I worked as a QA Engineer for a few years. While I really liked the work I was doing, I realised that I wanted a more dynamic routine where I could participate in the decision making process of what gets built and directly create impact for customers.
After doing some research, I discovered that product was a field where I could access the dynamics I was looking for. I spent a lot of time reading up on what it would be like to work as a product owner – or manager. A few months later, a position opened up at Nmbrs, and I was made an offer to fill it, which I immediately accepted.
While this was incredibly exciting, it was also scary. The experience I had in product came mainly from books and online courses, and I suddenly found myself responsible for an API with five million requests a day, used by hundreds of partners. In particular, I struggled with not having all the answers to problems, understanding users’ experience of our product, and defining a product strategy.
What helped me overcome this was changing my mindset, and taking active steps to turn these challenges into learning opportunities.
Here’s how I approached that, and some lessons I learned along the way.
Get help from many different people
During my transition from QA Engineer to product owner (PO), I’d had a chance to do some QA work for the squad I was joining. This gave me an initial understanding of the product and, in particular, the API. However, when I started in my new role, I still felt very insecure in meetings with partners, POs and other stakeholders because I had always been able to rely on experience to unpack and understand problems, and now I was struggling to answer some of the questions people were asking me.
My role is multifaceted, and, because I was completely new to it, I knew I would have to put myself out there and ask for help from different people in different roles. Here’s who I approached and what they helped me with:
- A mentor: The PO role was still new to me, so I was assigned a mentor who had experience with product ownership at Nmbrs. She helped me understand what the role looked like, and was available to answer my questions and give advice when I needed it.
- The senior developer on our squad: My role is closely tied to what the developers on the team do, so I set up weekly sessions with our senior developer. In these sessions, I shared what I was struggling with on a technical level and he gave me advice based on his experience. Meeting with him helped me build trust both with the team and with myself.
- A career coach: Even though working with my mentor and senior developer helped me feel more confident with the practical side of my job, I still worried about not being good enough on a personal level. The career coach at our company was very helpful in reminding me of what I was good at, and to be kind to myself. We had frequent check-ins where I could verbalise my frustrations, which really unburdened me.
- Industry experts: Outside of talking to people at the company, I made sure I kept reading and researching online. I saw a post from a Head of Product offering to mentor POs who were just starting out on reddit. We spoke about everything I had been going through as a product owner, and it was a relief to hear that he had had very similar experiences at different stages of his career.
- Family and friends: Talking to the people I felt closest with at the end of every day was also an important way to grow my confidence. They were able to help me contextualise my work struggles and remember who I was, first and foremost, as a person.
From what I learned, putting yourself out there when you need help or guidance is the best thing you can do. No one ever makes progress alone, and most people are happy to support where they can. If you need help, you just have to ask!
Invest time into listening to user feedback
When I joined the squad as a fresh product owner, the company was going through a migration from Universerver to Azure. This caused a lot of disturbance in the SOAP API that our partners use. A lot of complaints were coming in, so we needed to resolve the issues fast. However, there was no clear list of who our partners were, or how they were using the API and implementing it to connect to our software, which made it hard for me to understand the problems they were facing.
To get around this, I made it my mission to get a clearer idea of who they were, how they used our product to serve shared web app customers, and what their biggest problems were when connecting to our API.
There are often many people involved, and many different ways in which each of them use the product. That’s why the simplest way I could think of to start was to talk to as many of our users as possible, and listen to their individual feedback. Here are some of the ways I did this:
Reached out to internal stakeholders
I found that it was useful to reach out to internal teams, such as the support team, who were in direct contact with our partners. This helped me get a general idea of how they perceived the API and what common challenges they ran into, which in turn gave me surface level insight into what we should be looking at.
Set up feedback sessions with our partners’ teams
Whenever there was a meeting scheduled with a partner – to do a demo, for example – I tried to make sure that there were people in the room who could give us feedback on both the technical and business side of the product. I found that this was more useful than asking for overall feedback on the API from one group who didn’t have a detailed understanding of the other’s experience because it would allow us to understand and focus on the real problems.
Investigated the problem on the ground
Using some of our meeting time to request feedback from partners was useful, but I also felt the need to go further and understand more. To do this, I decided to book 1:1 interviews with some people, and go into their workplace to see for myself how they used the Nmbrs API, and further discuss any feedback they wanted to share.
Published a survey
I published a survey to gather further quantitative input about what the partners thought of the API, and collected open inputs and NPS.
While all of these steps were important to get to know our partners, I’ve learned that understanding users and their journeys is a continuous process. Keeping this process at the forefront of my job has helped me a lot in my role because your product is only useful if it’s something that your user wants.
Work with tools and frameworks to create a clear strategy
When I joined the squad, there had been no product owner for a while, and the team was in maintenance mode, making sure that the API was up and running and that bugs were fixed. The API already existed as a product that needed to be developed and maintained, so it was easy to focus on what needed attention immediately – but it was much harder to think about a strategy for where to take it next. I didn’t have much experience with defining strategies, and while there had been discussions amongst the other product owners at the company about the API’s future, there was no clarity on what this future would look like, and how it would link into the broader company strategy.
With so many opinions and ideas flying around, it was hard to not get overwhelmed. To mitigate this, I went back to what had helped me at the start of my journey into product ownership: research. I started with more high level research, such as understanding how a strategy is developed, before talking to customers and hearing about their challenges.
Once I had data from customers, I found it useful to analyse the information and work with tools, frameworks and techniques to dig deeper into WHY certain next steps would be useful to take.
Some of the tools and frameworks my team and I experimented with included 5 WHYs, The Value Proposition Canvas, MosCOW analysis, impact mapping, user story mapping, user journey and empathy mapping. Each of these had their own specific use case, but they all helped me build a strategy that I was confident would guide my team in the right direction.
Working with these tools helped me develop a sense of structure that not only made the problem easier to understand, but also helped me get on the same page as my team. Because they provided a structured way to communicate, it made it easier for us to start “speaking the same language”.
While I have only been in this role for a year, I feel like taking steps like these have helped me grow and gain confidence. There is still so much to learn, and I’m excited to keep improving!
Gabriela is currently working as a product owner at Nmbrs. She’s passionate about the problem more so than the solution, and is always focused on generating value for her product’s users. She’s excited about keeping up-to-date with what’s going on in the industry, so she reads a lot of product books. Her other big loves in life are dogs – especially her new pup, Pipa – and summertime.
