Measuring FDE Success by Business Outcomes: Forward Deployed Engineer vs Software Engineer
This skill teaches you how to define, instrument, track, and report on business-outcome metrics that prove the value of forward deployed engineering engagements, replacing vanity technical metrics with measures that matter to the customer's P&L.
Define 2-4 business-outcome metrics tied to the customer's stated mission before writing any code. Track leading indicators weekly and lagging business results monthly. Report outcomes in the customer's language, not engineering jargon. Compare what a forward deployed engineer vs software engineer would measure: FDEs track revenue impact, time-to-value, and customer retention rather than story points, commits, or uptime percentages.
Outcome: You produce a living scorecard of 2-4 business-outcome metrics with baselines, targets, and weekly tracking that lets you prove FDE engagement value in terms the customer's leadership team cares about.
Prerequisites
- Basic understanding of what forward deployed engineering is and how it differs from traditional software engineering
- Familiarity with the customer's business model and revenue drivers
- Access to the customer's analytics or data infrastructure, or the ability to request it
- Completion of or concurrent work with scoping mission-driven engagements
Overview
The most common failure mode in forward deployed engineering is measuring success the same way a product team measures it: pull requests merged, features shipped, bugs closed, uptime achieved. Those metrics tell you whether an engineer was busy. They say nothing about whether the engagement was worth the investment. This skill closes that gap by teaching you to identify, instrument, and report on the business outcomes that justify an FDE's presence in a customer environment. When you compare a forward deployed engineer vs software engineer, the measurement difference is the sharpest contrast. A software engineer working on core product is measured by code quality, velocity, and system reliability. A forward deployed engineer is measured by whether the customer's business moved. Revenue unlocked, time-to-value compressed, churn risk eliminated, operational cost reduced. The artifact you build here is a living scorecard, not a dashboard of vanity metrics.
Within the Forward Deployed Engineering Five-Lens Framework (FDE Five-Lens Framework), measuring by business outcomes is the fifth lens and the one that keeps all the other lenses honest. You can scope a mission perfectly, operate autonomously, ship production systems, and run learning loops, but if you cannot prove the engagement generated measurable business value, renewal conversations become guesswork and internal stakeholders lose confidence. The scorecard you create here feeds directly back into scoping mission-driven engagements for the next engagement cycle and into transitioning field learnings into product features when you want to justify building a capability into core product.
Success looks like this: at any point during the engagement, you can open a single document or spreadsheet, show it to the customer's executive sponsor, and in under two minutes explain what has changed in their business because of this work. The scorecard contains a baseline (where the metric was before engagement), a target (where the mission aims to move it), the current value, and a trend line. No Jira velocity charts, no sprint burndowns. Business language, business numbers, business impact.
The skill is rated intermediate because the technical instrumentation is usually straightforward. The hard part is the negotiation: getting the customer to commit to specific, measurable targets before you start building, and resisting the organizational pressure to pad the scorecard with easy-to-hit technical metrics that dilute the signal.
How It Works
The fundamental insight behind outcome-based measurement is that engineering effort and business value are only loosely correlated. You can ship a beautifully architected data pipeline in three weeks that nobody uses because the sales team was never trained on the reports it generates. Or you can write a 200-line script in two days that automates a manual reconciliation process and saves the customer $40,000 per month. Story points cannot tell you which of those was the better use of your time. Business outcomes can.
The technique works by inverting the normal measurement flow. Instead of starting with what the engineer did and inferring value, you start with what the customer needs to change and work backward to the metrics that prove it changed. This is the core distinction when comparing a forward deployed engineer vs software engineer in practice. A software engineer's metrics flow from the engineering process outward: code coverage, deploy frequency, incident response time. An FDE's metrics flow from the business objective inward: the customer said they need to reduce onboarding time from 14 days to 3 days, so you measure days-to-first-value for new accounts.
The scorecard uses two layers of metrics. Leading indicators are things the FDE can observe weekly that predict whether the business outcome will be hit. They are controllable and early. Lagging indicators are the actual business results, often measured monthly or quarterly. You need both. Leading indicators let you course-correct mid-engagement. Lagging indicators are what you present to the executive sponsor.
For example, if the business outcome is "reduce customer churn by 20%," your leading indicators might be feature adoption rate among at-risk accounts, support ticket volume per account, and time-to-resolution for integration issues. These are things your engineering work directly influences, and they move before the churn number does. The lagging indicator is the actual churn rate, measured quarterly.
The framework also explicitly excludes certain metrics. Anything that measures engineering activity rather than business impact gets excluded from the scorecard. Lines of code, number of deploys, sprint velocity, pull request counts. These can live in your team's internal retrospectives, but they never appear on the customer-facing scorecard. The reason is not that they are useless internally, but that including them dilutes the signal and trains stakeholders to evaluate FDE work the way they evaluate their internal engineering team, which defeats the purpose of the engagement.
Finally, the scorecard includes a "so what" column. For each metric, you articulate the dollar value, time value, or risk reduction it represents. This translation step is what turns a data point into a business case. "Feature adoption increased from 35% to 72%" is interesting. "Feature adoption increased from 35% to 72%, which means 412 additional accounts are using the integration that reduces their manual processing by 6 hours per week, saving those accounts a combined $1.2M annually" is a renewal conversation.
Step-by-Step
Step 1: Extract the business objective from the mission scope
Pull the mission statement from your scoped engagement document. If you do not have one, pause and create one before proceeding. Identify the specific business change the customer expects. " Write the objective in the customer's language, using their terminology.
If the mission scope contains multiple objectives, rank them by the customer sponsor's stated priority and select the top 2-3. More than 4 business objectives on a single scorecard creates noise that makes weekly tracking impractical.
Tip: If the customer's mission statement is vague ("improve the integration experience"), schedule a 30-minute call with the executive sponsor and ask: "If this engagement is wildly successful, what number changes on your quarterly business review slide?" That question almost always produces a concrete metric.
Step 2: Define 2-4 lagging business-outcome metrics
For each business objective, define one measurable lagging indicator. This is the number the executive sponsor will use to judge the engagement. It must be a metric the customer already tracks or can start tracking with minimal effort. Common FDE lagging metrics include: customer time-to-value (days from contract signing to first meaningful usage), revenue influenced (incremental revenue from accounts where the FDE shipped capabilities), churn reduction (percentage decrease in accounts lost), operational cost savings (dollars saved through automation or process improvement), and NPS or CSAT changes among accounts touched by FDE work.
Write each metric with four components: the metric name, the unit of measurement, the current baseline, and the target. " If you do not have the baseline, getting it is your first task before any engineering work begins.
Tip: Always get the baseline number in writing before you start building. If you establish the baseline after you have already made improvements, stakeholders will anchor on the improved number and your impact becomes invisible.
Step 3: Identify 1-2 leading indicators per lagging metric
For each lagging metric, identify 1-2 leading indicators that you can observe weekly and that predict movement in the lagging metric. Leading indicators should be things your engineering work directly influences. " The leading indicators serve as your weekly steering mechanism. If they are moving in the right direction, you are on track.
If they stall, you investigate and course-correct before the lagging metric reveals a problem a quarter later.
Tip: A good leading indicator changes within 1-2 weeks of your engineering work. If it takes a quarter to move, it is actually another lagging indicator and will not help you steer.
Step 4: Build the scorecard document
Create a single document or spreadsheet that will serve as the living scorecard for the engagement. Use a simple table structure with columns for: metric name, type (leading or lagging), unit, baseline, target, current value, trend (arrow or sparkline), last updated date, and "so what" (the business translation). Place the lagging metrics at the top and their corresponding leading indicators indented below them. Add a header section that includes the engagement name, the customer, the executive sponsor's name, the engagement start date, and the expected end date.
Keep this document in a location accessible to both your internal team and the customer stakeholders. A shared Google Sheet or Notion page works well. Do not bury it inside an engineering project management tool the customer does not use.
Tip: Add a "so what" column from day one, even if you have to estimate the dollar translation. Stakeholders who see "churn dropped 3 percentage points" react differently than stakeholders who see "churn dropped 3 percentage points, retaining approximately $480K in ARR that was at risk."
Step 5: Instrument metric collection
Determine how each metric will be collected. Some metrics come from the customer's existing analytics (Mixpanel, Amplitude, Salesforce, their data warehouse). Some require new instrumentation you build as part of the engagement. For each metric, document the data source, the query or calculation, and the person responsible for updating it.
Automate collection wherever possible. A metric that requires someone to manually pull a report each week will stop being updated by week three. If full automation is not possible, set a recurring calendar event with instructions for whoever performs the manual step. Test the collection mechanism by pulling the baseline number.
If you cannot reliably get the baseline, you cannot reliably track the metric, and you should either fix the instrumentation or choose a different metric.
Tip: If the customer's data infrastructure makes a critical metric hard to collect, building that instrumentation is legitimate FDE work. Frame it as part of the engagement: "We need to be able to measure X to prove the engagement is working, so the first deliverable is the measurement capability itself."
Step 6: Run weekly leading-indicator reviews
Every week, update the leading indicators on the scorecard. Review them in a 15-minute internal check-in (not a formal customer meeting). Look for three patterns: indicators moving toward target (continue current approach), indicators flat (investigate blockers, which often involve customer-side dependencies like training or process changes), and indicators moving away from target (escalate and potentially re-scope). Document the reason for any significant movement in a notes column.
Over time, this creates a narrative that explains the trajectory of the engagement. When a leading indicator stalls, the fix is often not more engineering but rather a conversation with the customer about adoption, training, or process changes on their side. This is where the FDE's interdisciplinary skills become critical.
Tip: Keep the weekly review to 15 minutes and focus on surprises only. If everything is on track, acknowledge it and move on. The review is a steering mechanism, not a status ceremony.
Step 7: Conduct monthly lagging-metric updates with stakeholders
Once per month, update the lagging business-outcome metrics and share the scorecard with the customer's executive sponsor. This is not a long presentation. It is a 5-10 minute walkthrough of the scorecard, delivered either in a standing check-in or as an asynchronous update with a short Loom video or written summary. Lead with the business outcome numbers: where they were, where they are now, and where they are headed.
Then briefly connect the dots to the leading indicators and the engineering work that drove them. End with any asks: do you need the customer to unblock something, change a process, or provide access? The monthly cadence keeps the engagement visible to decision-makers without overwhelming them. If you wait until the end of a 6-month engagement to report results, you lose the opportunity to build confidence incrementally.
Tip: Send the scorecard update 24 hours before any renewal or expansion conversation. Let the numbers do the selling.
Step 8: Translate metrics into a renewal or expansion case
At the 75% mark of the engagement timeline, compile the scorecard data into a one-page summary that answers three questions: What was the business problem? What changed? What is the projected impact if we continue or expand? Use the "so what" column data to calculate ROI.
2M in retained revenue plus $800K in operational savings, the ROI story is straightforward. If the lagging metrics have not moved enough yet but the leading indicators are trending correctly, project the expected impact based on the trend and clearly label it as projected. This summary becomes the input for the customer success or sales team's renewal conversation, and it becomes the evidence base for transitioning field learnings into product features when you want to justify building FDE-proven capabilities into core product.
Tip: Frame the ROI in the customer's fiscal year, not your engagement timeline. If the customer's CFO thinks in annual savings, present annual numbers. If they think in quarterly revenue, present quarterly.
Examples
Example: B2B SaaS reducing enterprise onboarding time
A 40-person SaaS company sells data analytics to enterprise customers. Their average onboarding takes 45 days, and they lose 15% of new accounts before go-live because the integration process stalls. They embed one FDE for a 6-month engagement. The FDE needs to prove value to justify the $250K engagement cost.
The FDE starts by documenting the baseline: 45-day average onboarding, 15% pre-go-live churn, $180K average annual contract value. The lagging metrics on the scorecard are: average onboarding days (target: under 10), pre-go-live churn rate (target: under 5%), and revenue retained from faster onboarding (target: $540K in saved ARR, calculated as 10% churn reduction times average ACV times projected new accounts). Leading indicators are: number of integration steps automated (weekly), percentage of new accounts reaching first data import within 48 hours (weekly), and support tickets per onboarding account (weekly). By month 3, the FDE has automated 7 of the 12 manual integration steps.
The leading indicators show 68% of accounts reach first import within 48 hours (up from 22%), and support tickets per onboarding dropped from 14 to 4. The lagging metrics are moving: average onboarding is at 18 days and trending down, pre-go-live churn is at 9%. At the month 4 stakeholder review, the FDE presents a scorecard showing the trajectory and projects that by month 6, onboarding will be under 10 days. The "so what" column shows $390K in retained ARR so far, already exceeding the engagement cost.
The renewal conversation is straightforward.
Example: Fintech reducing manual reconciliation costs
A fintech company deploys an FDE to a large banking client that processes 50,000 transactions daily. The bank's operations team spends 120 person-hours per week on manual reconciliation of failed transactions. The 4-month engagement costs $180K. The bank's VP of Operations is the executive sponsor and needs to justify the spend to the CFO.
The FDE documents the baseline: 120 person-hours per week at an average fully loaded cost of $65/hour, totaling $7,800 per week or $405,600 annually. The lagging metric is operational cost reduction in reconciliation, with a target of 70% reduction ($283K annual savings). Leading indicators are: percentage of transaction types with automated reconciliation rules (updated weekly) and manual interventions per 1,000 transactions (updated daily via the bank's ticketing system). The FDE builds the scorecard in a shared Google Sheet the VP of Operations can access anytime.
By week 6, automated reconciliation covers 60% of transaction types, and manual interventions drop from 24 per 1,000 transactions to 9. " By month 3, the lagging metric shows a 62% reduction in reconciliation costs. " The bank expands the engagement.
Example: Small startup proving FDE value for a single strategic account
A 12-person startup deploys their CTO part-time as an FDE to their largest customer (40% of revenue). The customer is a logistics company struggling with real-time fleet visibility. There is no formal engagement budget, but the startup risks losing the $600K annual contract if the customer does not see improvement within 90 days.
The CTO-as-FDE keeps the scorecard minimal: one lagging metric (percentage of fleet with real-time visibility, baseline 35%, target 90%) and two leading indicators (number of vehicle types integrated with the tracking API, and data freshness measured as average latency of position updates). The scorecard lives in a shared Notion page with the customer's Head of Logistics. Every Friday, the CTO updates the leading indicators and adds a one-sentence note explaining what changed. By week 4, three of five vehicle types are integrated and average latency drops from 8 minutes to 45 seconds.
The lagging metric moves from 35% to 58% fleet visibility. At the 60-day check-in, the CTO shows the scorecard and says: "You can now see 72% of your fleet in real time, up from 35%. " The customer renews and increases the contract by 30%.
Example: Forward deployed engineer vs software engineer metric comparison at a large enterprise
A platform company has both a core engineering team of 80 software engineers and a 6-person FDE team. Leadership asks for a unified performance report. The FDE team lead needs to demonstrate why FDE metrics look different from the core team's metrics without appearing to undermine the engineering org.
The FDE team lead creates a side-by-side comparison document that frames the difference as complementary rather than competitive. The core engineering team reports on deployment frequency (daily), test coverage (87%), P95 latency (120ms), and sprint velocity (42 points per sprint). These are appropriate metrics for a team building and maintaining a platform product. 1M over the past two quarters).
The team lead frames this in the report: "Core engineering makes the product excellent. FDE makes the product successful in complex customer environments. " This framing, rooted in the forward deployed engineer vs software engineer distinction, helps leadership understand that both measurement approaches are correct for their respective contexts. The comparison document becomes a template other FDE orgs in the company adopt.
Best Practices
Set baselines before writing any code. The single most important moment in the measurement process is capturing where the metric stands before the engagement begins. Without a documented baseline that both sides agree on, any improvement becomes debatable. Pull the number, screenshot it, put it in the scorecard, and get the executive sponsor to confirm it in writing or on a recorded call.
Limit the scorecard to 2-4 lagging metrics. More than four business outcomes on a single scorecard fragments attention and makes it impossible to tell a coherent story. If the engagement genuinely touches more than four business outcomes, you likely have multiple missions bundled together and should split them into separate engagements with separate scorecards.
Always include the dollar or time translation. A metric without a "so what" is just a number. Translate every metric into the language the customer's finance team speaks: dollars saved, hours recovered, revenue retained, risk reduced. If you cannot quantify the dollar value precisely, use a defensible estimate with clear assumptions.
Even a rough translation ("each day of reduced onboarding time saves approximately $X based on the customer's average deal size and sales cycle") is better than no translation.
Separate engineering-activity metrics from business-outcome metrics completely. Keep sprint velocity, code coverage, and deploy frequency in your internal engineering retrospectives. Never put them on the customer-facing scorecard. Mixing activity metrics with outcome metrics trains stakeholders to evaluate FDE work by effort rather than impact, and it undermines the entire value proposition of the engagement.
Update leading indicators weekly without exception. Stale leading indicators are worse than no leading indicators because they create false confidence. If a metric has not been updated in two weeks, it means either the collection mechanism is broken, the metric is too hard to track, or the team is too busy building to measure. All three are problems that need immediate attention.
Use the customer's language, not engineering jargon. The scorecard is a communication tool, not a technical document. If the customer calls their metric "time-to-go-live" instead of "time-to-value," use their term. If they measure "cases resolved per analyst per day" instead of "throughput," use their term.
Alignment on vocabulary prevents misunderstandings and signals that you understand their business.
Review the scorecard design with the executive sponsor before finalizing it. The metrics you think matter and the metrics the sponsor reports to their board may differ. A 20-minute review where you walk through the proposed scorecard and ask "Does this capture what success looks like for you?" prevents weeks of tracking the wrong thing.
Common Mistakes
Tracking only technical output metrics like features shipped, bugs fixed, or deployment frequency
Correction
This happens because engineers default to metrics they can control and measure easily. The symptom is a quarterly review where you present an impressive list of deliverables and the customer asks, "But what did this actually do for our business?" To catch this early, check whether every metric on your scorecard could appear on the customer's quarterly business review slide. If not, it belongs in your internal retrospective, not on the scorecard. Replace technical metrics with the business outcomes those technical deliverables were supposed to produce.
Setting targets without establishing baselines first
Correction
This occurs when teams are under pressure to start building quickly and skip the measurement setup. The result is that at the end of the engagement, you cannot prove improvement because you have no reference point. The warning sign is any target phrased as "improve X" without a specific starting number. Before committing to any target, demand the current state number.
If the customer does not have it, building the measurement capability is your first engineering task, and you frame it as essential infrastructure for proving the engagement's value.
Overloading the scorecard with 8-10+ metrics to make the engagement look comprehensive
Correction
Teams do this to cover all possible angles and protect themselves from the accusation that they missed something. In practice, a 10-metric scorecard means none of the metrics get adequate attention, updates become a chore, and the monthly stakeholder review turns into a data dump instead of a focused narrative. If you find yourself adding more than 4 lagging metrics, step back and ask which 2 the executive sponsor would show to their board. Those are your real metrics.
Everything else is either a leading indicator (nest it under the lagging metric) or a distraction (remove it).
Waiting until the end of the engagement to report business outcomes
Correction
This often stems from wanting to wait until the numbers are "impressive enough" to share. The problem is that by the time you have end-of-engagement data, the renewal decision has already been made emotionally, and you have missed months of opportunity to build stakeholder confidence incrementally. The fix is to start sharing the scorecard monthly from month one, even when the numbers show early baseline data and minimal movement. Early transparency builds trust and gives the sponsor ammunition to defend the engagement internally before results materialize.
Choosing metrics the customer cannot verify independently
Correction
If the only person who can pull the metric data is the FDE, the customer has to take your word for the results. This creates a credibility gap, especially during renewal conversations when the FDE is the one advocating for their own continuation. The signal is any metric sourced exclusively from a system the customer does not have access to, or a calculation only the FDE understands. Fix this by using metrics from the customer's own systems (their CRM, their analytics platform, their financial reports) or by building the reporting capability so the customer can pull the numbers themselves.
Conflating correlation with causation when reporting results
Correction
Churn dropped during your engagement, but was it because of your work or because the customer also launched a new pricing plan? FDEs who claim credit for every positive movement in the lagging metric without acknowledging confounding factors lose credibility with sophisticated stakeholders. The fix is to tie your narrative to the causal chain: your engineering work drove specific leading indicator changes, those leading indicators are mechanistically connected to the lagging metric, and here is the portion of the improvement attributable to the engagement. Honest attribution, even when it means claiming partial credit, builds more trust than claiming total credit.
Other Skills in This Method
Scoping Mission-Driven FDE Engagements
How to define clear, outcome-bound missions for forward deployed engineering work so engagements stay focused on shipping production results instead of drifting into open-ended consulting.
Operating Autonomously in Customer Environments
Techniques for making independent technical decisions at the edge of customer deployments while maintaining alignment with your home organization's product strategy and engineering standards.
Shipping Production Systems Inside Client Infrastructure
Practical workflows for deploying, integrating, and hardening production-grade software within a customer's existing tech stack, security policies, and operational constraints.
Running Continuous Learning Loops from Field Deployments
How to systematically capture insights, failure patterns, and feature requests from customer environments and translate them into actionable product feedback for core engineering teams.
Building Interdisciplinary Forward Deployed Engineer Skills
How to cultivate the hybrid blend of software engineering, data analytics, solution architecture, and client communication skills required to operate effectively as a forward deployed engineer.
Transitioning Field Learnings into Core Product Features
How to evaluate which customer-specific solutions deserve generalization, write compelling internal proposals, and collaborate with product teams to fold field-proven patterns back into the platform.
Preparing for Forward Deployed Engineer Interviews
How to study for and excel in FDE interview processes, including system design in ambiguous customer scenarios, live coding under constraint, and client-communication role plays.
Frequently Asked Questions
How do I measure FDE success when the customer cannot clearly articulate their business objective?
Start by asking what number the executive sponsor reports to their board or their boss. If they still cannot name one, propose three candidate metrics based on the problem domain (e.g., cost reduction, revenue growth, time savings) and ask them to rank them. Most customers know what success looks like, they just have not framed it as a metric yet. If after two conversations they genuinely cannot identify a business outcome, this is a red flag that the engagement may lack a clear mission, and you should revisit [scoping mission-driven engagements](/skills/scoping-mission-driven-engagements) before proceeding.
How long should it take to set up the scorecard before starting engineering work?
Budget 3-5 business days for scorecard design, baseline collection, and stakeholder alignment. This includes one call to extract objectives, one working session to draft the scorecard, one call to validate with the executive sponsor, and 1-2 days to instrument metric collection. If you spend more than a week on the scorecard, you are overcomplicating it. If you spend less than a day, you are probably skipping baseline documentation or stakeholder buy-in, both of which will cost you later.
Should I measure FDE success before or after transitioning learnings to product?
Measure continuously during the engagement, not after. The scorecard runs from day one of the engagement through the end. Transitioning learnings to product is a separate activity that happens in parallel, informed by what the scorecard reveals about which customer problems are common enough to justify core product investment. The scorecard data becomes the evidence base for the transition case. See [transitioning field learnings into product features](/skills/transitioning-field-learnings-into-product-features) for how to use scorecard data to build that case.
Why does my FDE scorecard keep drifting toward technical metrics over time?
This drift happens because the people updating the scorecard are engineers, and engineers naturally gravitate toward metrics they can control and measure precisely. Technical metrics are comforting because they always show progress: code was written, tests passed, features deployed. Business metrics are uncomfortable because they sometimes show no movement despite real engineering effort. Combat this drift by reviewing the scorecard every 4 weeks and asking for each metric: "Would the customer's CFO care about this number?" If the answer is no, move it to your internal engineering retrospective and replace it with a metric the CFO would care about.
How do I handle situations where the forward deployed engineer vs software engineer measurement conflict creates organizational tension?
Frame it as complementary, not competitive. Software engineers measure platform health and development velocity because those metrics ensure the product is reliable and improving. Forward deployed engineers measure business outcomes because those metrics ensure the product creates value in complex customer environments. Both are necessary. Present the two measurement frameworks side by side in leadership reviews and explicitly name why each is appropriate for its context. " Let the numbers make the argument.
What do I do when the business outcome metric does not move despite strong leading indicators?
First, verify the causal chain between your leading indicators and the lagging metric. If feature adoption (leading) is climbing but churn (lagging) is flat, something else is driving churn that your engagement does not address. Second, check the time lag. Some lagging metrics genuinely take a quarter to respond to leading indicator changes, especially retention and revenue metrics. Third, look for confounding factors: did the customer change pricing, lose a key account manager, or face a market shift? Document these factors transparently on the scorecard. Honest analysis of why the number has not moved yet is far more credible than overpromising or quietly swapping the metric.
How do I build the scorecard when the engagement is very short, like 4-6 weeks?
For short engagements, focus on one lagging metric and one leading indicator. Skip the monthly reporting cadence and instead do a single mid-point check and a final report. Choose a lagging metric with a short feedback loop, such as time-to-first-value or a specific operational efficiency gain, rather than a quarterly metric like churn. In very short engagements, the scorecard is less about tracking trends and more about documenting the before-and-after snapshot. Capture the baseline on day one, measure the same metric on the last day, and calculate the delta. Simple, defensible, and fast.