The value engineer
Most PMs think their job is to build features. They’re wrong. Their job is to minimize the amount of code required to solve a customer problem. Shipping a request without a diagnosis isn’t velocity but expensive laziness.
In high-growth environments, we often call “order-taking” being responsive. In reality, it is a choice to ignore the root cause in favor of short-term political peace. Every time you ship a requested feature without a diagnosis, you are paying engineering salaries to subsidize a stakeholder’s lack of process.
To move from a project manager to a Value Engineer, you must change the diagnostic process for every request that hits your desk.
1. The “ten seconds before” rule
When a stakeholder asks for a feature - like a new CSV export - they are usually asking for a band-aid.
The CSV export is an admission of your product’s failure. The user isn’t looking for a file; they are looking for an answer they cannot find in your UI. Instead of asking what a feature should do, identify the trigger: What exactly was the user doing ten seconds before they felt they needed this?
To get this data, do not ask for an opinion either. Ask for a walkthrough: “Share your screen and show me the moment you realized you needed this. What was the very last thing you clicked?”
If a user is exporting data just to filter it by “Region” because your UI doesn’t allow it, the export tool is a band-aid. That is a Satellite feature - a niche addition that adds weight without fixing the root cause.
The Order-Taker builds the export.
The Value Engineer builds the filter.
One adds weight; the other adds power.
2. Visualizing the cost: Operational gravity
PMs struggle to say “no” because it feels like a lack of support. You need to translate niche features into operational drag.
Stop treating the backlog as a flat list and categorize requests by their gravity:
The core: Initiatives that strengthen the primary reason users pay you.
The pillars: Essential functional areas that allow the product to scale.
The satellites: Requests that serve a single segment but add permanent maintenance weight.
When a stakeholder pushes for a satellite, show them the maintenance-to-innovation ratio. Every feature added is a permanent increase in your QA surface area and technical debt interest.
Show them the math: For every 5 features we “adopt” for life, we lose roughly 1 day of new development per sprint to maintenance.
Pro-tip: Don’t just show the ratio. List the 5 satellite features that are currently “eating” your Mondays. Nothing stops a stakeholder faster than seeing the specific ghosts of bad decisions past. Ask them: “Is this button worth losing 5 days of innovation next year?”
3. The counter-interrogation
In high-pressure meetings, stakeholders usually want the widget, not the metric. Don’t fight them with abstract “outcomes”; fight them with the workflow.
When a senior lead pushes for a specific button, ask:
“If we ship exactly what you asked for, but the user still spends 3 hours in Excel to get their result, did we win or lose?”
Force them to acknowledge the workflow, not the button. A Value Engineer doesn’t just reject the request; they audit it. If the stakeholder can’t define the “win,” they haven’t done their job. Your job is to help them do it - or kill the request.
4. Monday morning action
If you can’t prove a feature removes a bottleneck, you are just a project manager. True customer-centricity is saying “no” to a customer’s specific request to save the customer’s time.
Go to your roadmap. Find the satellite feature that has been sitting there for months. Ask the “ten seconds before” question.
If you can’t find a clear trigger that justifies the permanent operational drag, demote it to Discovery. It doesn’t get a single line of code until the trigger is proven.
Thanks for reading! This article was originally published in my newsletter. I share one specific system for product managers every week. Join the community here: michelepm.substack.com
