The anti-framework for new product managers

The product world doesn’t always come neatly packaged in a convenient acronym.

Angela Blake
Bootcamp

--

Lego person in a hazmat suit, looking worried.
Adapted from Photo by Mulyadi on Unsplash

Having just crossed the 6-month as a product manager, I know you’re swimming in advice on how to succeed in your new role. There are 30–60–90 day plans, frameworks, communication strategies, and a whole lot of stuff about stakeholders. Instead of another framework to memorize, I’ll share with you a few lessons I learned the hard way.

Don’t throw out the playbook

If you’re coming to product from another discipline, it’s tempting to abandon your old processes and try to “learn product.”

New gig new you, right? Wrong.

Resist that temptation. Remember that you sold yourself to your new manager on the premise that you’ve done applicable work … and have proof, or you wouldn’t have been hired. They’re counting on you to bring your existing skills to this role.

That’s not limited to your soft skills, like communication or empathy, but your processes as well. How did you identify and solve problems in your previous roles? You’re going to have the same problems in product, just packaged differently. Apply the same processes.

A method for understanding problems

When I started, my biggest struggle was that I don’t know what I don’t know. I borrowed these steps from my experience in tech support to gain context and understanding when I’m starting from scratch:

  1. Use resources: Read the stories (we use JIRA) and any linked pages or attachments; Review documentation — support articles, product demos.
  2. Get Clarification: Ask people who wrote, commented, or worked on the stories; Talk to support teams and SMEs; Review customer feedback from support tickets and logs.
  3. Try it out: Install or set up the product or feature, configure settings, and add dummy data; Record notes and screenshots or screen recordings; Confirm with others that it’s working as intended and I understand it correctly.

This process can be applied to just about anything, and I did not learn it in product. I brought it with me from a previous role.

The sweet spot is getting to a point where you constantly re-evaluate and adjust your existing processes rather than abandoning them entirely.

Build collaboration, not credibility

A lot of articles talk about earning trust and credibility for yourself on a new team, but that’s not really how teams work.

I asked my skip-level manager for advice on how to build trust with our engineers, so they would feel like I knew what I was doing. She bluntly told me they didn’t need to trust my judgment — it wasn’t my job to have all the answers. Instead, they needed to trust me to include them in decisions and check their work too.

No one catches everything. That’s why we have teams.

Thinking about trust in terms of your own credibility is a self-centered perspective, not a team-centered perspective. Even if you’re the only PM, your designers and developers are still part of your team. You have to trust them to help you, and they’ll trust you to do the same.

Questions to check your collaboration skills

  • Am I the right person for this task?
  • Do I need to get input from others before making a decision?
  • Did I openly accept and incorporate feedback?
  • Who can check my work?
  • Does anyone need me to provide input or check their work?

Get comfortable working without data

The inconvenient truth about product management is there’s never enough/accurate/usable data. That’s why you have to go through those nerve-wracking estimation questions in the interview process.

This is part of that big, scary ambiguity everyone talks about.

Substitutes for data

I’m still getting used to this too, but here are some ways you can make decisions without data.

  • Secondary research: Search for related data from other companies. What worked for similar products or solutions? What failed? This is helpful for deciding on test treatments for experiments.
  • Best practices: Look for industry-wide standards you can adopt; lean into solutions that are familiar to users. This works best for design decisions.
  • Estimation: Go for percentages rather than whole numbers so you can measure without a baseline. This works best for creating hypotheses for things you haven’t begun measuring yet.
  • Common sense: Does this really make sense? Give yourself a gut-check or get someone completely outside the problem to weigh in. Don’t underestimate the value of common sense in EVERY situation.

Being a data-driven PM is as much about identifying the need for data and planning its collection as it is about making data-based decisions.

Manage your failure anxiety

Chances are, you’re going to feel like everything you do is wrong for a long, long time. You’re going to fail while learning, and a lot of your impact will not be measurable or even visible.

If you’re anything like me, a few fails can make you freeze, and then you have to push past that inertia to get things done. It’ll get easier with practice, but you can find better ways to cope.

Trust yourself and trust the process. The wins will come.

Coping mechanisms

  • Look for low-hanging fruit: If you can get a quick win for your team, you’ll feel a lot better. Great opportunities can be found in adding to team documentation, recording a product demo, mapping out a flow or process, and just generally knocking out things no one else had time to do. Just make sure you’re still prioritizing the most important work.
  • Read through past projects: Got a project portfolio? Review and reflect on some of your best work. Remember what a badass you really are.
  • Do something creative: I love creating things, but I don’t get much opportunity to create at work. During my free time, I might redesign my website, make CSS art, or even write articles like this one. Some people like to bake, others like to knit. You do you — make time to create.
  • Share your knowledge: Learning something new all day, every day, can make you miss feeling smart. But you have an area of expertise, and you can get a quick confidence boost by sharing it. Look for social groups, forums, or communities where you can answer questions. It’s a win/win: help yourself by helping others.

I have yet to meet a PM, at any point in their career, who doesn’t have imposter syndrome. It might as well be part of the job description.

Buddy up to product support teams

For such a collaborative role, product management can feel very lonely. This is the perfect opportunity to make friends with your support teams.

They are the best source of camaraderie and good memes as well as insight on customer behavior. They’ll make your workday a lot more fun and productive, but there’s a key to communicating with support.

How to build a good relationship with support

  • Come prepared: There’s nothing more annoying to support agents than having someone ask a vague question and provide no examples or details. Do your homework first so they can help you.
  • Involve them early: Don’t wait to consult support after you’ve already done most of your planning. They can help you make better decisions from the beginning, which is more efficient than having to re-work it later.
  • Be humble: Don’t talk down to people on support teams or dismiss their ideas. Remember that they are specialized professionals, just like you. If you can’t implement something they suggest, take the time to explain why.
  • Have a sense of humor: Let your freak flag fly … in a way that’s safe for work. Make fun of yourself; make fun of your products; make fun of everything. Bring your best gifs, your best memes, and your favorite music.

I come from a support background, and I still get busy and forget to touch base with them. But when I do, it’s always the best part of my day.

Adjust your expectations of product management

By now we’ve all heard that a product manager is not really the CEO of their product, and it was good news to some of us. But not everyone knows that the role is different for each level, product, and company you work at.

Good news: You’re not the CEO! Bad news: You don’t know what you are.

Some PMs have days packed with meetings, others execute more than they strategize, and some have duties overlapping project management, product ownership, or even product design.

Chances are, you didn’t come into product management thinking it would be easy or ideal. In fact, it can be incredibly frustrating, and sometimes you might wonder what you’re even doing here. Stay flexible on your definition of the role, and you’ll thrive (or at least keep disappointment to a minimum).

PM pitfalls to watch out for

  • You don’t have as much latitude to make decisions about your own work as you thought you would.
  • You spent a lot of time reading about frameworks and strategies you’ll never use (don’t worry, you’ll use some).
  • You don’t end up liking the aspects of product management that you thought you would (there’s something for everyone).
  • You don’t get to work as much on the product or features you’re really interested in.
  • You feel like you do a disproportionate amount of legwork (chasing down dependencies and establishing requirements) instead of “fun” activities (brainstorming, wireframing, presentation).

Don’t worry if you experience any or all of these things. Remember why you wanted to be a product manager in the first place. It’s very rewarding when you focus on the parts that make you feel good about your work.

Good luck, new PM!

I’m not writing this from a place of having mastered all of these concepts or even using all of them consistently. We’re all in this together.

Keep your head up and give the new PM next to you a reassuring, virtual back pat.

--

--