Product Execution

Core areas of execution for a PM include:

1. Understanding the opportunities and problems (data, research, insights)

2. Defining the goal

3. Defining the plan (a.k.a. strategy)

4. Product artefacts - scoping and defining the work, writing code, testing, sales enablement, release notes, team rituals etc. All orgs and teams are different here

5. Playing your role during iterations and unblocking the team

How do you avoid creating something nobody wants?

1. You understand your target customer

2. You know which problems/opportunities to solve

3. You know how best to solve them (balancing risks to ensure it is desirable, usable, feasible and viable for your org)

Elements of execution here can look like:

• Customer research. Running interviews, surveys, usability studies etc

• Competitor analysis. Every move they make moves them ahead/behind you and vice versa

• Data analysis

Perfect execution counts for nothing if the outcome does not matter.

So spend time validating how you setup your goals, how the goals contribute to the org and how you can properly measure them.

Combining top-down direction with bottom-ups hard earned knowledge is a good balance here. 

There are multiple parts to defining a goal:

• the desired change

• the rate of change (e.g. "from x to y" or "not started to complete")

• by when 

This implies it is measurable - which is a must for any goal to be useful. KPIs are great but equally valid might be a binary outcome - complete/incomplete. Beware of output specific goals - publish 10 blog articles - a question to help strengthen this - what does publishing 10 blogs help you achieve? And then continue asking "why does this matter" and usually you can land on a KPI the org values.

If you struggle here, you can use the goal setting framework: SMART Goals. This provides a solid foundation from which you can tailor to your needs.

Prioritising all the things you could do - into the specific things you will do.

This step is much easier if the preceding steps have been done well. With a solid understanding of your Customers and Goals you can quickly assess which ideas have the strongest potential impact for the least effort.

The RICE prioritisation framework is one way to organise: Idea Prioritisation Template

The framework lists your idea catalogue with structured responses for key decision criteria:

1. How does an idea connect with strategy

2. What metric is the idea trying to change

3. How many users may this potentially reach?

4. What is your predicted change to the metric?

5. How confident are you of the prediction? You can use product discovery techniques to help gauge this

6. What is the level of effort to deliver this? Be sure to cover Engineering, Design and Product Marketing efforts

These inputs can be calculated by a model to quickly stack rank ideas. It's important to note the ranking output is not a prescription - it is a guide to support prioritisation discussions.

The framework can be used at various "levels" from opportunity themes to detailed bugs backlogs. It is a tool to help structure thinking and connect ideas with goals. 

You can rule out ideas where:

1. you don't know enough (yet), 

2. it doesn't connect to the current goal (save for later) or 

3. requires too much effort for too little potential reward (you should reassess these and breakdown the problem/solution spaces).

Present the prioritised ideas in a roadmap - which is simply your intended sequence to tackle the ideas. You can include delivery dates - but this can lead to a focus on "delivering output" over "delivering results". Remember - success is not shipping something people do not want.

Part of the PM role is about creating docs. 

• The analysis: lots of spreadsheets!

• The plans: roadmaps, strategy docs, vision statements, sprint plans, updates, retro notes etc.

• The details: Briefs, specs, test plans, sales enablement content

• The results: showcases, release notes, impact reviews

In addition, you might also have people development artefacts - typically provided by your org (unless you're tasked with developing them yourself).

My view is Product Managers tend to have the widest perspective amongst the product team.

This tends to manifest from two things:

1. The natural desire to solve problems. PMs tend to lean into the unknown, learn it and connect the dots back to the team. As a PM expands knowledge and connection across an org, they will tend to be "pulled" wider across the org. Beware it's on you to own your time - but in general, seek, encourage and embrace this. The wider the perspective, the better the understanding of the business.

2. Someone has to do the things nobody wants to do. Engineering and Design roles are usually well defined. It's not uncommon for anything that falls outside their scope to land with the PM. This is a double edged sword as it's pretty easy to be sucked into busy work.

At the end of the day, when progress gets blocked - the team needs to work out how to get unstuck. Not every problem should or will fall on the PM but our natural curiosity, wide relationships across the org and strong problem solving skills generally combine to make the PM a key player in unblocking a team. Remember… just because you can, doesn't mean you always should.