What playing investor for a day taught me about developers and the business side

We ran a role-play with my team not long ago: a mock pitch to investors, and I sat on the other side of the table as one of the people deciding whether to write a check. My developers pitched their product to me, and what struck me wasn't their coding ability, which was genuinely strong. It was how many of them had never had to think about the business their code was supposed to serve.

That gap is worth taking seriously, because it's not really about presentation skills. It's about whether an engineer can operate as more than an implementer, whether they can see the decision behind the system they're building, not just the system itself.

Investors don't fund features, they fund a business

The developers who struggled in that role-play weren't short on technical substance. They were short on an answer to the one question every investor actually asks: how does this make money. Fundraising isn't a pitch about what the product does. It's an argument for why the underlying business deserves capital, and that argument depends entirely on understanding how the business runs, not just how the code runs.

A good pitch needs a story and a number, not just enthusiasm

I watched colleagues get excited describing their product as fast and polished, and watched that excitement land flat, because investors in the room wanted numbers, not adjectives. A pitch needs a story that hooks attention and evidence that backs it up, the same way a joke needs an actual punchline. Concrete numbers changed the room: not "we'll sell software" but "we'll sell a thousand units, and here's why." Vague enthusiasm about the tech signaled the opposite of seriousness. Specific numbers signaled it directly.

Numbers, operations, and customers: the parts code doesn't cover

None of that lands without three things developers don't automatically think about. Profit, loss, and market size are the concrete measures investors actually weigh, and a team that can't estimate them hasn't done the homework yet. Operations, who's on the team, how it's structured, what the hiring and growth plan looks like, matters because a pitch has to answer "how will this scale," not just "does this work today." And customers matter more than any of it: who's actually buying, what does that market look like, and are there external forces, even something as indirect as shifting weather patterns affecting outdoor gear sales, that could move demand. A product without a defined buyer isn't a business yet, no matter how well it's built.

Curiosity is the actual differentiator

What separated the strongest people in that room wasn't raw coding talent. It was a willingness to keep learning past the edge of their own discipline, to ask how the business actually works instead of assuming someone else would handle that part. That curiosity is what turns a good engineer into someone who gets included in decisions that shape the product, rather than someone who finds out about those decisions after they've already been made.

The code was never the whole job

The role-play didn't teach me that my developers needed to become finance people. It taught me that the engineers who eventually get pulled into the room where real decisions happen are the ones who started asking "how does this make money" long before anyone required them to. If you write code for a living, that question costs you nothing to start asking, and it's very often the thing that determines whether you stay an implementer or become someone the business actually consults.