Technology Strategy and Business Alignment Questions

Direct answer

I would design measurement before launch, not after: a short chain from adoption to process outcomes to business outcomes, a baseline taken in advance, and a rollout staged so some teams adopt later and act as a comparison group. That staging is what lets me separate the program's effect from seasonality, pricing changes and market shifts. Finance owns the money model (the spreadsheet that turns measured effects into dollars); my job is to supply credible measured effects and say how sure we are.

1. Build the measurement chain

1. Adoption (leading indicator, one that moves early and predicts later results): percent of target users active weekly, data quality in the new system.
2. Process outcomes: lead response time, quote-to-close days (sales cycle), manual re-keying hours.
3. Business outcomes (lagging indicator, one that confirms results only months later): win rate, revenue per salesperson, customer retention.
   Each metric has a named owner, definition and source, written down at the start. Take at least two to four quarters of baseline.

2. Separate the program's effect from everything else

• Stage the rollout: teams or regions switch at different dates. Compare the change in switched groups with the change in not-yet-switched groups over the same period (difference-in-differences). Seasonality (predictable calendar swings, such as a year-end buying rush) and market changes hit both groups, so they cancel out, provided the groups would have trended alike without the CRM. Check that with the baseline quarters: if A and B went 64, 63, 62 days and C and D went 62, 61, 60 (illustrative), both pairs were falling about 1 day a quarter beforehand, which supports the comparison.
• Keep a log of other changes (pricing, hires, reorganizations) and check the result against it.
• If staging is impossible, use a trend comparison: pick similar units that did not adopt (matched on size and starting sales cycle) and compare their trend with the adopters'. State the lower confidence, for example "the CRM shortened the sales cycle by about 5 days, plausible range 3 to 7; about 2 of the 7 days we saw would have happened anyway."

3. Worked example (illustrative)

Regions A and B get the CRM in Q1; C and D wait until Q3. Median sales cycle: A and B go from 62 to 55 days (-7); C and D go from 60 to 58 (-2) with no CRM. Estimated effect = (-7) - (-2) = -5 days, not -7. The 2 days is everything else changing. Repeat each quarter as rollout proceeds.

To connect it to money (Finance builds the real model; this is the shape): if the company closes 400 deals a year worth $20,000 each, that is $8M of bookings. Closing 5 days sooner pulls cash forward by 8,000,000 x 5 / 365, about $110k, a one-time timing benefit. Value from reps handling more deals in the same time is modelled separately, with the assumption that reps are limited by time rather than by leads stated explicitly.

4. Decision velocity (a measure of how fast decisions get made)

Define it measurably, for example the median hours from a discount-approval request being raised to it being decided, for one defined class of decisions. Instrument it (build the measurement in) with timestamps in the workflow tool. Illustrative: the median goes from 30 to 18 hours in staged teams and from 30 to 27 in not-yet-staged teams, so the estimated effect is (18 - 30) - (27 - 30) = -9 hours. Attribute causally the same way: compare staged groups. Watch for the measure falling because decisions are being rubber-stamped (approved without real review); pair it with a quality check such as approvals later reversed, say 4.0% before and 4.5% after.

5. Over three years

Quarterly benefit reviews with owners, each ending with a one-line statement of the estimate and its range; a year-1 view dominated by adoption, year-2 by process outcomes, year-3 by business outcomes. Expect lag: do not judge revenue effects at month 6.

Trade-offs and pitfalls

• Adoption is not value; people can log in and change nothing.
• Staged rollout delays benefits for later groups, a real cost that executives must accept.
• Do not credit the program for improvements already trending before launch; the baseline shows this.

Direct answer

I would not reject it outright and I would not adopt it alone. I would adopt it as a leading signal (an early measure that tends to move before the result we care about, such as retention or revenue, so it helps steer but does not prove success on its own) only if I can pair it with measures that reveal gaming, and I would define it so that gaming it requires doing the thing we actually want. The rule of thumb behind this is Goodhart's law, popularly phrased by Marilyn Strathern as: when a measure becomes a target, it ceases to be a good measure.

Step 1: Decide whether to adopt

Ask:

1. What behaviour do we want, and how directly does this number reflect it?
2. How would a customer game it, and what would they gain? If gaming has no payoff, the risk is small.
3. Can I redefine it so the cheap trick no longer counts?

Example (illustrative): the KPI is "reports created per account", meant to show engagement. A customer can run a script that makes hundreds. Redefine it as "reports viewed by at least two different users within seven days". Now gaming means getting colleagues to read the reports, which is the outcome we wanted.

Step 2: Guardrail measures

A guardrail measure is a second number watched alongside the KPI to catch harm or distortion:

• Retention of the same accounts, not only activity.
• Support tickets and complaints per account.
• Share of the KPI that comes from the top few accounts.
• Quality indicators of what was counted (do the reports get opened?).

Also: do not tie pay or targets to the raw number, and report it with its guardrails every time.

Step 3: Detect gaming after launch

