What McKinsey's Forward Program Taught a CS Student About Business That Lectures Didn't

I was wrong in a specific, useful way — and it's a gap no CS lecture ever pointed out to me, because lectures aren't built to test it.

The gap between solving a problem and framing one

In CS, you're handed the problem. A bug, a spec, a broken function — defined, scoped, ready to be solved. Four years of that builds a very particular kind of confidence: give me the problem, and I'll solve it.

Forward Program exposed the assumption hiding inside that confidence. In real business situations, nobody hands you a clean problem statement. The actual skill — the one that determines whether you solve the right thing or just the first thing you noticed — is structuring an ambiguous, half-formed situation into a problem worth solving in the first place. That's not a debugging skill. It's a framing skill, and it doesn't show up anywhere in a syllabus that assumes the problem is already defined for you.

Where this actually showed up for me

A few specific shifts made the gap concrete instead of abstract:

• Structured problem-solving frameworks forced me to separate "what's actually going wrong" from "what's the loudest symptom" — a distinction I'd been skipping by instinct, not by skill
• Strategic communication wasn't about explaining technical decisions clearly. It was about deciding which decision even mattered enough to explain, to which audience, in which order
• Adaptive leadership assumes the plan will be wrong partway through — CS coursework almost never rewards you for planning around your own plan being incomplete
• Digital transformation, as a concept, only clicked once I saw it from the enterprise side — not "what tech should we use," but "what's actually true about how this organization makes decisions, and what does that mean for what tech can even succeed here"

None of that contradicts the engineering mindset. It sits underneath it, and most CS programs simply don't reach that layer, because the problems they teach you to solve are already pre-framed by someone else.

Why this matters more once you're the one building the thing

Here's where it stopped being theoretical for me. Running Bivoxo means I'm not just the engineer anymore — I'm also the person who has to frame the client's actual problem before a single line of code gets written. Get that framing wrong, and you can ship flawless engineering against the wrong problem entirely.

A perfectly executed solution to a badly framed problem is still a failure — it's just a failure that took longer, and looked more convincing while it was happening.

That's the sentence I keep coming back to. Technical skill tells you whether something was built well. Business framing tells you whether it should have been built at all, in that shape, for that reason. Lectures teach the first one exhaustively. Almost nothing in a standard CS curriculum teaches the second.

What changed in how I actually operate

A few concrete habits came out of this, ones I now apply on every build and every client conversation:

• Before scoping any technical solution, I now spend real time structuring what the actual problem is — not what it was first described as
• Communication gets planned with the audience's priorities first, not my own excitement about the technical approach
• I plan for the plan being wrong, instead of treating a changed requirement as a disruption to a "correct" original plan
• I separate "is this technically impressive" from "is this the thing that actually needed building" far more deliberately than I used to

The combination is the actual advantage

I don't think the answer is choosing between technical depth and business thinking — it's refusing to let either one cover for the other. My engineering background means I can actually build what I decide is worth building. The frameworks from Forward Program mean I'm far less likely to build the wrong thing well.

That combination is exactly what I bring into every product decision now, whether it's my own venture or a client's at Bivoxo: structure the problem like a strategist, then build the solution like an engineer. Lectures gave me the second half. It took stepping outside the classroom entirely to get the first.