Cheaper product cuts

Your superpower is knowing the cost surface of the codebase. Use it. Before you estimate a widget, ask who is hurting, what behavior should change, how you will measure success in 2–4 weeks, and what you have already tried.

If the ticket says "add a dropdown for export format" but the metric is "reduce time-to-insight for CS leads," a scheduled email of the existing report may win more than a new UI. That insight is product sense, and it is allowed from engineers.

The phrase that works

Yes — we can do the full version. Here's the cost (3 eng-weeks, new dependency, on-call risk). Here's an MVP that tests the same hypothesis in 4 days. Which outcome matters more this quarter: learning, or the complete UX?

Always attach cost and risk, not just "no." "No" without a path makes you a blocker. "Yes, and here's the bill" makes you a partner.

Useful MVP moves:

• Manual / admin-only path before full self-serve
• One segment of users before everyone
• Async job before true realtime
• Existing report + link before a new dashboard

Walking through co-editing

Request: "Build real-time co-editing for comments." Metric behind it: "Increase weekly active editors on shared docs." A spike shows true co-editing is a multi-quarter CRDT project.

Counter-proposal: presence indicators + faster refresh (5 s) shipping in two weeks. Measure whether collaboration complaints drop. If yes, fund CRDT later with evidence. Same goal; different appetite.

Reading a PRD like an engineer

When a PRD or spec lands, do not only skim the happy path. Scan for:

1. Success metrics and leading indicators
2. Non-goals and out-of-scope lists (missing → ask)
3. Edge cases: permissions, empty data, mobile, offline, localization
4. Rollout and experiment plan (who sees it, kill switch)
5. Open questions — offer to own the technical ones

Reply with a short eng note: feasibility, rough cost, risks, proposed MVP cut. That note often becomes the seed of the design doc. Silence reads as agreement.

Common mistakes

• Implementing the ticket literally while knowing it will not solve the problem.
• "No" with no path. Bring a cheaper test of the same hypothesis.
• Estimating the widget before asking the metric.
• Silence on a PRD. That reads as agreement.

Check yourself

1. The request is real-time co-editing. The metric is weekly active editors. What is a 2-week test? Presence plus a 5-second refresh. Fund CRDTs only if complaints actually drop.

2. A PRD has no non-goals. What do you do? Ask, then reply with feasibility, cost, risks, and an MVP cut. Silence is agreement.

Key takeaways

• Start from user problem and success metric, not the first proposed widget.
• Offer cheaper MVPs with explicit cost and risk.
• Useful cuts: manual path, one segment, async, existing report.
• Answer PRDs in writing.

Further learning

The Product-Minded Software Engineer (Pragmatic Engineer)Product-minded engineers are developers with lots of interest in the product itself. They want to understand why decisions are made, how people use the product, and love to be involved in making product decisions. The…The Pragmatic Engineer

Next, check the scary unknown with a feasibility spike.