What I’ve learnt (so far) as a Product Manager

That’s it! I’ve learnt.

No process

Be warned there aren’t any nuggets on how big the agile team should be or advice on if you need one and a half user researchers on Mondays or if you should work in sprints of 11 days. There’s plenty of good stuff out there already.

But

What I have learnt over the last few years working on Agile projects and Digital Transformation is the encouragement to learn, and the importance of continuously learning. For me this is at the heart of the culture and why it is so positive and transformational. And yes, continuously learning from users is key to that.

The TEAM — the most valuable asset!

Understanding users, user research/observing/testing is part of this. Pulling together a strong team and using their combined wisdom to develop products based on learning and sharing ideas. Bringing in the business, the communications experts and policy leads. Sharing through show and tells, retrospectives, stand ups, story development, testing…. . This leads to a really positive team and energy. And why is it that the team is so good — because it’s full of people that want to learn as well.

The not so good way

Compare this to a few years ago. The culture (still prevalent in places) was for everyone to pretend that they were expects. Job descriptions based on qualifications for process experts. Documents to show processes were applied. Everything nicely controlled. Registers to show risks had been thought about before a board meeting. Requirements and direction set by the most dominant stakeholders. And needs/requirements being static, a bit of learning about users at the beginning but then locked down whilst everything around changed.

What did we learn from the ‘not so good way’

The previous approaches also had learning bolted onto the end. Remember the lessons learnt report at project closure! I spent days writing one — and then it dawned on me that no one would ever read it. My learning was that most processes in non infrastructure projects doesn’t add much value. Some people will say that there should have been a meeting as well but the point is that good learning is done every day in Agile. It’s not a process at the end!

More Learning

One of the best things about the last few years is that I haven’t had to pretend to be an expert so have less fear. This is especially important in a big organisation where the culture is normally to prefer process and the perception of control. So Agile has allowed me to become more comfortable with my own lack of knowledge. That has made me far more receptive to learning, and as the team have succeeded I’ve appreciated the views and contributions of everyone else even more as they have repaid my trust in bucketloads.

Almost Failing

I did come close to failing at the start. I remember a really tough planning session early on when I was distracted by numerous emails demanding compliance with process. Then the big question from the business analyst — what was my view? There were eyes on me, the developers had eaten too much sugar and wanted to code. Gulp, buy time…could you repeat the question please. So a turning point for me was to say that I didn’t know. Instead I tentatively asked if we should “find out the user needs”? This was met with silence, no one laughed, rolled their eyes or threw anything at me. Instead the team nodded, I was offered a doughnut, I loosened my tie — I relaxed and started to realise that under this new approach I didn’t have to pretend to be an expert and could start to be me a bit more trusting. Over the coming months the team flourished and our delivery has gone from strength to strength.

Don’t get Carried Away

We all need to force ourselves to listen more and recognise that there’s lots more to learn. I’ve only started to use social media in the last year as I prejudged it before — so am only now realising how beneficial it is. So my stubbornness has meant that I’ve missed out on loads of good information in recent years. But I’ve learnt now and will try harder to listen, avoid pre-judging, not assume and to keep seeking out more information and knowledge. The team also helps as the user researchers, content lead, designer, business analyst, technical lead, developers, web ops, testers, delivery manager along with all of the users, present arguments and evidence daily to keep me in line.

Lastly

Sometimes we make it up as we go along. This is given different names about failing fast etc. But this is part of the learning process. As we make it up from what is already known it’s not as bad as it sounds and will never pretend that it’s finished — as the team develop.