My Experience As A Non-Tech Product Owner
20 April 2017 |
About a 4 minute read
Every time we get a new batch of joiners they go through a four week Bootcamp to help them understand the areas of our business and become prepared for working on a client site as a unit. For our recent Bootcamp in February I had the opportunity to act as Product Owner (PO) for one of our bespoke applications at AND Digital and develop a new product from scratch. Coming from a non-techical background, I thought this would be a great way to challenge myself, to learn about what is going on at “the back-end” and to test our Agile practices with a new Scrum Team.
The goal was to develop an online catalogue for the AND Digital Academy to make our offering available to our “ANDis” as well as to our clients (and in the future to also book courses through this site!).
It was a great experience as I had also taken on this role for the first time. What I gained was a better understanding of the importance of visualisation, how hard it is to stick to Agile principles and YES, I learnt about the tech stack!
But it wasn’t all plain sailing! To start a new product from scratch with a newly formed team brought along interesting challenges. This is what I had to tell myself during our first sprint:
- You can’t have it all! The Scrum team had a pretty hard job of managing my expectations in terms of product and release date. I found it difficult to imagine what an MVP (Minimal Viable Product) looks like as nearly ALL functionalities seemed to be really important.
- Learning how to visualise the ideas instead of expecting my team to be able to “mind read”. I was designing a new product from scratch and I started off with some cryptic drawings on a flipchart – still, better than nothing, and the Product Analysts actually used them to create the wireframes!
- Being agile – being flexible! “Being agile” – It sounds great, but dealing with scenarios that constantly change is yet a skill that I need to master. Even within a short sprint of only one week, the business requirements changed and we quickly had to re-assess and re-prioritise whatever was in the backlog, which can be a bit frustrating at times.
- Don’t bring in too much and don’t break the Scrum goal! It was sometimes tempting to pull more in as the team seemed to get on really well; and I gave into the temptation. This did work until we pulled it too much – and we ended up not achieving the sprint goal.
- Tech Stack – What was most helpful, were the discussions with the Product Developers of the team, understanding interdependencies and asking how much effort is needed in the back-end (e.g. having a “perfect” button on a website is probably not worth spending a fifth of their time…so I got a “not-so-perfect” button – it works and that is what counts!).
- Make time – being a PO is a time consuming role (not necessarily being physically present, but THINKING about so many details that haven’t even crossed your mind). Also, the team needs sign-off pretty quickly, especially when you have a short sprint of one week and this can become a blocker. Ultimately, it works like this: the more you invest, the more you get out.
- It’s OK to say “I don’t know”. In the beginning I thought that as a PO I would need to be able to answer all questions from the development team. To be honest, I couldn’t keep this up for very long! The team was challenging me with technical questions and raised points from a user experience perspective I hadn’t even thought of. As I couldn’t give them what they need, this only left me with one option: To find it out from other people!
My top tips for your first go at being a PO:
- Develop a vision board (e.g. http://www.romanpichler.com/tools/vision-board/) and share it with your team to create transparency and set clear goals.
- Establish a relationship with your team and clarify your expectations (specifically with the Scrum Master).
- Make yourself available for key sprint events so you don’t become a blocker for the team.
- Accept and embrace change even if this means scrapping everything you thought you wanted.
- Ask questions about the Tech, processes and jargon you don’t understand – Ask your development team, ask other POs, ask the Product Developers, ask the Product Analysts, ask everyone who can help achieve your vision.
Being a PO was a hugely valuable experience, which I would highly recommend. On a personal level, it was very important for me to keep the team motivated and morale high – knowing that I had set very high expectations in a short time-frame. I tried to support the team by providing lots of constructive feedback and reinforcement rather than trying to “correct” things. The result was that the team really surprised me – and what was even better, was they also surprised themselves with what they are capable of.
React Native Engineer (London)
Champion software quality and technical vision for AND and our clients, work on large-scale projects and help junior and mid developers grow in their roles.
Technologies you will be using
Tech Lead (Reading)
Bring your expert tech knowledge to the table to influence the direction of projects, whilst coaching and your team through engineering best practices.I'm Interested
DevOps Lead (Reading)
Bring your delivery expertise to the table, leading the pack as ambassador on operational requirements, influencing and continuous development.I'm Interested