Hi Reader,

Let me guess: you probably underestimate how much impact you actually bring.

Or you know that you bring it, but you never seem to be able to make it sound impactful.

I get it. Internal products are tough.

There are a few steps you can take to go from "created roadmap, built a feature" to "generated X in savings." The kind that makes your impact undeniable.

Read on :)

Today in 10 minutes you will:

• What a weak self-assessment looks like (and why it fails)
• The impact framework I have used for 2 years
• How to find the value even when "you can’t measure it"
• 4 examples you can copy

Why I am writing about this

I am writing about this because I have actually struggled with self-evaluation of my own performance.

There was a year where I did a lot of work. I went beyond my scope, wearing multiple hats, from the actual PM work to taking on engineering, testing, and anything in between.

But when I put that on a self-assessment, it looked like just a long list of tasks.

My justification was that my product was still in MVP. It didn’t create much value yet, and we had to do a lot of doing before we got to the earning.

And it’s not to say that’s not true. You do have to do a lot of doing.

But it’s a lot about how you communicate it.

I was delivering big impact, bringing a product to life that didn’t exist in the industry. And I was selling myself short by writing a list of to-dos.

Surprisingly, the thing that changed my mindset was LinkedIn.

For all its obnoxiousness sometimes, I realized that PMs and PM leaders in B2B and B2C also struggle with framing their impact.

And I thought: if they struggle and can get out of it, where impact is much more straightforward than where I work, then I can do it too.

And here we are.

I have been improving this for about 2 years now. Not to say it is perfect, but it can definitely point you in the right direction.

​
What traditional self-evaluation looks like for internal PMs

Before we get into the framework, let me show you what an average self-assessment looks like.

Let’s say you own a Sales CRM.

It usually reads something like this:

All true. All real work.

But it’s a laundry list of responsibilities, not a story of achievements. And it says nothing about why any of it mattered.

The impact framework

The framework I use is nothing fancy. I’m sure you’ve seen some version of it before.

But first, one thing that happens way before the self-assessment: setting the goal.

This is where I use SMART, at the start of the year or whenever a new goal comes up. The part that matters most for us is relevance: tying your product goals to what the organization actually cares about.

Because here’s the hard truth: if you’re doing work the org doesn’t care about, it won’t be evaluated highly, no matter how well you did it.

So SMART is the front end. It points you at the right work.

Then, at review time, you need a way to write that work up. That’s where the other two come in:

→ the Google XYZ formula (great for the result and the storytelling)

→ the CAR method: Context, Action, Result

Here’s the difference between a review and a resume: a resume can stop at the result. A review can’t. It needs the Context so people understand the situation, and your Actions to show how you contributed, not just what the team shipped. So I bolt the C and the actions from CAR onto the XYZ result.

Here is what it looks like:

Relevance (organization goal):Start by naming the org goal your work served. Then: achieve X, measured by Y, by doing Z (the Google part), within the context C and a timeframe, plus the specific actions that underline your unique skills (the CAR part).

A good example:

See the difference?

The first part (the org goal, then X, Y, Z and the context) gives you the result.

The last line is where you show up. That’s the part a laundry list always leaves out, and the part that actually wins you the review.

How I find the value (without making it up)

The most common pushback I get is: "But I can’t measure my work."

For a long time I believed that too. Then I realized I was asking the wrong question.

The question isn’t "is this quantifiable?" Almost everything is, if you pick the right method.

The real questions are: which method fits, and who needs to co-sign the number so it isn’t just me inventing it.

Here are the methods I reach for:

1. You already have the data → measure it directly

Revenue, ticket volume, hours logged, adoption. If the number exists, use it. Then get finance or the business to confirm you’re reading it right.

2. No clean metric → put a cost on the time

This is the one I use most. If there’s no ready-made number, look at the time involved and multiply it by what that time costs. Hours saved, or hours wasted, times a loaded hourly rate. I used exactly this to put a number on a slow feature once: [X] users, losing [Y] minutes a day, times their hourly cost. Add it up across a year and suddenly “the feature is a bit slow” becomes a real figure. It’s rough, but it’s defensible. And that’s the whole point.

