Product Management for Imposters

19 Aug, 2024

by Nikko Ong

There are 3 things that a Product Manager (PM) does.

1. Find problems that affect users
2. Help team find solution that helps users
3. Help team ship solution

Most often, a PM works within a business that focuses on a technology product (software that people use). Within their main 3 areas of work, they are known for:

• Bringing clarity to the team
• Providing context for decisions

Following is a short list of ways to achieve items 1, 2, and 3:

Finding problems that affect users

For an early career PM, finding a problem (1) is done one of three ways.

1. My boss tells me (most common)
2. I find a small problem myself
3. A customer tells me about a problem

Once you have problem, validate that this is an actual problem with data from actual customer usage (either quantitative data from user telemetry or qualitative data from user studies).

Finding solutions

Finding solutions (2) is really hard. You will likely not know how to solve the problems you have. Other people know, and we need to make sure that everyone agrees on the problem and then agrees on the solution.

If you have time (optional):

• schedule 1:1 meetings with other people for them to brain dump on you about the problem
• synthesize this information (challenges, opportunities, suggestions)

Create a 1-2 page specification (“spec”) draft that includes:

• Short description of problem and solution
• Things that are not included as part of solution
• Scenarios aka short stories (should make up bulk of spec): “As a user, I can...”, or hypothetical stories about what a user will do in the app in block paragraph form. “Nikko clicks on the New Idea button. He sees the 4 options...”
• Goals to hit
• Bunch of pictures (if we try to talk in ideas only, we WILL miscommunicate). Talk about something concrete.

Some notes on writing specs:

• The spec needs to be short, otherwise no one will read it. They may not read it anyway.
• Ways to get your team to read the spec: concise, 3rd grade language, etc.
• Show to a few people to get initial feedback and incorporate

Spec Reviews

The best pre-spec reviews happen in small rooms. If you’re in a big room and have major decisions to make, you’ve already lost.

• Send spec to important people in advance, send IMs every day if they are busy, be pushy trying to meet, and stay visible about the work especially when it’s all up in the air.
• Should ONLY happen when everyone has already seen the spec. Require everyone to read through and leave comments before review.

If people have pushback:

• Remember, pushback is cheap
• Ask for suggestions and make an action item for them to find a solution

Productive output from spec review:

• Make sure that each developer has CONFIDENCE in the purpose and goal of each spec
• Enough consensus and understanding to plan out their work

Helping ship solutions (3)

Once developer work tracking items are created, the hard work is done. Take a deep breath.

Helping ship:

• Offer to test features, file bugs, do copywriting
• Prepare full end-to-end “E2E” delivery
• You wrote the initial spec, drove discussion and brought clarity to the ambiguity in the process, shepherded work to be coded AND THEN-
• You prepared a blog post, help articles, a social media release, and evangelized the feature to the rest of the company + gave lots of kudos and made everyone feel good about their work
• Keep track of your goals/metrics that you had initially set out, and celebrate the small wins and progress.

The PM Job

• Define what happens in the product
• Responsible for the “what, why, and for whom”, NOT for the “how”
• Translate customers needs into goals and features
• Make or drive decisions

PM Secret Sauce - your special weapons

• Eloquence: when you speak, you inspire confidence that “this is covered”. Speak slowly, don’t doubt yourself, and stick to your expertise (see below).
• Expertise: knowing customers inside out. Your job success is defined by satisfied customers, and you know their problems better than anyone else.
• 1:1 Meetings / small meetings:

• Figure out who prefers to do video calls, in person chats, just emails or IMs.
• Use to figure out problem space, pick brain about an issue
• Review designs within spec for feedback
• Social interaction (get people to know you and like you)
• Progress updates
• Outcome should be more clarity, so always check that everyone knows what to do next
• Set followup if necessary
• Send recap of takeaways (3 points max)

• Pictures:
• You know how complicated it is to describe complicated ideas in words. ALWAYS use pictures or visual analogies to communicate complex ideas. Use wireframes and flowcharts more readily than you would type a long message.