When I grow up, I want to be a…Product Manager?

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.

Becoming a Game Developer – not that simple, after all

As a young starry-eyed country village boy going to a big city university, I dreamed of developing  worthwhile and meaningful video games that would challenge and move my audience. This was perhaps a bit naive, and I soon had to face reality – it is extremely difficult  getting into this niche development industry. In fact, finding a clear path into game development has proved elusive, not only to me, but to many of my peers.

Inspiration for action

No one seems to know what game studios want in graduates (in terms of skills and experience) or how games are developed here in New Zealand.

During my final year of uni there is a year-long Honours research project which is normally related to industry or internal work. I decided this would be a great opportunity to take the initiative in answering some of these questions, making game development the topic of my research. As a software engineer, I have been taught to value Agile principles and follow good development methodologies like Scrum and Kanban. I have been told that game development has a very different approach to process, in that much work goes into planning and pre-production. Thus, my research is geared into answering two questions:

  1. What are the methodologies that the Game Development Industry uses here in NZ.
  2. How do they perceive they align to traditional standards of professional practice.

I have been very fortunate that the pursuit of this topic has the support of the university and the School of Product design (which offers a degree in immersive game design). They are very interested in knowing how the industry works, in order to better harmonise the university’s course content with what is actually being done in the real world. I have attended various Meetups in game development and have spoken with several game studios here in Christchurch, such as Cerebral Fix and Digital Confectioners.

Curiously, they are also very interested in this research, because a whitepaper on industry practices hasn’t been done here before. Hence, the students, the university, the industry, and me personally all benefit from this research project. It is particularly encouraging for me to know that other students with an interest in gaming will be able to make more informed choices and have a clearer road map for their careers.

The three stages of research

The research itself is going to be based on three stages.

First: Question

An anonymous survey will be carried out across the industry to find out exactly what development methodologies they are actually using (versus what they think they are using). They will be asked in general terms what their various processes are for different phases of development, in the context of a client or internal project. Questions include things like, how they test, how they organise their teams, and what coding practices they use – for example. They will also be asked what development methodology they believe they are using. Using the answers from these two perspectives on the same question, I will be able to infer how closely they are following ‘standard’ software development practice. The survey will give insight into the day-to-day work that is required to develop a game in a modern studio, as well as identify commonalities and trends in studio practice.

A lot of effort has been put into the survey to ensure that it is clear and that the data drawn from it will be valid. Investigation into the game development domain itself draws out its key elements so there is meaningful thought behind the survey questions. It turns out that there are strong psychological aspects to surveys that can easily cause them to go wrong. For example, the length of the survey, the number of multiple choice and matrix questions, and the positioning of questions all have an influence on the quality of response data. Long surveys lead to low completion rates, Matrix questions often lead to ‘averaging’ behaviour, and its shown that large number of question choices puts off participants. For those interested, the following sites offer insights to these biases and survey considerations:




The survey will also be pilot tested, and I have consulted with the industry about how best to ask or frame certain questions to get the best, most accurate data.

Second: Investigate

The second part of the research involves going into the studios and interviewing the developers themselves to learn about the challenges and issues they face. This is to get a deeper understanding of day-to-day game development experience, and the reality of the difficulties. This part of the research is not independent of the first. Every studio will have its own context and problems with its projects and there may be a relationship between their issues and the degree to which they follow Agile methodologies. Of course, it’s not a given following methodologies like Scrum results in high performing studios. Agile, by its nature, is designed to be adaptable, and so adapted to whatever configuration that works best for the project at hand. But, Agile is used across the industry for a reason, and so determining whether there is a measurable detrimental effect rejecting Agile practices would nevertheless be a worthwhile inquiry to make.

Third: Analyse

