A day in the life of an Agile Product Owner

Reading Time: 5 minutes

Outvise is devoted to sourcing tech talent, so we take pride in the functionality of our platform. We aim to make sure it’s user-friendly, easy to navigate, and provides our clients with the results they need, and fast. One of the key players behind the platform is our Agile Product Owner, Ariel Delfín. Along with the rest of the tech team, he works in his role as a Certified Scrum Product Owner to design, maintain and improve Outvise’s next-generation talent-sourcing platform. 

Ariel has over 15 years of experience working as an Agile Product Owner and a Business Analyst. Before joining us here at Outvise, he worked with a major insurance company,  Sopra Steria, eCommerce giant Mercado Libre and National Geographic. In this interview, he shares a look into a day in the life of a Product Owner, including his favourite tasks and some insight into the processes. 

1. Did you always want to work in tech or did you discover it later in life?

I’ve always loved everything about tech: hardware, software, every aspect of it. Perhaps my true enthusiasm is for hardware, especially networking and building stuff. However, I decided to dedicate myself to software because it’s broader. When I started studying IT there were two possible routes: either I went towards Product or development. Product commanded my attention a bit more and that’s where I began with Product analysis. 

I chose Product because it had more possibilities. If you look at development, it doesn’t have many variations or specific derivations other than switching coding languages, but Product has many: data, analysis, management, UX/UI, and so on. The analysis part itself has many different components (data, reports, etc.). Reporting, database, and everything related to SQL is probably the parts I’m most interested in. 

2. What does a Product Owner do all day?

Depends on each day, but, without fail, I start by grabbing a coffee. Then I either begin with daily updates or follow up meetings with development or review emails, pending tasks, depending on what was done the day before. On the Product side specifically, the regular to-do list includes meeting with stakeholders, the CTO, catching up with the development team, working on improving the platform, solving problems and providing cross-functional team support. 

In terms of managing the Product itself, the daily routine will begin with the Product Backlog, which is essentially a list of the new features, changes to existing ones, bug fixes, infrastructure changes or other tasks for the tech team. Product management will also include devising our vision for the future and new functionalities for the platform, the distribution of functions, and so on. 

3. What does Product development itself consist of?

The development process is one of the main things that a certified Scrum Product Owner will manage on a daily basis. A big part of the process is meetings, discussions and problem-solving. These may not just be about the Product itself, but also other types of requirements. Product and technology responsibilities comprise a lot of reporting, thinking of new functionalities to adopt and general functions flows. Moreover, the prioritisation of tasks and new requests is an important part of decision-making with the management team. Once we define the priorities, we start working on the Product in stages:

1. Analysis and design
2. Validation with stakeholders
3. Specification of the tasks
4. Development
5. Testing and validation
6. Release

We are usually working on several developments or tasks at the same time, but the simplified flow would be: after one task finishes, the next one starts. Normally, at the development stage, we start the validation of other requests and definition of the tasks that would go after.

A certain amount of time each day will be devoted to designing new functions; we use the Balsamiq wireframing software, which allows us to design wireframes of the modules we want to implement, whether it be email, UI, framing, or a new Product actions flow.

Once we’ve dealt with the functions, we set up internal meetings with stakeholders to check everything works and looks good. This enables stakeholders to validate the functions and align them with the company’s requirements. Once the version is approved, we proceed to the functionalities validation stage with the rest of the teams if needed (sales, operations, etc.). 

After the version is fully validated – everything works, it’s well designed, with a good user experience – we proceed to the development definition. The version is then sent to the development team, with whom we have weekly meetings in order to define the tasks they are going to be attacking. An individual User Story is created for each new functionality and grouped with other tasks in accordance with Sprint planning to make sure the development team has a precise outline of what to do and in what order. Below is a basic summary of the process:

• Design stage. This is the stage that takes the longest since the design has to be approved by all stakeholders.
• Development. We have daily updates with developers, where we follow up the weekly tasks, answer questions, solve problems in the code, etc. 
• End of development. Finally, we start testing to verify that everything is working well. Once tested, we move to the validation stage, which consists of verifying and detecting any possible issue. If there are any, it’s sent back to the development team to correct them and we test it again.

When all the tasks are finished, we move towards the culmination of weeks of work, which is the release stage.

4. Do you use any specific methodology?

We use Agile. To be more specific, we use Scrum with the development team and Kanban internally in the Product team. This encourages an iterative approach to planning and implementation, allowing the team to adapt to feedback in order to deliver to stakeholders incrementally. In Scrum, self-organising teams are responsible for managing and completing work within specified timeframes called Sprints, which I mentioned earlier. This structure helps us deliver at a sustainable pace.

5. What is the Product Owner role in Scrum? 

So in Scrum, the Product Owner is in charge of the Product vision. An Agile Product Owner needs to understand business, customer and market requirements and then prioritise, define and organise the work to be done by the development team. 

6. What’s your favourite part of the job? And what do you find most challenging?

My favourite part of this process is probably UX design and flow definitions. The other part I like a lot, even though it’s not 100% the Product Owner’s task, is reporting. 

On the challenging side, perhaps when we are creating something that needs us to define the wording and communication, like a landing page. Sometimes it’s difficult to identify for yourself if it is understandable or not for someone that doesn’t know what the Product is. It’s not complicated, but you have to try to put yourself in their shoes and forget everything you know about the Product. Essentially, this is because your knowledge is too deep; the end-user is coming in completely cold and you have to make sure that it’s user-friendly and easy to navigate.

Source an Agile Product Owner like Ariel

Ariel and the tech team are responsible for making the Outvise platform what it is – user-friendly, agile and functional. Without his team’s work, we wouldn’t be able to deliver outstanding service to our clients that enable them to connect with the best of the best in tech and TMT. Combined with our project-matching algorithm, clients can find the expert they need in as little as 48 hours.

If your company is embarking on a development project, you can build an Agile team with Outvise. With profiles from Agile Product Owner, to Python developer, Scrum master, senior technical Product Manager, UX/UI designer, and many more, an expert with all the experience relevant to your sector is just a few clicks away. Explore the platform here to identify a freelance Product Owner and many more Agile profiles.