News and blog

My 8 steps to beating ‘new Product Owner’ impostor syndrome… almost

For over a decade now, my career has focused around understanding what customers are trying to achieve, and working with development teams to produce products and tools that make achieving these things easier for customers. That’s nearly a third of my life. And yet in spite of this, that nagging feeling that maybe I’m just a fraud with no clue what I’m doing is never very far away – particularly in the first month of a new job.

People refer to a learning curve, but to me, the first few weeks as a Product Owner in a new role are more of a learning yoyo. I’ve had really great ‘yes! I’m actually starting to understand this’ days, followed by ‘wow, I really don’t have a clue’ days. I’m not sure whether it’s just because I happen to sit next to a developer with an impressive talent for solving Rubik’s cubes that the analogy occurred to me, but sometimes process feels like you’ve just made one face of the cube fall into place only to discover a gaping hole in your knowledge that shunts all the cubes out of alignment once again.

However, as I go through the process of figuring out the day job here at Ocado Technology, I’m starting to develop a process to try and fend off the impostor syndrome and feel like I’m actually getting somewhere.

Step 1: Get to know the team. Individually.

With a grateful nod to Ken Norton, I started this role by meeting each person in my team for a half hour catch up. I wanted to find out exactly what they did, what they liked or disliked about it, and what they felt I could do to help them. Essentially, I wanted to find out what motivates them, and how they thought I could add value. I’ve found this is a great way to get a head-start working with the team, both in terms of knowing who’s best to ask questions about process, systems, users etc, but also who’s interested in getting stakeholder feedback, who’s motivated by solving complex technical challenges and who wants to drive process and make things more efficient.

The team as a whole will have its own characteristics, but I’ve found that spending time with everyone individually is a better way to learn about them than judging by what happens in group meetings and catch-ups.

Step 2: Start learning the language.

In every meeting I’ve been to, I’ve made a note of any three letter acronyms or jargon I don’t understand, so I can ask what they mean as quickly as possible – if not immediately, then at the end of the meeting. I find that the longer you’ve worked somewhere, the harder it is to ask these questions (“what, you don’t know what the XZT is?!”), so getting them out of the way early helps to make each subsequent conversation that much easier as you start to learn the language of your new organisation.

Step 3: Read absolutely everything, even if it makes little sense.

Part of this language learning process for me is to read everything I can get my hands on. Intranets, blogs, support tickets, technical notes on Slack, guides on our wiki – I read anything and everything. I’ve found that it doesn’t really matter at this point whether a huge amount of it goes over my head. Gradually, the terms seep in and the new information finds hooks to connect itself to other key pieces I learn along the way, until steadily I start to form a clear picture of how everything fits together. In fact, doing this enabled me to help solve a technical support ticket because I could spot a link between two pieces of information I’d read in two different places. I didn’t know what to do with the information I’d found exactly, but it certainly felt good to point out the link to the development team and have something useful to contribute!

Interestingly, almost everyone I spoke to in my first week or two in this role was concerned about overloading me with information. Personally, I haven’t found this to be a problem – mainly because those first few weeks can be daunting, with lots of hours to fill but not enough knowledge to truly do the job yet. Having stuff to read, notes to review, sites to peruse and meetings to attend helped me to stay busy and feel like I was doing something to get up to speed.

Step 4: Find the people who can help

Among all the info download, there have been some key meetings with people that have helped me along the way. By spending time with more technically-minded people in the the business, I’ve found out (at least from a very high level perspective) how the many systems my team work on are connected, and also how the deployment process works. This last one was important in order to make sense of stand-up and other status meetings. I’ve also met with other Product Owners from across the business, which is a great way to find out more about the various products the company works with, and also to find out who I’m likely to need to talk to for any cross-team development.

Step 5: Find a way to remember what you learn along the way

Each time I have meetings like the above, I’ve asked the person to draw a diagram (or take me through any visuals they have already) to explain how things fit together, and what their own part is in that. I remember things more easily if I’ve seen a diagram, and a quick photo of a whiteboard is a much simpler reminder than pages of notes. That said, I do make the pages of notes too, by hand, in a notebook. Buying that notebook for a new job is a bit of a ritual for me – it becomes my bible of everything I learn in the first few months, so often I keep it for a long time. My purple Moleskin notebook is my security blanket for this new job, and I clutch it for every meeting.

Step 6: Find the people you need to help

Another crucial meeting was with my line manager, pinning down as complete a list of my stakeholders as possible. Obviously this is helpful because meeting all of these people is crucial, so I can introduce myself and start building relationships. But it also helps me to start thinking in terms of priorities. If the feature request hasn’t come from one of my key stakeholders, what value will it deliver for them? Are they aware of the request? Should they be? Similarly, it stops any awkward conversations later down the line when I run into a key stakeholder and realise I really should have introduced myself to them in week one, rather than month six.

Step 7: Find out where to get user feedback

In every other role I’ve had before, meeting the users and getting their feedback was a hurdle that had to be overcome. Happily, that’s not a problem here at Ocado Technology. The systems my team work on are used by staff – mainly our delivery customer service team. The delivery centre is a short walk from the office, so I can meet our users and ask for their feedback whenever I need it. That can be a double-edged sword, as with a small development team, there is much, much more that the delivery team would like to have than we could ever build. This means that I have to be careful and specific when asking for product feedback, to avoid disappointing lots of people with great ideas that I won’t be able to prioritise any time soon. However, I’m hoping that by becoming a regular visitor to the delivery team, I can build trust that the specific feedback I ask them for will be acted on, and that more general opinions and improvements are definitely still welcome and worth voicing – I just can’t work miracles.

Personally I’d rather be honest about whether something will be built in the foreseeable future or not, rather than just adding it to the backlog. Having a conversation about why not everything is feasible right now, and why the things we’re working on now have been prioritised, will help to build a more open relationship between the development and delivery teams.

Step 8: Say ‘yes’ to every training opportunity

Another great benefit of working here is the enormous amount of formal training that’s on offer, delivered both by staff and hosted externally. This has been particularly useful to me in terms of quickly understanding the company culture and processes. Wondering what goes on at a delivery ‘spoke’? Rent a car, find some colleagues and go for a visit. Want to know why the team find Kanban is the best approach for them? Go to the Kanban training, hosted by a member of my team. Want to bounce ideas off someone about ways of working? Join a Slack channel, ask a ‘Catalyst’ (similar to an Agile Coach in other organisations), go to an Academy session or put your name up on the Learning Cafe wall to find someone else who’s interested in the same thing. For someone in their first month (or at any time), that culture of ‘just ask’ and a mixture of ways to learn, is incredibly valuable.

So, here I am, almost at the end of month three. It’s pretty telling that I must be getting my teeth into the day job as I started this blog in my first month, but it’s taken me another two months to finish it. In the intervening time I’ve certainly continued to find out just how much there is that I don’t know, but crucially, the tidal wave of ‘how on earth did I get this job – I definitely don’t have the skills for this’ feelings have been avoided, because I’ve found channels, resources, and most importantly, people, who can help me to find out.

As a strategy for starting a new job as a product owner, I definitely find these eight steps are a good foundation, but I’d love to hear ideas on how to improve the process. What tips do you have for overcoming imposter syndrome and settling into a new role?