Own the Problem, Not the Task
Entrepreneurial thinking for engineers who want their work to matter
🧭 Why this matters
Most teams execute tickets. High-leverage teams own problems. That one shift changes everything: velocity, product-market fit, morale, and trust with stakeholders. “Entrepreneurial thinking” doesn’t mean being a mini-CEO; it means acting like a builder who cares about impact more than output—and proving it with evidence.
🔄 Task vs. Problem (with real examples)
Tasks describe activities. Problems describe outcomes we’re trying to change.
Consumer app
Task: “Add a Share button.”
Problem: “Increase organic referrals per user from 0.2 → 0.5 in 30 days.”
Outcome paths: Share button, referral code in receipts, post-purchase nudge, deep links.
B2B SaaS
Task: “Create a CSV export.”
Problem: “Cut partner handoff time 12 min → 2 min with <1% errors.”
Outcome paths: CSV, webhook, secure shared view, scheduled email.
Internal tooling
Task: “Add retry logic to job.”
Problem: “Reduce failed nightly runs 8% to <1%; on-call pages 4/wk to ≤1/wk.”
Outcome paths: retries, idempotency, backoff + alerting, input validation upstream.
When you frame the problem, you unlock multiple simple solutions and pick the cheapest one that moves the needle.
🧪 MVE > MVP: Learn faster with smaller bets
We love “MVPs,” but they can still be months. An MVE (Minimum Valuable Experiment) answers one high-value question this week.
Question: “Will managers use automated status summaries?”
MVE: 10 users get a manual summary for 5 days. Measure opens/replies.
Decision: If engagement >30%, automate. If not, reframe the problem.
MVEs de-risk direction without committing to architecture too early.
🧰 The Owner’s Toolkit (copy/paste templates)
1) Problem Statement (Who / Pain / Evidence / Target / Horizon)
Who: Who is stuck?
Pain: What hurts? When/where does it show up?
Evidence: Tickets, metrics, quotes, recordings (2–3 bullets).
Target: From A → B (one number) + guardrails.
Horizon: When will we know? (1–4 weeks)
Example
Who: Ops coordinators sending manifests to partners.
Pain: Manual copy/paste; 3% errors; delays.
Evidence: 37 tickets in 60 days; avg 12 min per handoff.
Target: 12 → 2 min, errors 3% to <1% in 4 weeks.
Horizon: First readout in 10 business days.
2) Five 15-Minute Calls (the fastest discovery loop)
Example questions to ask:
“Walk me through the last time this hurt.”
“What did you try first?”
“How do you usually do this? Do you use any workarounds?“
“If I could fix one thing this week, what should it be?”
“Is anything slowing you down?“
“What would make this a ‘wow’ for you?”
Take verbatim quotes. You’ll reuse them to drive alignment.
3) MVE Menu (pick one)
Manual concierge (do it by hand once)
Paper/Loom demo (watch clicks, ask “What next?”)
Feature flag for 5 users
Script + one-time run + before/after timing
Shadow workflow (measure, don’t change UI)
4) Evidence Pack (90 seconds to trust)
1 chart (North Star) + 1 guardrail (stability/quality)
1 screenshot or 30-sec Loom
3 bullets: What we tried / What changed / What’s next
Repeat weekly; evidence compounds.
📊 Measure what owners measure (simple, not fancy)
North Star (one number): the outcome we’re moving (time saved, conversion, error rate, on-call pages, referrals, etc.).
Guardrails (two max): ensure we don’t harm stability/quality/customer satisfaction.
ROI sketch:
Build cost: 5 engineer-days.
Value: 1,200 manifests × 10 minutes saved = 200 hours/month.
Payback: <1 week.
Talking in payback wins runway and autonomy.
Instrumentation, minimal edition
Add a start/stop timestamp (duration), success/failure flag, and user cohort.
Log to whatever you have (db table, Amplitude, CloudWatch, Sheets if you must).
Capture baseline for one week before you launch.
👥 Three mini case stories
1) Support reconciliation (internal)
Problem: 6 hours/day chasing missing order IDs.
MVE: Background matcher + 1-screen dashboard for 5 agents (2 weeks).
Result: 6 → 2 hours/day, CSAT ↑, tickets or bugs ↓35%.
Next: Notifications, expand match rules, retire manual export.
2) Onboarding drop-off (SaaS)
Problem: 42% mobile drop-off at step 2.
MVE: Inline validation + auto-save + single CTA (1 week).
Result: Drop-off 42% → 29%.
Next: Social login test; follow-up email for abandons.
3) Developer velocity (platform)
Problem: New service setup takes 2–3 days.
MVE: “One command” template (repo scaffold + CI + observability) for 3 teams.
Result: Setup 2–3 days → 2 hours; fewer PR stalls.
Next: Bake into golden path; maintain versioned template.
Each started with a problem, not a “cool idea.” Each produced evidence first.
🧱 Team habits that create entrepreneurs (without chaos)
Problem-first backlog
Rewrite tickets as outcomes: “Reduce handoff 12 → 2 minutes” (+ suggested approaches below).
Keep “discovery” tickets alongside build.
Friday “Wins & Proof” (15 minutes)
Each stream: 90 seconds → chart + screenshot + 3 bullets.
Replace status theater with evidence.
Customer-in-the-room
One user demo or 15-minute chat per sprint. Engineers ask questions, not just PMs.
Guardrail agreements
We ship small behind flags.
We instrument what we change.
We don’t add permanent complexity for temporary certainty.
👥 What leaders and ICs can do each Monday
For managers/leads
Set outcome goals per stream (one number + guardrails).
Fund 10–15% capacity for discovery/MVEs.
Promote and praise outcomes and learning, not just scope or heroics.
Ask in reviews: “What did we learn; what changed; what did we retire?”
For ICs
Bring a problem statement to standup. Offer 2–3 cheap paths.
Propose an MVE you can ship in 5 days.
Share a before/after video every Friday.
Keep a 1-paragraph decision log (context, options, tradeoff, revisit date).
🚫 Anti-patterns (and how to repair them)
Ticket factory: Tasks with zero context.
Repair: Demand a problem statement; attach a simple metric and horizon.
Architecture astronaut: Designing for year 3 with no week-1 proof.
Repair: Defer generalization; ship one narrow path and measure.
Big-bang validation: Months of work before first user touch.
Repair: Prove demand with manual/flagged trials first.
Metrics theater: Dashboards no one uses to decide.
Repair: Tie each chart to a weekly decision. If none, delete it.
💬 Useful scripts
To a stakeholder: “If I could fix one part of this by Friday, what gives you the biggest win?”
In planning: “What number will move if we’re successful? What number must not get worse?”
In review: “Here’s the before/after and how we measured. Keep, expand, or kill?”
When pushing back: “I can build the generalized version, or ship a narrow slice this week and prove need. Which risk do we want to take first?”
📅 A 10-day starter plan
Day 1–2: Pick one high-friction area. Write the Problem Statement. Book five 15-min calls.
Day 3–4: Run calls. Choose one MVE. Baseline the metric.
Day 5–7: Build the MVE behind a flag or as a manual concierge.
Day 8–9: Collect evidence. Prepare the 90-sec Evidence Pack.
Day 10: Demo “Wins & Proof.” Decide: expand, adjust, or retire. Repeat.
🧠 Final thought
Entrepreneurial engineers don’t wait to be told what matters—they make it obvious. They trade tasks for outcomes, opinions for experiments, and ceremony for evidence. Do that consistently, and your work won’t just get done—it will change something.
Own the problem. The tasks will follow. And so will the impact.