3. Risk or compliance → cost avoidance

This is the “what if it went wrong” method. You’re not saving money, you’re avoiding losing it. For security or internal compliance, I don’t guess. I go to the expert and ask: what would an incident here actually cost us? Their estimate becomes the number, and they co-sign it.

4. Soft outcomes → use a stand-in metric

This is the part that confused me for ages. Quality, satisfaction, fewer incidents. They feel unquantifiable, but they’re not. You measure a stand-in:

→ Quality → defect rate, rework hours, escaped bugs

→ Team health → retention, time-to-onboard a new dev

→ Satisfaction → CSAT or a simple before-and-after survey

5. No internal number at all → borrow a benchmark

When you have nothing to go on, use a credible external figure (industry cost of downtime, average cost of a breach) and say clearly that’s what you’re doing.

And then there’s the small set of things that genuinely resist numbers: reputation, morale, strategic positioning.

Don’t force a fake number on those. Use evidence instead: a direct quote from a stakeholder, a clear before-and-after, the name of the person who felt the difference.

A VP saying "this saved my quarter" beats a number you made up.

Three rules to keep it honest:

→ Co-sign every number with whoever owns it. Finance for money, security for risk, the business for the outcome. Their sign-off is what turns your estimate into a fact.

→ Be conservative. Under-claim a little. One inflated number poisons the whole review.

→ Write your assumptions next to the number. If people can see how you got there, they’ll trust it. If it looks like magic, they won’t.

The point was never a perfect number.

It’s a number you can defend.

4 examples you can copy

Same framework every time: org goal, result, context, then the actions where you show up. The numbers are placeholders, drop in your real ones.

1. You built a new feature

Org goal: "Supporting [team]’s efficiency target for the year."

Result: "I shipped [feature] that cut [task] from [X] to [Y], saving the team roughly [Z] hours a week, measured by [ticket volume / time tracking]."

Context: "[Team] was doing this manually and it was the top complaint in [quarter]."

Actions: "I ran the discovery interviews, prioritized it on the roadmap, wrote the spec, and validated the result with the users after release."

2. You upgraded security

Org goal: "Protecting the company against the risk flagged in our last audit."

Result: "I led a security upgrade on [system], reducing the company’s exposure to a breach. Working with our security team, we estimated the avoided risk at [X], based on [benchmark]."

Context: "The system was running on [outdated component] and flagged in our last audit."

Actions: "I scoped the gap with security, prioritized the fixes by risk, coordinated the rollout with engineering, and got sign-off from the security lead."

3. You are building an MVP that’s not ready

Org goal: "De-risking a [Y] investment leadership was about to commit."

Result: "I built and validated an MVP for [product] with [X] early users, de-risking a [Y] investment before full build, measured by [adoption / feedback signals]."

Context: "Leadership wanted to commit [Y] to this. We didn’t yet know if the demand was real."

Actions: "I designed the MVP to test the riskiest assumption first, recruited the early users, ran the feedback loop, and turned the findings into a go / no-go recommendation."

4. You built an integration between two systems

Org goal: "Killing the manual re-keying that kept two systems out of sync."

Result: "I built an integration between [System A] and [System B], eliminating [X] hours of manual data entry a week and reducing errors, measured by [error rate / reconciliation time]."

Context: "[Team] was re-keying the same data into two systems and it kept going out of sync."

Actions: "I mapped the data flow between both systems, defined the integration requirements, worked with engineering on the API, and confirmed the time saved with the team after launch."

​
​

Behind the Scenes

Maybe you will be surprised by hearing this, but I am not a fan of social media.

Many of you found me through LinkedIn. But showing up on LinkedIn has been more of a push by myself.

Last week I took a pause with LinkedIn posting, because I've been feeling that something is off. In the way I post, in the way I interact with others.

I have a few ideas to try out this week to change it up. I will let you know how it goes.

Otherwise, if you have any feedback on my LinkedIn content, I would be very curious to hear!

What do you think?

Did this help you reframe your own impact?

Hit reply and let me know, do you love it, hate it, want more of something else?

See you next week,

Maria