This link between a game studio’s development methodology and the challenges they face flows into the third part of the research. This will involve finding potential solution candidates for the various common issues that were raised from the survey and the interviews. It is not the intent of the research to present ideal answers to the problems, nor to just bring optimisations to their processes. Rather, it’s about investigating the issues that the Kiwi studios all face, and the different strategies they have employed to address these problems. It’s quite possible that different studios have come up with novel solutions that would be beneficial for others. Thus, it’s about information sharing as much as it is about finding answers. A natural outcome of this research will be something of a snapshot of what game development is about, and, a roadmap into the game industry itself. This will hopefully give assurances to other students that are in my position.

Where to from here?

I have a busy year ahead, getting all this research completed by September. Every year, the New Zealand Game Developers Association has a conference which most of New Zealand’s game development industry attends. This year it will be hosted in late September – right when I am concluding my research report. It is intended that I will be one of the keynote speakers for this event in order to present my research findings directly to the industry. That I may have this opportunity is both exciting and humbling – and way beyond my original plans for this project. This opportunity is thanks to my supervisors, who have been quite supportive and share my enthusiasm in the success of this project.

I will keep you all posted as the project progresses.


Tim is entering his fourth and final year of his undergraduate degree in Software Engineering at University of Canterbury. While interning at Media Suite, he worked on a building a complex project management tool for an existing Media Suite partner, working through the complete concept>design>build>test phases of the project alongside senior developers, user experience experts and problem solving specialists.

The Internship: Every summer, Media Suite offers two promising developers a paid internship opportunity. Interns are embedded into one of our development teams alongside a mentor, contributing to the development of one of our products. The programme offers commercial experience, development of technical skills and a taste of what working in a professional environment is like. Internship applications open mid-2019.

The low down on React Hooks

This article assumes a basic understanding of the React APIs such as Context and Render Props. Do not worry if you do not understand some of the code examples or terms used in this article.

React has been around for more than 5 years now, and it has its pros and cons. A major pro is that developers using React will never get bored. It is constantly evolving to make building great user interfaces easier. The React Hooks API is one feature proposed to make React components cleaner, more maintainable and reusable. This article aims to improve your understanding of this API, and the problems it tries to solve.

So, what are React Hooks?

React Hooks are functions that provide access to React features you already know, in a way that really explains and collocates the logic within a component. Hooks allow developers to separate the code based on what it is doing, rather than the component’s lifecycle. Let’s look at a few examples to understand what that really means.

Let’s say we have a Component DisplayWindowWidth that displays the current window width. Here’s how we would currently go about implementing this Component (please note I will be using the class properties proposal included with CRA babel-plugin-proposal-class-properties for these examples):

Despite such a simple logic, we had to use a Class based Component (which in itself can be confusing for beginners) and use the lifecycle methods. We have to explicitly tell React when we want the event listener to be added and removed using the appropriate lifecycle methods. As the Component logic gets more and more complex, it becomes pretty hard to see the code and identify whether or not we have cleaned up the resources we were using, or used the right lifecycle method for the right purpose.

Now, let’s see how the new React Hooks API can help us achieve the same functionality.

The Component is now a simple functional component (even though it has state) and much more concise. Let’s address the two unfamiliar functions in the above code – useState & useEffect. These two functions are, in fact, two of the built-in Hooks that React provides. A full list of the available React Hooks can be found here.

useState is a function that React has provided to make a functional Component stateful. We initialise the state by passing in an initial value to the useState hook and use array de-structuring to obtain the current state and the function to mutate this state. Since these are now just function variables, we can give any name to these variables. We can also use multiple useState calls inside a Component and each call gets its isolated local state inside the Component.

Similarly, useEffect is also a function used to perform the operations that we would usually perform in lifecycle methods such as ComponentDidMount(), ComponentDidUpdate(), ComponentWillUnmount() etc. The difference is, the logic is now collocated and we have delegated the responsibility of handling creating, updating and cleaning up of resources to React. useEffect accepts a function that can be used to perform mutations, subscription and other side effects. We can also choose to return a tear down function from this that will be used for clean up, similar to what we would otherwise do inside ComponentWillUnmount lifecycle method. With the current code, the effect will run for every render. However, we can tell useEffect to perform updates only when a particular state or props field changes – or in other words perform diffing on state fields or props, we can do something like this in the below code (notice the second argument).

