Why does a business metric leave so much of the story untold?
This is a common frustration when you are writing a resume or preparing for an interview: you have work to talk about, but you do not have an impressive number to put next to it.
The first thing I always ask is: “do you need a metric? and if so… why?”
It’s probably born out of some societal rule we were taught somewhere along the way… but I’d also push you to maybe throw that rule out and explore what you’re really after.
There can be so much emphasis on final business measurements that we skip over the work itself. “I worked on a project that increased revenue by 30%” sounds impressive, but it tells me very little about what you actually contributed.
In FACT… I’ve seen managers, myself included, almost dismiss the candidates because they actually can’t talk about how they contributed in any meaningful way to the metric.
What was your role? What did you do? What happened because of your contribution?
It can also sound like you are taking credit for a group effort. I have written more about explaining your contribution to a team project, but there is another important piece here: whether that final number moved does not, by itself, tell us whether your work was useful.
Your work exists within a system. Other teams, decisions, processes, and business conditions influence what happens after you deliver it. Sometimes that system will not accept what you have created, even when there is strong evidence behind it.
I learned that through a pricing project. One of the biggest lessons of my career… And if you happen to be one of the sales reps involved in that pricing project… I may still hold some resentment (kidding! maybe…)
What did a pricing project teach me about impact?
We were acquiring a company and needed to figure out how its product would fit into our pricing model.
My team explored hiring a pricing consultancy. The quotes were in the six figures, around $200,000, with several months needed to complete the exercise. Which was just not in our team’s budget. Also… what a gig to go into! One pricing project and you’re set for a year!
After looking into the approach these agencies were using, I proposed running the work in-house for a fraction of the cost, accounting for my time, the opportunity cost of that time, and expenses such as tooling and surveys.
I completed that project, sometimes much to my own surprise. I identified a value metric, developed the pricing, and tested it with customers. Customers repeatedly told us that this was how they wanted to buy the product. The research and models supported the approach.
Along the way, I thought I had the support of the sales team.
That was where I missed something important.
Despite what customers told us, the sales team did not feel comfortable selling the product that way. Walking them through the evidence did not resolve that discomfort. The system was rejecting the change.
Looking back, I should have launched the traditional pricing model alongside the new one, with a much smaller group of sales reps testing the new approach. That would have given those reps an opportunity to establish whether it worked in practice and build confidence through their own experience.
That is what I would do differently, but it is not a successful pilot I can claim happened.
The project did not produce the revenue result or change in business habits we wanted. But it gave me a very specific lesson: customer validation and internal readiness to sell are two completely different things. I had done substantial work on the first and had not adequately addressed the second.
And, even now looking back at the actual work I did, with my many more years of experience… the work was incredibly sound. It was accurate. It was 100% the right direction that would have made the company a whole lot more money. So the work is still a valuable story to hold on to, even if it didn’t produce the final result.
That distinction changed how I think about bringing new work into an organization.
What can I describe instead of the final number?
The first place I encourage people to look is at intermediate outcomes: what your work allowed to happen at the next step.
Maybe it helped salespeople have clearer conversations with customers. Maybe it changed a discovery process, helped a team make a decision, or gave people more confidence using something you created.
Those changes can matter even when they do not immediately show up in the final business result. Sales skills, market conditions, customer decisions, and other factors still influence what happens afterward. It’s part of working within a system. We can do great work, even positively influence everything around us, but the system as a whole rejects the change.
Be specific about what you actually observed. “Made sales more effective” is vague. A concrete example of how a salesperson used your work to answer a previously difficult customer question gives someone much more to understand.
You do not need to turn that example into an invented percentage, nor do you need to claim it caused revenue growth you cannot connect to it.
In my pricing story, I can explain the research I conducted, the customer preferences we established, and the pricing approach we developed. I can also be honest that those findings did not translate into the adoption we needed.
The useful work and the disappointing result both belong in the story.
What if the result still was not what I wanted?
Then look carefully at what you learned.
I use that pricing project when answering interview questions about a mistake because I can explain where my thinking was incomplete and what I would change next time.
Simply saying “the sales team rejected it” would leave out my responsibility. The stronger story includes the signs I missed and the different rollout I would now consider.
That is part of developing your craft: reflecting on an experience and updating how you approach the work.
When I am listening to someone’s career story, I want to understand that thinking. What do they recognize now that they did not recognize before? What would they investigate earlier? What would they test before committing to a larger change?
You can do that reflection now, even if you did not do it during the project. Be honest about when the lesson became clear and whether you have applied it yet.
How do I turn this into an achievement story?
Choose one piece of work and answer four questions:
- What did I contribute? Describe your work and the thinking behind it.
- What did it enable immediately afterward? Name a change in behavior, a decision, or a way of working, and explain how you know it happened.
- What happened to the wider result? Be clear about what was achieved, what was not, and what remains uncertain.
- What did I learn that changes my approach? Separate changes you have already made from things you would try next time.
For a resume, use the specific contribution and supported outcome that fit. In an interview, you have more room to explain the context, the limitations, and the lesson.
The final number is one part of your experience. What your work made possible, and what that experience taught you to do differently, can tell someone far more about the craft you are bringing with you.
