New year, and a new product role on the horizon? At this time of year people start to look to the next year with one of two attitudes, it’s either “Right I am going to progress at doing x,y,z, bring it on!” or “That’s it, I am looking to move on”.  Usually for me it’s the former, but I am sure there will be a new day 1 at some point.  Let’s face it, we will all have quite a lot of day 1’s in our industry, either by promotion or less rewarding factors.  Product Managers have a shelf life, and change is good for the soul.  Our industry and profession is growing at a rate of knots and there are tons of blogs out there of “the first 90 days” and “what you must do when you get through the door”.  I don’t want to paraphrase or be disrespectful, but the general advice is to absorb, listen, and take it all in. Before I started my current role, I wrote a checklist of things I needed to do to hit the ground running. This is by all means not a complete list, but when fate decides I will be kicking ass somewhere else this is the blueprint I will be using.

1. Actually become a user of the product

I know it sounds dumb, but there are so many product people out there who only see the product they manage while they are at work. How can you ever change something for the better for your audience if you don’t actually use the thing as a user!  Whilst I’m at it, actually use the devices the user would use! I know this can be hard, especially if you have never used the product before, but I like to start using the product about a month before I start a job so I am clued up on the structure of the product, the UI, and already start to identify the pain points and themes. Before you start, think about what your basic expectations of the product are, and what stopped that expectation from being achieved. It takes 21 days for an action to become a habit, so don’t be surprised if at first you have to force yourself to use the product you are inheriting, if it isn’t in your usual behaviour of tools and services.

2.Do your research

Before starting a new role, I get right into comscore and start to see what the competitor set is, what the audience breakup for my new product will be, and look at the areas where there are opportunities.  Of course I will validate my assumptions with the right analytical people once my foot is in the door, but the data you can collect on your own is a great place to start.

3.Figure out where the money comes from

This doesn’t mean ignore everything else, but you need to have an open dialogue with the people who make sure the thing you do pays the bills.  As product people, we might only have one shot to produce something meaningful and collaboration is fundamental.  I used to have the mentality of  “well if I make a good product the monetisation part is sure to follow”. But if you don’t have that 360 buy in or input then you are missing out a key part of a product lifecycle. Removing development in silos means including everyone and the right times.

4.Point out faults

There is a small period of time from being new, to being part of the furniture whom becomes so institutionalised that they think their product is their baby and as such, finds it hard to see the obvious issues.  Make sure you shout about the issues you noticed right off the bat.  When you are new in an organisation, you can ask the obvious questions and people won’t think less of you.  In fact, don’t even worry about that, they will either embrace you or become a blocker and you don’t need them, the world is full of enough blockers.

5.Learn how to get stuff done, quick

There is always the tennis match of questions in what the processes are in a new job. Some places have it nailed on and can pull out all the flow diagrams or process documents to paint a crystal clear picture of order of doing things. Other places will say “depends on what you need done and who is asking” (be cautious of places like that).  Either way, you have got to know what the process is to get someone to do something. I like to start off with things that are small but require quite a few departments as part of the delivery.  Who in research can I validate we are tracking the right things with?  Who is the design sign off?  Who does the technical feasibility?  Do I need legal to be aware?  Is there a commercial opportunity?  And so on and so on.  Getting your head around where all the dots are makes joining them a lot easier, or at least you can question whoever has a level of understanding of the business.