10 things PMs should do when they start at a new company

10 things PMs should do when they start at a new company

Three months ago I joined a start-up called Remote Year as Head of Digital Product. That fancy title aside, I was coming in as the first PM on the ground and the company’s first hire to a new digital product department. Remote Year is a service based company that brings together groups of people who want to work and travel the world in the company of an awesome community. I was so excited to be joining a team that was on the crest of a wave that symbolized a new way of thinking about work and life.

Remote Year is the first company I joined where software was not the driver, but an augmenter and an enhancer. I was nervous about this, but mostly excited as I am a UX-Design-heavy PM and working with user needs is my wheelhouse. I was also excited about the opportunity to bring UX research and design thinking practices to an IRL service.

Remote Year dogfoods like no company out there. It is 100% remote with a large majority of its 100 person staff traveling with or between our programs as they criss-cross the planet. I was coming from a company that espoused a philosophy of co-location as a cornerstone of good practices, so this was unchartered territory for me. I was also coming from a big company where I had designers, engineers, data scientists on my team from day one. Then it was just me, for a while at least.

Three continents, four countries and countless Zoom calls later, I’m taking stock of what has gone down and creating a list of things I did that worked well, things that I wish I had done better, and things I really wish I had done at all, though I won’t say explicitly which is which. As a team of one, (about to become a team of two) in an entirely new environment, trip-ups were inevitable, but I hope this list will be a help to PMs who are entering into any new company, as these practices can be broadly applied to lots of different orgs.

1. Explain the broad vision of your process to all your stakeholders

Whether your company is brand new to certain methodologies or old hat at agile and UX, have a conversation with the key folks you need to work with about what it IS that you do, and what the outcomes are is incredibly helpful, as many things can be different from org to org. Present an overview of agile product management, what is comprised in discovery and framing, what activities you will do at a high level, and what the expected outcomes are.

Agile, despite being nearly 25 years old, still isn’t something that is clearly understood, and how user centered practices fit into agile is even less understood. Have an hour long conversation supported with a few slides and visuals, and get folks asking questions.

2. Make it crystal clear what you need and when

During that agile overview/education session, make it clear how much you need stakeholders to participate, either in attending Discovery activities, or in attending group debriefs to discuss the insights gathered during rounds of research. Set placeholders for them on the calendar and try to make them stick. Push for this and be explicit about its importance. I’m not saying it will happen, but be clear about why you need them there.

One of the most valuable things about the Discovery process is that it will steward a team that participates to the same destination. If you’ve done all the work alone, and not brought the team along with you in incremental steps, it’s a lot longer of a journey to get them to your page as Discovery draws to a close.

3. Make sure you do constructive stakeholder interviews

When I first joined Remote Year, I travelled to Asia, so most of the folks I needed to speak to were at least 3 time zones away, and many were 13 hours behind. This, to put it lightly, threw me for a loop and I can cop to letting this one slide, but understanding what your colleagues who are guiding the company are thinking about is really important in terms of understanding implications and opportunities for digital. I’m doing them now, and it’s actually alright that it’s a bit later. I think you can grab value from this exercise at any point.

If you need a template for a good stakeholder interview, check out the book “UX Team of One,” by Leah Buley. In fact, that book is a god-send for anyone who needs process support as they figure out a new company environment.

4. Set consistent touch-points and come hell or high water, stick to them

This one is pretty similar to #2 just on the one-on-one level. There are probably 3–5 people that you should be checking in with on a weekly or bi-weekly basis. These intimate conversations are updates that help you stay abreast of what work is going on at a granular level and vice versa. This helps create transparency on both sides and assists collaboration. This is easier when you’re in the same office, but can still be challenging regardless if schedules are busy, (which they always are.)

5. Repeat back the deliverables timeline early and often

This conversation should be easier if you’ve done #1 and laid out the big picture from the beginning, but misalignments can still happen. If you’re used to doing things with certain team members, in a certain order, with certain resources, you make assumptions about when things are going to happen.