Now that we have encapsulated the Component logic in functions, we can do some more cleanup. We can, in fact, go ahead and pull out the entire logic to handle the state and effect into a custom Hook as shown in the following code snippet. By doing so, we have now made the logic reusable across Components. We can safely do so because (as already mentioned above) each useState call gets its isolated local state inside the Component.

So far so good. Now, let’s look at another React feature that we can use in a  Component – the Context. Don’t worry if you are not familiar with Context in React, just think of it as global variables for a Component subtree. So, say we want to apply a particular theme and a locale to a Component subtree, we can do that using the Render Prop API like so:

The example above shows a very simple Component but it manages to highlight another issue with the current API – we had to restructure our Component to leverage the Render Props API and by doing so, we have created a hierarchy that is not driven by the UI, but by the need to share data within the Component tree. As the underlying Component tree grows and/or more nested Contexts are being added, it becomes increasingly hard to understand the data flow within the Component tree.

Let’s now see how we can achieve the same functionality using one of the built-in Hooks from the new API and if you have been paying attention, you may have already guessed how we can do this (hint: useContext).

The Component as a whole starts to look much less intimidating. Not only did we get rid of the False Hierarchies, we also managed to make the code more readable and easy to understand. Additionally, useContext not only reads the value but also subscribes to the Context.

The fun with Hooks does not just end here. If you’re familiar with Redux and prefer to keep state changes predictable and declarative, you can ditch the useState Hook and use (you guessed it) useReducer hook as demonstrated here and below:

Source: https://reactjs.org/docs/hooks-reference.html#usereducer

The API provides a few more useful Hooks which we have not covered in this article.

Since Hooks are just functions, we can easily build custom Hooks composed of one or more built-in Hooks and reuse them across Components. However, there are certain restrictions or rules to use React Hooks – the two most important ones are:

  1. Hooks should not be called inside loops, conditions or nested functions (much like state in Class Components).
  2. Hooks should not be called from regular JavaScript functions. They should only be called from a React function component or from custom Hooks.

Both these rules are enforced by a ESLint plugin eslint-plugin-react-hooks.

React Hooks might seem a bit weird and confusing at first, and that is to be expected. I believe it will take some time for developers to widely adopt it. Having said that, it is also worth noting what Dan Abramov mentioned in his React conf 2018 talk – “Hooks represent the core team’s vision for the future of React”. So, Hooks can very well become the standard, and widely accepted, way of doing things the “React way” in the near future.

At Media Suite, we have not yet used this API for any of our partner projects. While this API looks exciting and we look forward to see how this is adopted by the wider community of React developers, we also believe that the benefits of using a stable API outweighs the benefits of using cutting edge or experimental technologies. Our focus is on working with our partners to get to the bottom of, and resolve their problems. Delivering cost-effective and efficient solutions is a big part of this, and we can achieve it best by leveraging established best-practices. We’re excited to see the Hooks API in action, and it is very likely to make its way into future React developments at Media Suite,

If you want to play around and experiment, React Hooks have been released as part of version 16.8 and the original proposal can be found here. The React conference 2018 presentation introducing React Hooks by Sophie Alpert and Dan Abramov can be found here. I encourage everyone to play around and have fun with this new API!


Subhra completed his undergraduate degree in Electronics in India, before coming to New Zealand to pursue his true passion for software development.  He completed a Graduate Diploma in Science (specialising in Computer Science) in 2018 at the University of Canterbury. While interning at Media Suite, he worked on a complex software project within one of our core development teams, working in React and Django. He wrote this blog as part of his internship, but (cos we like him so dang much) has recently continued to work for Media Suite in a contract capacity. 

The Internship: Every summer, Media Suite offers two promising developers a paid internship opportunity. Interns are embedded into one of our development teams alongside a mentor, contributing to the development of one of our products. The programme offers commercial experience, development of technical skills and a taste of what working in a professional environment is like. Internship applications open mid-2019.