Look at distributions (the full spread of values across accounts: how many sit near 10, how many near 150) rather than the single average. Worked example with illustrative data: 1,000 accounts, of which 986 create about 10 reports (9,860 in total) and 14 create about 150 (2,100). The average looks healthy at about 12 per account, but those 14 accounts (1.4%) produce roughly 17.6% of all volume. Then check whether those 14 also have views, retention and tickets in line with the others. If their reports are never opened, that is gaming.

Other checks: sudden step changes (a jump in the number right after the KPI was announced, instead of a gradual climb), usage at odd hours or in fixed intervals, accounts with high counts and low value on every other measure. Review the segment monthly and ask customer success what they see.

Step 4: Respond

Fix the definition first, not punish customers. A message to a flagged account might read: "We noticed your account created 150 reports last week and few were opened. We changed how this measure counts so it reflects reports your colleagues read. Is something in the product making the old count hard to avoid, or can we help you get more out of the reports?" Separately, if the KPI is also part of a contract or incentive, the response differs and needs legal and sales input.

Trade-offs and pitfalls

• A KPI so guarded that it takes months to compute is useless.
• Dropping every gameable metric leaves nothing measurable.
• What would change my call: if the payoff for gaming is large (money, status) and I cannot redefine it, I would refuse to adopt it.

Direct answer

A north star metric is the single measure that best captures the value customers get from the product and that the business grows from. It changes engineering priorities by giving every team the same question to ask of any roadmap item: which input to this metric does it move, and by how much? It settles arguments because it replaces opinion about what matters with a shared yardstick.

What a good one looks like

• It reflects delivered customer value, not just activity (successful orders per week, not registered accounts).
• It leads revenue rather than lagging it: it moves first, within weeks, while revenue (a lagging measure) only confirms the result months later.
• It breaks into input metrics (smaller measures that add up to the north star and that individual teams can move, such as checkout success rate, search-to-cart rate, delivery on time).
• It is understandable by engineers, not just finance.

How it changes technical priorities

1. Each team maps its work to an input metric and states the expected effect before the quarter starts.
2. Reliability targets (service-level objectives, or SLOs, which are the reliability level you promise; a guardrail metric is a second number that must not get worse while you chase the first, such as refund rate or support tickets) are set on the user journeys that feed the metric, such as checkout, rather than on every service equally.
3. Platform and tooling work is justified by the input metric it speeds up or protects.
4. Some work does not move the metric at all (security, legal compliance, preventing future outages). It is kept in a protected capacity share and is not asked to prove itself with the metric.

Example that settled an argument (illustrative)

A marketplace's north star is successful orders per week. The platform team wants to rebuild an internal reporting dashboard. The payments team wants to fix intermittent checkout failures. Both are reasonable.

Numbers: 200,000 checkout attempts a week, 4% fail technically, which is 8,000 failures. Halving the rate to 2% removes 4,000 failures. If about half of those buyers give up rather than retry, that is roughly 2,000 more successful orders a week. The dashboard serves a handful of internal analysts, so its link to the metric is indirect and unquantified. The payments fix went first. The mapping was written down like this (checkout rate and expected effect are illustrative):

The dashboard was not rejected: it was asked to state which input it speeds up, and it came back with a case about fraud review time.

Pitfalls

• Choosing a vanity metric (a number that looks impressive and rises easily but does not reflect customer value, such as sign-ups) that rises while value falls.
• Choosing revenue alone: too slow to guide a team's weekly choices.
• Gaming: teams optimise the number in ways customers dislike, so pair it with guardrail metrics.
• Treating the metric as the only legitimate goal and starving long-term engineering health.

Direct answer

I would set up a small, standing portfolio council that decides in two layers: funding is allocated to long-lived teams in a few agreed buckets (so we are not re-arguing every project), and a short list of cross-product requests goes to the council for an explicit decision with one accountable owner. Conflicts go up a time-boxed ladder, and success is judged by decision speed, reuse and outcomes, not by how many meetings happen.

Who is in the room (and why)

• Product leaders for each product (they own customer outcomes), the head of the shared platform, the team that builds capabilities every product needs, such as login, billing and data pipelines (owns reuse, meaning build once and use in several products), a senior architect (owns technical coherence), a finance partner (owns the budget envelope), and a go-to-market representative, from the sales, marketing and customer-success side (keeps it grounded in what customers pay for).
• The CPO (chief product officer) and CTO (chief technology officer) co-chair. Accountable for each decision is a single named person (usually the CPO for roadmap priority, the CTO for technology investments); everyone else advises. The CEO is the final tie-break (the deciding vote when the co-chairs disagree), not a regular attendee.

Criteria

Allocate by category first, then judge cross-product asks on four questions: Does it serve a stated company goal? How many products or customer segments benefit (reuse)? What is the risk and how reversible is it? What is the cost of waiting a quarter? I deliberately do not score every ticket in this forum; teams order their own work inside their budget.

Funding

