Menu iconMenu

When I was a kid, all I wanted to be was a builder. In fact, I was so driven by this goal that I wasn’t going to let something trivial like school get in the way. Coming home from my first day of school, I tried to convince Mum that “I know maths now so, I don’t need to go back.”

Fast forward 35 years, and I’ve finally achieved my goal… well, sort of. I don’t build buildings (of course), but I do work with a very talented and fun team at Media Suite. We aim to Build The Right Thing.

I’m not a builder, I’m a Product Manager.

When I tell people what I do, the reaction I get from most people is confusion. If I told them I was a builder, they’d probably know what that was. In fact, such is the confusion, if I’m ever asked what I do in passing, I usually say “I work in IT”. This is most commonly received with knowing nods, and no further questions – as if this conjured up a crystal clear image that left no detail in doubt. Either that, or they don’t want a sermon on software development.

So, what is a Product Manager?


Well, this is a question of the ages. I’ve worked with, talked with, and listened to many a Product Manager, and the universal truth is that no two roles are the same. The inconsistency in role requirements stems from what we’re here to do – make the best decisions for products. If we’re doing our jobs right, they’ll end up more valuable for product clients, product users, and Media Suite.

This to me is why defining Product Manager proves so difficult. Clients, and their domains, company size, processes, challenges, drivers, and constraints, are all different. There are likely infinite permutations of these (and other attributes) forming who they are. All of these attributes can also change with time. Layer all this on top of any business, and you’ll find another layer of changeable complexity there too. Now, you begin to appreciate the context within which Product Managers work.

Given this context, and the uncertainty it brings with it, it follows that a prescribed approach to how you work and what you focus on simply can’t be applied universally.

So, where do you start?

Well, I can only really tell you where I started some nine months ago. I’m privileged to have begun my role as a Product Manager in a company that knows product management is about context and people. Way back then, they recognised that I have the skills to navigate my way towards making the best decisions on the what, the how, and the when. They have since have put their trust in me to do so.

Here are a few of the things I’ve done.

I got to know the Product

The context: I was taking on the management of an existing product, already live in production and being used by some major government regulatory agencies. I didn’t know anything about the product and I didn’t know the domain –  a position somewhat unusual for me, having worked in the health sector for a decade (and all the familiarity that brings). There is, however, something unique about landing in the unfamiliar, being able to bring a fresh perspective and ask questions, without the influence of history or context that can introduce constraints.

So even before I started at Media Suite, I got myself a product account and began navigating my way through it. I took notes on its look and feel and how intuitive it was for a naive user. I wrote a list – primarily made up of  ‘why?’ questions.

I have since found myself referring back to my early notes and questions, reminding me of that first user experience and the questions I had – and to remind myself to keep questioning. Many of my questions have long been answered as my domain knowledge has grown, but others have helped me to challenge the status quo and look at new ways to increase value for clients, users, and Media Suite.

I got to know the domain and its people

Day 4 on the job and I was on a plane to Australia with Managing Director George. We were heading off to demo the product for a potential new client, testing whether our New Zealand product would work in the Australian market. I was light years from being an expert in the product or the domain – so how did I approach this?

Knowing George had lived and breathed the product since its inception and clearly didn’t expect me to pretend to be an expert, I seized this as an opportunity to learn about the domain and its people. I spent the day meeting with folk from different business units, and  trying to understand their world. I was up front that I knew nothing, which seemed to give them the freedom and confidence to open up to me about their needs and challenges.

They wanted to be heard, and I listened.

Rather than frantically scribbling or typing notes and missing half of what was being said, I asked permission to record the audio with my phone. This allowed me to engage fully with each person speaking – actually connecting with them and forming a trust that better helped me understand their world.

I found this experience hugely rewarding and informative, and continue to use this approach each time I go out to speak with users or potential clients. I make this a priority. For me, it’s more than just understanding, it’s about forming trust. With this trust we can work better together, better identify solutions or opportunities, and enjoy the time we spend doing so.

