What My MBA Is Teaching Me About Product Thinking

Six Months In

I'm far enough into the MBA now to have opinions, and honest enough to admit some of them are still half-formed. This isn't a "here's what product management is" piece — plenty of people more qualified than me have written that. It's closer to a progress note: what's actually landing, and what still feels foreign.

The Frameworks I Didn't Expect to Use

Going in, I assumed the useful part would be the vocabulary — roadmaps, personas, the language of product work. What's actually turned out to matter more is something closer to structured decision-making: how to lay out a problem, its constraints, and the tradeoffs between options before committing to one.

That sounds obvious written down. It wasn't obvious in practice, because engineering had trained me to solve the problem in front of me, not to first ask whether it was the right problem. A root-cause analysis on a failed drive doesn't require you to question whether fixing the drive matters. Product decisions require exactly that question, every time, and I'm still building the reflex to ask it before reaching for a solution.

Where Engineering and Product Actually Overlap

Root-cause analysis and product discovery are structurally similar: both start by refusing to accept the first plausible explanation. In maintenance work, that meant not stopping at "the drive failed" — you keep asking why until you hit something you can actually act on. In product coursework, the same instinct applies to "users want X" — the useful question isn't whether they said it, it's why they'd feel that way, and whether solving for it actually moves anything that matters.

Where the overlap breaks down is speed and certainty. Engineering problems usually have a checkable right answer — the system either passes the test or it doesn't. Product decisions rarely do. You commit under uncertainty and find out later, sometimes much later, whether you were right. That's the part of the discipline shift that hasn't gotten comfortable yet.

What Still Feels Uncomfortable

Ambiguity, honestly. Four years of maintenance work trained me to want a clear failure mode and a clear fix. Product strategy case studies rarely resolve that cleanly — the "right" answer is often a matter of judgment, informed by frameworks but not determined by them. I notice myself still looking for the equivalent of a root cause in situations where there isn't a single one.

I don't think that discomfort is a problem to solve quickly. I think it's the actual skill being built, and skills built through discomfort tend to be the ones that stick.

What I'm Applying Right Now

The most useful test of any of this has been Flashly — not because it's far along, but because it forces the coursework to meet a real, if small, decision. Every time I have to decide what Flashly should do next, I notice whether I'm reasoning like an engineer (what's technically the cleanest path) or reasoning like the MBA is asking me to (what actually matters to the person using it). Most days, it's still a conscious switch rather than a natural instinct. That's fine — six months isn't supposed to be enough for it to be natural yet.