Fund persistent teams rather than one-off projects, with a quarterly rebalance. Illustrative split of 80 engineers: Product A 28 (35%), Product B 20 (25%), new Product C 10 (12.5%), shared platform 16 (20%), and an unallocated exploration reserve of 6 (7.5%). That sums to 80. The reserve is released by the council for cross-product needs, which stops every small request becoming a political fight.

Conflict resolution

Ladder: the two product leads negotiate (3 working days) then the co-chairs decide (next council or an urgent call within 5 working days) then the CEO. Every decision is written in a short decision record (what, why, alternatives, who decided, review date) so losers can see the reasoning.

How I would know it is working

• Decision latency (how long a request waits for an answer): median days from request to decision.
• Share of roadmap items traceable to a written business outcome.
• Platform reuse: how many products use each shared capability, and duplicated builds found.
• Outcome hit rate: of the bets with a stated target, how many were met at review.
• A short quarterly survey of product and engineering leads on whether they understand why they won or lost.

Worked example

Product B asks for single sign-on that Product A built 18 months ago. Only Product A runs it today; once B adopts it reuse is 2 products, and Product C will be a third. The council funds extracting it into the platform (moving the login code into the shared team's care so every product calls one service) using 4 of the 6 reserve engineers for one quarter. Product A's lead objects (delay to their roadmap). The CPO decides, because the choice reorders product roadmaps (a technology-investment question with a roadmap cost; the CTO advises on it and owns the design that follows), records the reasoning, and promises a review in one quarter: did B and C ship faster?

Who does what in that decision:

Trade-offs and pitfalls

• Central governance slows teams if it decides too much; keep it to cross-product and hard-to-reverse choices.
• Too small a reserve and the platform starves; too large and teams feel taxed. Revisit the split quarterly.
• Flip to a looser model if council latency grows beyond what teams can tolerate; flip to tighter if duplicated builds keep appearing.

Direct answer

Write one objective that says what engineering will change for users, then three key results that describe what users do or experience, then name which engineering work is supposed to move each one. A key result measures an outcome when it describes a change in what users or the business do. It measures an output when it counts what the team produced.

Plain definitions

• Metric: any number you can measure (page load time, signups).
• KPI (key performance indicator): a metric watched continuously to keep something healthy, usually without a specific change target.
• Objective: a short, qualitative statement of the direction you want.
• Key result (KR): a measurable, time-bound target that shows whether the objective was met. Objectives commonly carry 3 to 5 of them (Google's OKR guide suggests around three).

The difference: a KPI says "is this healthy?", a KR says "by how much will we change it this quarter?", and both are built from metrics. Monthly active users (MAU) means distinct users who did a qualifying action in a month (an action that product defines in writing, for example opening the app and viewing or creating something, so that a bot hit or accidental open does not count). A guardrail is a second metric that must not get worse while you chase the first. Initiatives are the pieces of work (projects) you do to try to move a key result.

Worked example (illustrative numbers)

Baseline 400,000 MAU, so +15% is 460,000 (60,000 more). Two pieces of engineering work: (1) a redesigned signup and onboarding flow, and (2) mobile app startup speed and crash fixes.

Objective: Make the product easy to start and dependable to return to.

At 50,000 signups a month, KR1 means activated users go from 15,000 to 19,000, which is 4,000 more a month, or 12,000 over a quarter. That is a partial contribution against a 60,000 gap (the 12,000 is three monthly cohorts of new activated users added together, so it is the most MAU this KR could add by quarter end, not a measured monthly figure; the users must also stay active to count in a month). For KR3, assume 250,000 of the 400,000 monthly users are on mobile: 3 points of 250,000 is 0.03 x 250,000 = 7,500 more users who stay active. KR2 (fewer crashes and slow starts) is the lever that supports KR3, so it is not added again. KR2 is the weakest of the three as an outcome: it measures the experience users get, not what they do, and it fails test 1 below (crashes could fall with user behavior unchanged). I keep it as a leading indicator for KR3 and say so; if the team cannot show it moving KR3, I would demote it to a guardrail and keep it out of the KR list. Together: 12,000 + 7,500 = 19,500 of the 60,000 gap (an upper bound, because a user activated under KR1 may also be a mobile user counted under KR3), leaving 40,500 for other work such as acquisition, new features and marketing. Saying openly that engineering key results cover only part of the objective is part of the answer.

Outcome versus output

These are outputs, not KRs: "Ship the new onboarding flow by week 6", "Close all crash tickets", "Complete three performance projects". Each can be 100% done while MAU does not move.

Three tests I apply:

1. Could the key result be achieved with users behaving exactly as before? If yes, it is an output.
2. Does it describe a user or business change, or a thing we built?
3. If we hit it and the objective still failed, would anyone be surprised?

Pitfalls

• Engineering rarely controls an outcome alone, so pick measures engineering can influence, and keep milestones as initiatives that sit under a KR rather than as KRs.
• Pair each KR with a guardrail (for example, crash rate must not rise while chasing activation).
• A pure outcome target without a plan is a wish; the work list is how the KR gets reached.