Technology Strategy and Business Alignment Questions

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

By platform I mean the shared internal foundation (build and deploy tooling, common services, data and infrastructure) that product teams build on, as opposed to the customer-facing features themselves. I would not ask executives to approve "three years of platform work". I would ask them to approve a staged, gated investment tied to outcomes they already care about, with the first stage cheap and reversible, and with stop criteria (the pre-agreed results that would make us halt or change course) agreed in advance. Being possibly wrong is handled by design, not by confidence.

Framing in business terms

• Name the business problem: for example, the time from idea to customer is slowing, outages are costing customers and engineers' time, and the roadmap itself is at risk because every feature gets harder.
• Say what the company gets: faster delivery of features later, fewer incidents, ability to enter markets the current system cannot support.
• Say what it costs: roadmap capacity, in plain terms. If the program takes 30% of engineering capacity for 3 years, that is 0.3 x 36 months = 10.8 months of capacity: about a year of delay spread over 3 years, not a year of nothing. Name the roadmap items that wait, for example "the loyalty-points feature and the second-region launch move out; the checkout redesign and the compliance deadline stay".

Sample opening of the pitch: "Today an idea takes about 20 days to reach customers, and a growing share of each team's week goes to working around the old base. I am asking for 30% of engineering for three years in stages. The first stage costs one team for 90 days. If lead time has not moved by month 12, we stop."

Evidence to bring

• Trend data you can show: lead time (idea to production), how much of each team's time goes to workarounds, incident counts and customer-facing impact, and examples of roadmap items that took far longer than they would have on a cleaner base.
• A comparison: what happens if we do nothing, with the same metrics projected.
• Left to the finance partners: the detailed financial model, which they build from these figures.

What I ask of them

1. A decision on the direction and an executive sponsor (a senior leader who owns the outcome, clears obstacles and defends the budget).
2. Protected capacity (a fixed share of engineering time that is not taken back when a feature gets urgent, not whatever is left).
3. Agreement on the gates (checkpoints where leaders decide to continue, change or stop), say at months 6, 12 and 24, each with a measurable test. Illustrative gates: month 6, the pilot team deploys without manual steps; month 12, idea-to-production lead time falls from 20 days to 12; month 24, a majority of teams run on the platform and the share of engineering time lost to workarounds drops from 30% to 15%.
4. A commitment on which roadmap items will wait and which will not.

A rough payback check (illustrative)

Using the numbers above, the program costs 30% of capacity for 36 months. Per engineer that is 0.3 x 36 = 10.8 months. If the month-24 gate is met and workaround time falls from 30% to 15% of engineering time, that frees 15% of capacity, or 0.15 x 12 = 1.8 months per engineer per year. 10.8 / 1.8 = 6 years to recover the cost from workaround time alone, counted from when the saving starts. The 15% saving is only reached at the month-24 gate, so on the calendar the break-even from this one benefit is later still, which strengthens the point below. So that benefit by itself does not carry the case. The case has to rest on the other outcomes: lead time from 20 to 12 days (features reach customers 40% sooner, 8 / 20), fewer incidents, and markets the current system cannot support. I would put a number on each with the finance partners and say plainly which one the investment depends on, so executives can judge the claim that matters, and so the month-12 gate tests that one.

Handling the risk that I am wrong

• Start with a thin slice (the smallest end-to-end piece that tests the idea for real): one team or product on the new platform within about 90 days, to test the assumption cheaply.
• Make the gates real: for example, if the pilot team's lead time has not improved by the agreed amount by month 12, we stop or change course, and that is written down now.
• Keep each stage independently useful, so stopping halfway still leaves value.
• Invite the strongest opposing view and put it in the proposal.

Pitfalls

Hiding the delay, arguing from technical purity, and asking for unconditional trust. What would change my call: if the pilot shows the benefit is much smaller than predicted, I recommend scaling back.

Direct answer

Engineering-business alignment means the work engineering chooses is traceable to a business result the company agreed to chase, and that both sides share one definition of success. If engineering delivered everything it planned and the business still missed, the likeliest cause is that the plan measured output (things shipped) while the business needed an outcome (a change in revenue, retention or cost). I would fix the plan's link to outcomes first, then the structures that keep it linked.

What misalignment probably looked like

