A day in the life of a developer and product owner

I am Thijs Konst, the Product Owner of the RiskChallenger projects platform. I am also a developer and rotate in our development team. This ensures that in addition to my contact with customers, our risk managers and other stakeholders, I stay well up-to-date with the progress of the development team. ‍

‍

On a normal day, I'm mainly concerned with looking at what new things we want to add to our application and how we make sure the quality of our product is as high as possible. What is unique about RiskChallenger is that the customers who use our product are also with us internally in the form of our consultants. This allows me to get through with very short lines what is needed from the field and where we can improve our product. This also makes developing our application very pleasant because you can sit down at the lunch table to discuss things directly with the user, without having to go into a separate meeting for this.‍

‍

My motto is ‘a day without learning is a day not lived’ and my normal day as Product Owner fits in well with that:

‍

‍

09:00 - The day begins

When I arrive at the office, I plop my bag of stuff down on one of our workstations and go straight for a cup of coffee. I try to catch up with what was programmed yesterday and check my inbox to see if any client queries have come in. I usually use this time to prepare for the day's meetings or do some quick reading on a topic.

‍

‍

9:30 - First meetings

My first meeting today is to catch up with Harry (Managing Partner) about a client meeting I had with Diederik (Managing Partner) and Pim (Unit Manager Sales & Marketing) about a future feature. Harry is a very good source of information for me on risk management. By nature, I am a software developer and not a risk manager, so he has valuable insights that are not always obvious to me. I find it important to learn from other people's knowledge and experience within the field.

‍

Harry and I mainly looked at how our software can fit with the customer's needs and their current way of working. Because we develop a SaaS (Software as a Service), we have to take into account that the software we write is a positive addition for each customer, this makes for a nice challenge to support this particular customer as much as possible and to look at how our other customers can take advantage of those developments.

‍

10:30 - Progress meeting Business Unit Projects

To keep up-to-date with progress and just to catch up, I have scheduled a meeting once a week with Marieke, our Unit Manager Projects. In this meeting, we look at the backlog of issues open to our developers and discuss whether anything has stood out in the past week.

‍

We are currently working on improving how developers work, because we have grown so much in the past year that our old ways were no longer sufficient. For this, we are diving into our large list of issues that we have built up over the past few years and looking at each issue to see if it is still relevant and, perhaps more importantly, if we want to solve the issue.

‍

It is a balancing act between the time the development team has in a week and the wishes from the market. If something is a marginal improvement but takes a lot of time we have to ask whether it is worth it.

‍

This is one of the most fun meetings of my week because (by agreement) I can close a whole bunch of old issues and leave our backlog a lot cleaner than when I started.

‍

12:00 - Lunch break

At noon, I am called to lunch. I usually work for another 10 minutes because I am just focused on something.

‍

12:10 - The real lunch break

I build a sandwich and wait for a spot in the sandwich iron. During this time, I can unwind and chat with my colleagues. Sometimes we talk about developments within IT or risk management, but often it's just about small talk.

‍

13:00 - Stand-up time

Since we started implementing our new way of working, we have chosen to schedule a stand-up with the team every day. In it, we discuss progress and check that everyone still has enough to work through.

The idea is that at the end of these meetings, everyone should know what is left to do and what their responsibilities are. This is also a time to discuss whether to be blocked or wait for someone else's code.

‍

13:15 - Time for programming

This time is becoming increasingly rare in my (increasingly busy) calendar, but I still manage to develop a few more hours on a normal day.

‍

Today, I am working on our new vote app. I am building a way to send information about our risks from our ‘main’ application to the new vote app and show it to the user. We need to make sure that we as developers use the same ‘language’ across all our products, for both the frontend (user-facing) and the backend (developer-facing).

In the frontend, we do that so that users know what to expect from us and know how the application works without further training. In the backend, this is important so that developers don't have to delve into dusty documentation, but can get straight into developing new features.

‍

To ensure that our code quality remains as high as possible, we review each other's code. In my experience, this is one of the best ways to develop yourself as a developer, because you look directly at the code someone else has written and can ask questions.

‍

I process some comments on my code left by my colleagues, adjust our automated tests and push my changes.

‍

A large part of our team consists of ‘full-stack’ developers and are thus responsible for the development of our entire application. This ensures that everyone has the knowledge to tackle all issues and, where knowledge is lacking, learn from other developers and become a better developer.

‍

15:30 - Consultation with a customer

To make sure we have the right requirements for the development team, I have scheduled regular meetings with our customers.

‍

When I hear that a customer has a particular wish for a feature in our application, I look carefully at what this wish entails, whether it fits within our vision for the product and whether there is not another possibility to solve the problem. It often happens that a customer has a wish to solve a problem, without making it clear what the underlying problem is.

‍

This is one of the most fun and satisfying challenges within my remit. This is because I get to talk to this client to find out what problem can be solved and together we can figure out which solution works best for both of us.

‍

Sometimes it also happens that I use our customers' risk management expertise to find out what we need for a new feature, as is the case today. This customer currently has a process that has to be done manually and which takes up a fair amount of (precious) time. Together, we look at how our application can help ease this process or even automate it completely.

‍

17:00 - Rounding off and planning

I just finish the piece of code I was making and push my changes. I try to finish everything I had planned, but sometimes things go a little differently than expected. I check my diary to see what meetings I have scheduled for tomorrow and close my laptop, time to go home.

‍