Give the Business Major a chance đŸ„ș

TL;DR

You're going to build a side project anyway, so why not team up with a business person? You'll build something that might be useful to many people while learning a thing or two about business impact, teamwork, and working with the latest hot framework.

Meme about the friend with the million-dollar idea

Source: r/ProgrammerHumor

CS Majors!

That kid with the business idea?

Give them a chance.

I've been throwing this idea around with my friends ever since I briefly pivoted to product management last year, and the more I think about it, the more I believe it needs to be said:

You know that kid (usually a business major) who comes to you with a business idea they want you to "code up for them" (that's how they usually phrase it, lol)?

I'm going to go out on a limb here and say: Do it.

Look, you need to build projects for your portfolio anyway. Computer Science is a field that's unforgiving if you graduate without experience. The candidate with prior experience—even for internships—is more attractive than the one without. It's recursive.

The base case, I've found, is to start creating your own experience. Side projects aim to do this, but they tend to fall short in a couple of ways:

  1. Most Side Projects Are Useless: They don't solve any real need. They're usually done to learn the latest hot framework or to showcase your familiarity with it (usually both).
  2. Incompletion: Let's be honest—how many self-started projects have you actually finished? (Don’t worry, I’m just as guilty of this as the next guy)

By taking a chance on that business major, you gain a few advantages:

  1. Accountability: You're more likely to finish a project if you're accountable to someone else, not just yourself.
  2. Balanced Learning: You get to learn that hot new framework while gaining an appreciation for problems worth solving (i.e., problems that you can solve while making money—not all problems lend themselves to this). This appreciation, also known as "product sense," is often lacking in CS majors and software engineers alike. It's also why good Product Managers are paid a premium, much to the chagrin of many SWEs who think PMs are useless.
  3. Potential Earnings: You might end up making some money out of it. In the best-case scenario, you could make more money than a small nation (though I wouldn't hold my breath).

Honestly, reasons #1 and #2 are solid incentives on their own.

And I get it. Most business people seem to be looking for a "code monkey" to build their app for a pittance.

Well, for starters, business majors, cut that shit out! Both the tech and business sides are equally important (hot take, I know), so you should be aiming for something closer to a 50/50 split.

More importantly, you should screen the business person, just as they're screening you.

The business person knows you can code, right? It's not hard to figure out if someone knows how to code. They can check out something you've built in the past or have you write some code on the spot.

You also need to figure out if the business person knows what they're talking about. Here's how:

  1. Have they generated revenue before?
    • Great: Ran a successful software/product business (e.g., a school magazine).
    • Good: Flipped stuff on eBay or Mercari.
    • Not so good: Ran a lemonade stand in middle school (sorry!).
  2. Have they validated the product in any way?
    • Great: Created a landing page or a Figma prototype (a person can dream, right?).
    • Good: Conducted some customer discovery surveys.
    • Not so good: Their mom thinks it's a great idea.

A few others, such as whether they have a business model or business plan, are nice to have but not necessary.

If they at least score "Good" on these two metrics, I'd say go for it.

You were going to build your Rust-based social media app for dogs anyway; might as well team up with someone else to handle the stuff you're less interested in—like, you know, getting people to sign up and pay 😉

Notes:

  1. Advice for Business Majors: Feedback on early drafts encouraged me to offer some advice to business majors. The biggest gripe a lot of CS majors have is that the business major sees them as some sort of code monkey, often offering ridiculous 96/4 splits. Both business and CS majors need to understand that they play equal roles in the success of the business. Hence, the initial split should be 50/50.
  2. Do your homework: As a follow up to the above, prior to approaching a potential technical counterpart, try to validate the idea in some way: talk to potential users, try to set up a landing page--anything you can to prove that your idea is feasible, that it's something people actually want. This is going to be the core of your work during the partnership so it helps to get started early. The more of this you do beforehand, the more likely said tech person will hop on.
  3. Workload Concerns: Another piece of feedback is that building a fully fledged business is a lot of work compared to a personal project. While this is true and a legitimate concern, you can address it by continuously scoping features that take a few weeks to build. This ensures you're not overwhelmed—at any given point, you have just a couple of weeks of work to do. It takes practice to get this down. Michael Seibel (President of YC) has a good article on how they did this during the early days of Twitch.
  4. Entrepreneurship Classes and Hackathons: Paul Graham wrote a great essay on entrepreneurship for students. I don't agree with his take that entrepreneurship classes are useless. They are great avenues to have people help you work on your idea. Most are just taking it for a grade, but the incentives align so they'll at least pitch in to make slides or talk to some customers. Most couldn't be bothered to come up with their own idea, so this is typically a win-win situation—you get help; they get a good grade. I think the same can be said of hackathons. A strategic business person should go to venues like these and have people help them prototype their tool.
  5. I found these two to be interesting reasources that discuss the issue of a non-technical founder:

Special thanks to Daniel Munoz for ideating this piece with me.