I always remember a song I heard as a child by Guatemalan singer Ricardo Arjona. It said (with a profanity substituted) “aquí no es bueno el que ayuda, sino el que no [molesta], acuérdese.” This translates to “here the good are not those who help, but those who don’t [bother], remember that.”
Having recently completed my first 3 months as a PM at Google, I’d say that this is good advice to keep in mind in the beginning of a new job. Instead of having a grandiose plan to make a big difference and impact, start by learning as much as you can without disturbing others.
Here are the things that I’d keep in mind as you ramp up on a new product or team.
Admit that you’re in a learning phase
As a new PM to an existing product, your focus must be in learning. Even when there is an improvement that seems obvious to you, a product idea or process tweak, you should abstain from trying to make your ‘quick win’ or contribution too hastily.
- You lack context. Your new colleagues have been working on the product area for months, maybe years. They have tried many ideas that failed, talked to many customers, and learned a lot in the process. Try to gain that context quickly.
- You have zero reputation. You can only go far if your team actually cares about what you have to say. You can quickly tarnish your reputation if you babble ideas or decisions before thoughtfully thinking through problems and considering all aspects of a problem.
So, focus on learning. How do you get started? Instead of trying to revolutionize the team’s dynamic, I suggest that you pick a small project or initiative and use that to prove yourself.
Picking up a few small initiatives
The most important thing I’ve done while ramping up on a new product or area has always been to dive in and pick up a small, non-critical project. It doesn’t matter how small or uninspiring the project might be. What matters is that it is an initiative with the various phases that a typical project will go through.
Your goal is not to amaze everyone by how well you did on this first project. Your goal is to maximize learning by getting through a full cycle of contribution. You will learn many of the quirks of working with your new team.
Going through a small initiative end-to-end will help you figure out the many tactical things that will later on make you much more productive:
- What template should you use to write product requirements?
- Who should you consult in the process?
- How do you communicate impacts to other teams?
- How do you break down your requirements into stories? Where do you file bugs?
- Will you have help from other teams (design, eng, user research, etc.)? If so, how much?
- How often do you need your manager’s input while working through the initiative?
- Do you need to get approvals or reviews by other teams? Which ones?
Going through the process will help you see gaps in knowledge that prevent you from moving a project forward. Try to maximize the number of times you go through this cycle in your first few months by picking many small, tiny initiatives and owning them. It doesn’t matter if the initiative is ultimately built or makes a big difference.
As you go through the initiatives, just remember that you’re trying to learn, so look for learning opportunities. As why things are the way they are, but don’t try to offer solutions or change things. What you’re looking for is opportunities to learn what’s effective and to tune yourself to make a bigger contribution within your team’s established processes.
Which brings me to my next point.
Tweak your habits, not your team’s process.
It is easy to look at any process and find ways to improve it. There’s a reason that’s the case, most processes just need to be ‘good enough’ to allow the team to work effectively. Constantly tweaking processes so they are ‘better’ is often more distracting than it is worth.
As such, instead of trying to change how your team does things, first accept their processes and tools and use them. Give them a genuine try and, as you do so, observe the pros and cons of sticking with them. Often I’ve seen new PMs reject a team’s way of working, just to come around months later to admit that it’s the easiest ‘quick and dirty’ way to get it done and not worth changing. Prioritizing using a simple Google Doc may feel inefficient when all your requests are in JIRA (or some other tool), but if that’s what your team does, try it out.
Unless something is an impending disaster, wait a few months before trying to change existing team tools and processes.
If and when you do try to change something, make sure it’s something that is worth trying to change. It must be a pain point that’s frequently observed and big. Also, since your change may fail, look for solution that is easily reversible if it doesn’t work out for your team.
Meeting your team
You will need a lot of help over the coming months and years from the people you are meeting now. Meet them as people. Try to learn about their personalities, what they are interested in, what they like and dislike about their job.
You will soon find yourself in meetings and discussions where decisions will be made that will impact the work your team does. You may be working with the engineering lead to decide how to distribute work among the team. Or in a meeting where an initiative is about to get killed or swapped by another one. Knowing your team will help you weigh their feelings and likes/dislikes into the process. It may not change the outcome, but it can surely help you make the process smoother for everyone and provide the right amount of context.
One thing I like to do when meeting people for the first time is to let them know that I’m here to help. “I don’t know anything right now, but if there’s something that you think I can be helpful on, just let me know.” It’s simple, recognizing that you are unlikely to be helpful, but shows your willingness to step up and assist others.
Remember, you’re a PM. You’re not the CEO of your product. You are not here to issue commands or speak of visions for the team to execute. You probably won’t be hiring or firing anyone. You’re here to collaborate with your team to come up with a direction that will make the product awesome. You should be very involved and willing to help your team’s life easier. Make it clear to them that you’re here to do that.
Ask your manager and coworkers for ‘braindumps’
When ramping up, my manager and I lovingly started to use the term ‘braindumps’ for many of our conversations or exchanges. These would be sessions in which she would give me a ton of information and context and I’d just soak it all up while asking clarifying questions. These sessions would be unstructured and we would often jump from one topic to the next.
The idea during these sessions was to surface all sorts of information that may be helpful later. Information such as:
- How does the product work?
- How does the product initiative fit within the overall product and company strategy?
- What are the known issues with a given feature?
- Why hasn’t an important issue been fixed?
- Why do these two parts of the product feel so disjointed?
- What did the team try and succeeded with? How did they start down that path?
- Who are the players involved in making your product area a success?
Keep these sessions flexible. They are best in person, but often we’d do these asynchronously by using a Google Doc. My manager would type up a bunch of thoughts about an area or topic I needed context around. We’d then discuss.
During these braindump discussions you will have many ideas, thoughts, and potential solutions. Don’t jump into looking for solutions. Remain focused on surfacing issues and tidbits of knowledge.
What you’re after is building a foundation of knowledge around the team and product. At first, all the information that you’ll gather will be in a disarray. That’s OK. You will then take time on your own to organize all this new information in a way that’s useful to you. As you do, try to explain in your own words the things that you’ve learned. Ask “why” until you’ve hit on a point that is easily understandable and actionable.
For example, consider that your note says that your product feature A has stability issues. Ask why? Is it due to a component of the system that it leverages? If so, what are your options to rewrite/substitute/improve that component? How much effort would it take? Why hasn’t it been done? Processing your notes from your braindumps, asking why, and finding the answer to those questions should take several times longer than the braindumps themselves.
The biggest benefit I find of getting ‘braindumps’ from co-workers is that they will naturally gravitate towards talking about things that are currently or were recently relevant to them and the rest of the team. This will make your learning process more focused, since you will quickly uncover the substance of the various discussions that your team has been having over the past 6-12 months, which will allow you to more easily understand what’s going on as you join team meetings and work on new initiatives. This is much more helpful than reading an internal documentation portal with information that hasn’t been updated in 3 years because no one cares about that topic any longer.
Observe your users
I could, and probably will at some point, write an entire article about the importance of getting first-hand exposure to your users. You can learn a lot from talking to your coworkers. But, ultimately, your goal is to build a product for your users. Deeply empathise with those users. Observe them. Talk to them. Find ways to watch them in action. The more you can identify with your users and understand their real goals and needs, the better of a product that you’ll be able to build.
Bringing it all together
Your first few months as a PM can be quite unsettling. You are brand new, want to make a contribution, may have a lot of relevant experience to bring to the table, yet have little to no knowledge or context about your new team and product area. There are major gaps in your understanding that will prevent you from making a large contribution. Thus, focus on learning by picking up many small initiatives, assimilating your team’s processes and tools, asking your co-workers for braindumps, digging deep into the ‘why’ behind what you’re told, and observing your users. After a few months consistently doing this you’ll be ready to take on larger initiatives and will be much more effective at helping your team.