• The roadmap was built from engineering capacity and a request backlog, not from the quarter's business bets.
• "Done" meant released, not "the metric moved".
• Dependencies (things other teams must do for the work to pay off) on sales, marketing or support, such as training, pricing and launch timing, were nobody's deliverable.
• Assumptions were never tested ("customers want this") and nobody revisited the plan when early data disagreed.
• Status reporting counted features delivered, so green dashboards hid a missed quarter.

Illustrative case: the business target was +10% revenue and the result was +6%. Engineering shipped 14 of 14 planned items, but only 3 of the 14 (about one in five) had a stated link to the revenue chain (the steps a customer passes through before paying: find the product, sign up, pay, renew). That ratio is the diagnostic. The map that produces it looks like this (excerpt; the other eight rows look like the last three):

Short term (this quarter and next)

1. Map every shipped and in-flight item to the metric it was meant to move and read what actually moved.
2. Stop or defer items with no link; protect the few with the strongest.
3. Hold a joint weekly review with product, sales and engineering on the outcome numbers, not task status.
4. Agree one written definition of done per initiative that includes the business measure. For example: "Done = live for 100% of customers, sales trained, pricing page updated, and two weeks of data show signup-to-paid conversion moving toward the 4.5% target; if it has not moved by week 4, we review." The weekly review runs 30 minutes: each initiative's metric against plan, whether its key assumption still holds, one decision per item (continue, change, stop), and the status of sales, marketing and support deliverables.

Long term

• Quarterly objectives written with the business, with outcome-based key results.
• Product and engineering plan together from the start (a shared discovery step: product and engineering test the problem and the likely solution together before committing to build), so feasibility and value are weighed once.
• Kill or change initiatives mid-quarter when early data says the assumption was wrong.
• Reporting that shows outcome movement next to delivery.

The same mapping applied to large technical projects (two illustrative cases where explicit mapping changed the scope)

1. Customer-system migration. The project plan was "move all data and reports to the new system". Mapped to the objective "shorten quote-to-cash time" (the elapsed time from sending a customer a price quote to collecting payment), most legacy reports (illustratively 51 of 60) turned out irrelevant and the quote workflow was the real target, so scope shrank and that workflow went first.
2. Move to a new cloud environment. Mapped to the objective "open a new country within two months", the team migrated only the services the new market needed (illustratively 6 of 40: login, catalogue, tax, billing, shipping rates and support) and left the rest, instead of a long sequence ordered by technical convenience.

These are composites to show the method, not reports of a named company.

Pitfalls

Do not answer by asking for more status meetings. If the cause was a market change outside anyone's control, alignment would not have saved the quarter, so I would also check what the plan assumed about demand.

Direct answer

Use a real story of your own; this one shows the shape. I helped decide to move a customer-facing web application off an end-of-life front-end framework (one whose vendor has stopped issuing updates and security fixes) to a currently supported one. I tied it to the product roadmap by sequencing the migration around the features that would otherwise be built twice, weighed future-proofing (choosing a platform that will not need replacing soon) against migration cost by migrating incrementally, and would now involve security and support earlier.

Situation and stakes

Four teams shared one web application. The framework's vendor support was ending, which meant no security fixes, and hiring for it was getting harder. The company strategy that year was to expand into new markets, which needed fast delivery of localized features (screens translated and adapted for each country) on that same front end.

Actions I took

