From DEV to PO

Posted On May 6, 2020

I used to work as a tester then as a developer for about 10 years. Somehow after a while I had the feeling that every success of implementing a cool feature or finding a solution to a problem didn’t give me the satisfaction I was hoping for. Or if it did, it went away pretty fast.

I am a people person who supposedly communicates quite well. I work with emotions and can detect mood changes only by looking at the people’s faces. I like to solve problems and I am able to predict quite well how things will evolve. So why not give a try to a new role ?

I have been working now for about 1.5 years as a Proxy Product Owner / Business Analyst. The transition came with its challenges but ended up with good learning experiences.

Life as a developer

• No dress code rules ! Yaaay ! 👟
• Cool or not so cool tasks to implement, if lucky by doing pair programming.
• Stackoverflow down: Catastrophe !
• No clue why things work again: Miracles happen.
• “It works on my computer”, “But it worked before (the demo)”, “What Java version/build number do you have ?”, “Which browser did you use ?”
• Get lost in debugging, miss breakpoints and start all over again 😖.
• Ufff … merging conflicts … not funny. Quietly and elegantly swearing.
• Give a try to TDD. Fail or maybe not trying long enough ?
• Technologies are evolving so fast. No sleep allowed, otherwise updates are missed.
• Cloud is cool as long as the EC2 instances are brought down at the end of testing 💰.
• Missing the big picture and not knowing if the feature made someone happy or changed a behaviour.
• Beertrospectives are a necessity 🍻!
• Well, if the above points look negative … actually it is not that bad as it might seem like !
• Etc.

Life as a (Proxy) Product Owner / Business Analyst

• There are far more decisions to make and I feel more responsibility on my shoulders.
• 100% concentration during the meetings is required (no naps allowed anymore 😴)
• The plan for the day is done on the way to work or better a day in advance. TODO lists are everywhere.
• Different themes to tackle at the same time which often require different knowledge and distinct approaches.
  – A long analysis involving other people, meetings, dependencies, synchronisation, documentation.
  – A prototyping session which ends up with something drawn on a sheet of paper or by changing the mark-up directly on the page. After I realise I suck at drawing 🙈, I pass this to the true UX-ler of the team.
  – A long run through the logs or a long testing session trying to break the code. And I am good at breaking things.
  – Administrative tasks, meetings preparation, scrum events, ad-hoc meetings and a lot of small stuff.
• Weekly alignment sessions with the stakeholders are required.
• Backlog prioritisation/ordering happens after tracking down and collating the information from more sources. (sometimes by following my gut feeling )
• The questions from developers have priority since they have to move forward with their work.
• The tasks should be well specified and easy to understand: clear, short (if possible), with examples, following a template, put in a general context. This is something I learned with time, by getting feedback from developers and colleagues.
• Deciding if a feature brings value is again something I am still practicing.
  – Improve the “Idea -> Action -> Output” way of thinking and moving more to “Idea -> Action -> Output -> Outcome.” Does the output change a behaviour or make somebody happy ? What is actually the outcome of the feature ?
  – If I compare the effort and the number of customers affected, is it even worth to implement this feature ?
  – If there were my money, would I ask for this feature ?
  – How do I measure the outcome ? 📈
• Etc.

Finding my way

Changing a role is not really easy. I had a few tough months at the beginning.

What changed with the new role

• Far more decisions to make: should we implement the quick and dirty solution or invest more time, should we create a hotfix, keep the text or replace it, should we affect the sprint goal and introduce this story ? etc. I was continually interrupted with questions and clarifications and I was not used with that. Now, it is something normal.
• The way I had and still have to think: always look ahead at the goals of the next sprints and have a vision for what needs to be achieved in the following weeks. As a developer I didn’t have to do this. Now, it is something normal.
• Having to tell others what to do, be clear in explanations and be able to argue the decisions. Still practicing.

What were my mistakes

• I tried to know everything ASAP, to do a lot of things at the same time.
• I forgot to breathe, I put alone pressure on myself.
• I was comparing myself with my previous colleague doing the same job and being really good at that. That was a huge mistake. We are all different and do our best in our own way.

It was only when Aidan (my boss) asked me: “Why do you stress yourself ? Do you see Michael, Sandra being impatient of having the feature implemented now ?“ That was the time for me to realise I was making a mistake in the way I worked and I had to change something.

My steps to change something

STOP
I stopped what I was doing and tried to get the big picture I was always complaining I didn’t have as a developer.

• Who are the stakeholders ?
• What are the products about ?
• Which other teams are involved and we depend on ?
• Which processes should be followed ?
• Which tools are used ?
• What is the current status of the projects ?

INTROSPECT
I asked myself what motivates me at my job.

• People around are happy with my work and show me they trust my decisions.
• There is visible progress in what the team does.
• I help someone to move forward with the work by answering the questions as fast as possible.
• The team is holding together and teammates understand each other.
• I am myself able to motivate people by listening, offering advice or helping others to come to the right decision on their own.
• There is something to learn every day.

ADAPT
I changed the way I organise myself to release the unnecessary pressure.

• Sort the TODO lists for today and tomorrow in advance and have the most important themes marked (idea “stolen” from a colleague 🙊)
• Identify what urgent really means: yesterday, tomorrow or in a week is also fine ?
• Start with the most boring or annoying task and have it behind.
• Take the time to prepare and think before answering something. Not everything has to be answered NOW !
• Don’t invest a lot of time looking for a response to some question if there might already be somebody who can answer in a few minutes.

What did I learn ?

I didn’t have the experience of a product owner when I switched. But I am grateful to work in a company that supports us very well in our journey. There are very good professional trainings (Product Owner Training and Scrum Master Training) organised by my workmates, knowledge sharing groups, regular knowledge-sharing remote meetings and a lot of colleagues ready to help, share their experiences and offer advice.

My journey from DEV to PO doesn’t have anything spectacular, but it taught me a few things:

• Be myself. Never compare with anyone else when doing my work.
• Every challenge helps me grow.
• I will make mistakes and will have to deal with them.
• I shouldn’t rush when making decisions.
• Limit the WIP (work in progress) and reduce the context switch.
• Knowing the theory about product ownership is not enough.
• I do have great colleagues, I just have to reach more for help when I feel stuck.
• Step by step, I can find the way to my goal.

I think I did find my way in the end 😉.