I got to know the team and the technology

In the IT world there seems to be two distinct camps – the technical and the non-technical. I don’t subscribe to this binary perspective but, if you were to classify me this way, I’m one of the non-technical. Some consider this a weakness, insisting the best Product Managers come from the technical camp.

I see it as a strength.

In my IT career it’s meant that I’ve had to embrace my ignorance. I’ve had to get to know the developers, architects, testers, dev-ops, and support personnel. I’ve had to understand their roles, their strengths, their interests, and their ambitions, and the technologies they use. This has helped me to learn that leveraging the strengths of others beats trying to know and do everything yourself.

At Media Suite, getting to know the team felt effortless. Our company values are clear and lived daily, so I already knew we had these in common before I accepted the role. This culture brings with it a mutual respect and trust, and has meant for me, that communication has always been easy and open. I appreciate this is not always the case, having experienced distrustful (and even hostile) workplace cultures that are destructive.

Our constructive culture means the team members support each other. The technical camp helped me understand their technology, approaches, constraints, and ideas. In the non-technical camp I bring the voice of the business, the client and the user to the table, providing the pieces of the puzzle that add context and meaning to the technical work.

I’m working closely with the team to build a vision, strategy, and roadmap

My view is that we can all benefit from having a North Star – something we can keep referring to keep us on the best path. I think this applies as well to life as it does to business.

My first step in establishing a vision for our product was understanding where it fits within Media Suite’s company vision. Fortunately, we had a series of company-wide workshops that crystallised this.

My second step confirmed a strategy and roadmap to achieve that vision. I set up a series of workshops spaced out over several weeks that included all members of the team. It was important to me that we worked on each step of this journey as a team to ensure we’ve all had a voice, and the opportunity for debate when we’re not aligned.

In fact, it’s actually getting aligned that’s fundamental here. It doesn’t take a team to define a vision and create a strategy and roadmap, but it sure as hell takes a team to deliver on it effectively.

This process has resulted in us each knowing what we plan to do as a team, why we’re planning on doing it, how it brings value to our clients, users and business, how it contributes to our product vision, and how this contributes to the company vision. This connects our day-to-day operations with the big hairy audacious Media Suite North Star, giving us purpose even in the little things we do each day.

Where am I now?

We have a product vision, a well-aligned team, and a passion for reaching that North Star.

I’ve still got a lot to do though. The sales pipeline of new clients is growing, and with it new solutions and opportunities to pursue. In parallel, the roadmap ‘Epics’ need to be elaborated on to create a backlog of ‘Stories’. Building those stories help us reach our North Star while also considering new opportunities that present themselves. One thing is certain – with client and user needs always changing, along with advances in technology, this work will be ongoing.

My journey to date as a Product Manager has been a steep learning curve that I’ve found fun and fulfilling. I’ve already learned so much about the domain, business, and technology, but there still remains a world of knowledge that is unexplored.

If there’s one stand out lesson from my time as a Product Manager, it’s that clients, users, and team members, regardless of domain, technology, or business, are all people with needs. It’s our role to be there, listen, and understand those needs. When we really listen, that’s when we can deliver true value and benefit.

Valuing your team means valuing their retirement

Media Suite recently incentivised the team to contribute a little more to their retirement. Commercial Manager Abi explains why SMEs should be supporting KiwiSaver for staff, not sabotaging it.
Abi Posted by Abi on 27 April, 2018

How we Slack at Media Suite

We use Slack a lot at Media Suite. Like A LOT. In this post, Steve explains how we leverage Slack to improve communication, keep everyone fed and even have a bit of fun. :thumbsup:
Steve Posted by Steve on 22 November, 2017

The Case for Professional Doodles

James puts pen to paper (and fingers to keyboard) to talk about drawing in the workplace.
James P Posted by James on 6 April, 2018
Comments Comments
Add comment

Leave a Reply

Your email address will not be published.