• Linked it to strategy. I framed the decision as "protect the ability to ship the market-expansion roadmap", not "modernize the stack". Product leadership cared about the delivery risk, not the framework name.
• Built consensus across teams. I met each of the four team leads, security, and the product manager separately first, to learn their constraints (support gave input by email), then ran one working session with the team leads and the product manager to reach consensus (agreement everyone could live with, not necessarily everyone's first choice). Stakeholders: engineering leads, product, security, support. Criteria we agreed in advance: security support horizon, hiring pool, migration effort, risk to roadmap dates, and ability to run old and new side by side. In the session each criterion got a weight and each option a 1 to 5 score (higher is better; illustrative):

Example, incremental: 0.25x5 + 0.15x4 + 0.20x3 + 0.25x4 + 0.15x5 = 1.25 + 0.60 + 0.60 + 1.00 + 0.75 = 4.20.

• Weighed future-proofing against migration cost. A full rewrite looked clean but would have frozen features. We chose an incremental approach, often called the strangler pattern after a vine that gradually replaces its host tree: new screens are built in the new framework from now on, and old screens are moved over in the order the roadmap will touch them, so the old code shrinks over time while both run side by side. Screens a roadmap feature changes are migrated as part of that feature; the rest are migrated by the dedicated 25% slice described below, so the migration has a finish date instead of waiting indefinitely for a feature to touch each screen. The extra cost of this path is running two frameworks in parallel until the end.
• Recorded the decision in an architecture decision record with revisit triggers.

Worked example of the cost arithmetic (illustrative numbers)

40 screens at about 1.5 engineer-weeks each is 60 engineer-weeks. Dedicating 25% of an 8-person group is 2 engineers of capacity, so migration takes about 30 weeks (60 / 2). The screen-by-screen effort is the same either way: 60 engineer-weeks, before the overhead of running two frameworks in parallel, which the incremental path adds and which I would estimate separately rather than ignore. A full rewrite would have been faster on the calendar (60 / 8 = 7.5 weeks with all 8 engineers) but would have meant a feature freeze (no new features while everyone rewrites) and one risky switchover, which the market-expansion roadmap could not absorb. The incremental path takes longer (30 weeks) but 6 of the 8 engineers keep shipping roadmap features every week.

Why this counts as a multi-year decision

The migration itself was about 30 weeks, but the decision was the multi-year part: choosing the front-end platform that the company expected to build on for at least the next five years, with revisit triggers set in the decision record (for example, if the vendor's support horizon or the hiring pool changed) and a review of the choice at roughly 18 months. The 30-week migration was the first phase of living with that choice, not the whole of it.

Result and what I would do differently

The migration finished alongside the roadmap, with no feature freeze. The qualitative result: security patches resumed and onboarding got easier. What I would do differently: bring support and security into the criteria workshop from day one, and publish a mid-point checkpoint so leadership saw progress sooner.

Pitfalls

Do not claim precise outcome metrics you cannot back up. Say what you personally decided, what you influenced, and where you were wrong.

Direct answer

For a small consumer mobile app team I would pick week-4 retention of new users: of the people who install in a given week, the share still active four weeks later. It rewards what a small team actually influences (a clear first experience, stability, speed, features worth returning for) and it tracks revenue and growth in most consumer apps because users who return are the ones who subscribe, buy or invite others.

Why this one

• It is hard to inflate without helping users: opening the app once is not enough, they must come back.
• It is a single number a team can see, and it covers onboarding, performance and feature value together.
• It is a product-outcome metric rather than a classic delivery measure. Delivery measures such as lead time (how long a change takes from commit to users) or deployment frequency show whether the team ships smoothly, but not whether what it ships matters to the business, and a small team can raise them without helping a single user. I pick retention because the question asks for contribution to business goals, and I keep a delivery measure beside it as a health check.
• Alternatives are weaker for a small team: installs depend on marketing, revenue lags and is lumpy, and release counts measure activity.

How to calculate it

Take a cohort (everyone who installed in one week), define "active" as at least one session in the target week, and compute active users in week 4 divided by cohort size. Example: 2,000 installs in the week of 2 March; 640 of them have a session in the week of 30 March. Retention = 640 / 2,000 = 32%. Track it per weekly cohort so a change in the app can be tied to the cohorts that saw it.

One way it can mislead you

Acquisition mix (the blend of channels users come from). If marketing runs a cheap campaign that brings in low-intent users, retention drops although the app did not get worse; if it stops paid installs and only loyal organic users (people who found the app on their own, through store search or word of mouth, rather than through ads) remain, retention rises although nothing improved. Before crediting or blaming the team, split by install source and compare like with like. Also read it with its noise. A cohort of 2,000 is only a sample of the people who might have installed, so the measured 32% wobbles from week to week by chance. The standard error is the typical size of that wobble:

standard error = sqrt( p x (1 - p) / n ) = sqrt( 0.32 x 0.68 / 2000 ) = about 0.0104, i.e. 1.0 percentage point

A 95% interval is the range that would contain the true value about 95 times in 100, roughly 1.96 standard errors either side: 32% plus or minus about 2 points. Comparing two weekly cohorts doubles the noise variance (the difference has a standard error of about 1.5 points, so plus or minus about 2.9 points), which is why a 1-point move week to week is not evidence of anything.

Trade-offs

Retention lags by a month, so keep a quick-feedback companion for release decisions: crash-free sessions, the share of app sessions that end without the app crashing. What would change my pick: if the app is a one-time-use utility, use task completion rate instead.