I Stopped Thinking Like an Engineer. Here's What Changed.

I trained as an engineer. For four years, being useful meant shipping code. When I started scoping products end-to-end - Mithivoices, the CRM, FitWardrobe - my instinct was still to open an editor within an hour of hearing an idea. That instinct kept betraying me.

On Mithivoices I built a real-time WebSocket pipeline before I had a single answer to 'who needs sub-450ms voice translation, and what breaks in their life today because they don't have it?' The pipeline worked. Nobody I could name was waiting for it.

The engineering mindset - 'I can build this, therefore I should' - is a superpower when the problem is well-defined and a liability when it isn't. Most product problems aren't.

I read a lot of PM writing that felt hollow - vague talk about 'customer obsession' without a description of the muscle involved. Two things landed. First: Marty Cagan's framing of discovery and delivery as two different jobs, not two phases of the same job. Second: watching senior PMs reject strong technical answers in interviews because the candidate had skipped the user entirely.

Neither gave me a framework. Both told me a habit was missing.

I made a rule: before I open any editor or design tool, I write down three answers in a single paragraph. Who is this for, in a way I could point at? What behaviour would change in their week if this worked? What is the single riskiest assumption I'm about to make?

If I can't finish that paragraph in ten minutes, the idea isn't ready. The editor stays closed.

Roughly half the ideas I would have coded never got past this check. The other half shipped faster and with sharper scope, because the constraints were already written down.

I said no to myself earlier, which is cheaper than saying no to a team later. I threw away less work. And counterintuitively, my technical background became more useful, not less - once I stopped defaulting to 'can I build this?', I could use engineering intuition where it actually paid: spotting when a plan hid a hard latency problem, or when a 'simple' AI feature was one prompt away from an unbounded eval nightmare.

I still build too fast sometimes. The habit is maybe two-thirds formed. What's different now is that I notice it happening - usually around the second hour of writing code for something I haven't validated yet. That awareness doesn't always stop me. But it means the damage is smaller.

The shift wasn't 'stop being technical.' It was 'stop leading with the part of the work I enjoy.' Those are very different instructions.