In terms of having this conversation with your boss, start with the question, “When do you expect us to start committing code?” and work backwards from there in terms of what you need in order to make that happen. Be explicit, and do not mince words. Over promising and under delivering will feel worse than saying the hard thing.

6. Immerse yourself in the product and service

The best way to kick this off is to get a group of roles in a room and do an in-depth, 2–3 hour user journey mapping. Use this exercise to get into the real nitty gritty of each role. I don’t just map the customer journey, but Remote Year staffers as well. Map as many roles as you can, and deep dive into particulars if possible. I had a two hour session and then four additional interviews to fill in the gaps. The User Journey Map should give you as good a sense of the inner machinations of the org and service as possible.

Unfortunately, I had to wait quite a while to get the right group in the same room (and user journey mappings don’t work over Zoom,) so I started immersing myself by joining programs and participating in the service itself. Watch how things work, listen to conversations that are happening, constantly take notes, be a fly on the wall, keep your eyes open as you watch how people interact with colleagues and customers. This helps you conduct better…

7. Do user interviews

Obviously as you’re doing Discovery, you’ll be doing a lot of things, but NOTHING is EVER as important as doing user interviews for a new PM coming into a company. Once again, I point you to UX experience Team of One if you need a reminder about a script template. Create a script that allows you understand the motivations, the incentives, the challenges, frustrations, pain points and current tools of your customers. The ultimate question you’re asking yourself is “How are things happening for my customer now, and what should change first?”

Trickiest thing about an interview: it has to feel like a conversation but still collect consistent data. It’s your job to guide towards this outcome. At Remote Year our customers are whip smart people who have a lot of questions for me. I view it as a sign of respect to them and the product to get the most out of the interview by saying “we can grab a coffee after and chat through those questions, but I really want to make sure I get your thoughts on a few things and these sessions fly by.” They’ll understand that this isn’t a casual chat, but actually that I’m taking the exercise and their time seriously.

8. Synthesize, and then find ways for others to use the insights gathered

I had to make the switch from post-it synthesis to Trello board synthesis so I can share it out more easily. I have also realized that synthesis is so much better if it’s done with someone else. So if you’re hanging on your own, do your darndest to pull in some of your colleagues into the process.

If you can, pull in colleagues who will derive a lot of value from seeing organized insights from your customers. I’ve really enjoyed pulling in folks from various corners of Remote Year and bringing them into the insights conversation. I hope to do this a lot more often in the coming months.

9. Don’t beat yourself up

This happened to me a lot. Things felt like they were moving very slowly, not surprising given I was doing the job of a three person team alone. I knew that things like stakeholder interviews were slipping, I wasn’t sure when I would get people together for a user journey map. I was having trouble finding time to do the work and then communicate what the work was indicating. At times, I didn’t prep enough in advance to get stakeholders involved. I was away from home. It was tough.

But… I am also traveling the world for my job. Meeting incredible groups of new people each month, and getting to know colleagues who are some of the most wonderful people in the world. I get to go to the beach in Mexico. I say things like “I think March is going to be in Lima.” I’m also working on creating products for a company that is the first mover in a new way of working, and is blazing a trail into a way of life that is bringing joy and inspiration to its customers. When you get down, take stock, remember the good stuff, make a list, and get started again.

10. Call your PM buddies (and data scientists and devs)…a lot

When I would get stuck this is the thing that would get me unstuck the fastest. I am so lucky that I have worked with so many amazing people in the past who I can call friends, who are willing to give of their time and ears to offer perspective and advice. Reaching out for help is not admitting you don’t know, it’s admitting that a conversation will assist you in getting there. Thank you to my squad for all of the good stuff you’ve given me over the past few months and looking forward to more learnings in 2017.

Previous
Previous

Every Team in the World Should Do Retros

Next
Next

Reframing the User Research Conversation