What if I told you you could piece together your own degree in Product Management at the school you’re attending right now? Almost no schools have any formal coursework that teach product management, but that doesn’t mean you can’t utilize your resources to develop your own, personal education. After all, part of being a PM is making the most out of whatever resources you have on hand 😉. Here’s a three-step process you can replicate on your own campus to start your career as a product manager:
- Learn to code functionally: Most CS degree requirements take a holistic approach to computer science. While this is doubtlessly valuable, you need to find ways to optimize your early learning for product success.
- Find space to communicate: Communication, influence, and empathy are required skills for the job, but as class learning objectives, they’re implied at best. Get yourself into positions where success depends on your ability to communicate effectively and influence fellow students, without using authority.
- Take advantage of the built-in startup accelerator: As a college student, you’re at the intersection of a couple amazing situations.
- You have freedom to control your schedule
- You have free and unlimited access to a user population that you understand extremely well, because you’re one of them
- You’re bound to find fellow like-minded, motivated students. This is the startup accelerator you’ve already been admitted to. Put it to good use.
The programming that got me my first internship and my current APM role wasn’t taught in class. My school didn’t offer iOS development or Web App development, so I taught myself how to build these in order to satisfy my creative itch. What I’m advocating is essentially “hacking”, which in some ways is the opposite of what a degree program offers.
Over my four years in college, I learned the basics of almost every computing concept in existence (it helps to study a field that’s only existed for 50-some years). Professors taught using lesson plans, prepared slides, and most notably, polished and sanitized coding assignments. Some of them even had large blocks of comments directing me where to write my code.
As a result, after a full year of classes taught in Java, I sat down in front of my computer to write a quick Java utility only to find I didn’t know how to run my code from scratch.
It was embarrassing.
In programming and UX, there’s the notion of the “happy path”, the path that if a user follows, every bit of the experience will be optimized. This leaves the implicit “unhappy path”: errors, forgotten cases, and options that were deemed “not important enough”.
The problem with my CS curriculum wasn’t its content — it was its strict adherence to the happy path. The happy path was only thinking about assigned problems, problems with known solutions and answer keys. It was being given starter code, clearly structured to guide you towards a working implementation. It was getting to start over with a new code base every two weeks, never enduring effects of tech debt, prioritization mistakes, and files littered with
Hacking is the opposite. If an academic curriculum is a DFS into a class’s subject matter, hacking is a BFS over all of software, a self-led exploration of the hidden, messy, and interesting. So how do you start?
- Don’t just look for your destination — look around along the way. Hacking is wandering: there’s no application in mind. A tool that you fiddle with then discard, a framework you evaluated but decided against. These all expose you to the world of what exists, of what’s possible. These tools may not get used in your current project, but they’ll float to the surface when the time is right. The experienced programmers you encounter didn’t amass their library of knowledge by reading lists of “Best X for Y”; they built it up by taking notes on interesting bits along their journey.
- Embrace the chaos. Hacking produces messy, ugly code. Here are some things that will happen along the way:
- After building your own library, you find a repo on Github that solves your problem along with edge cases you hadn’t even thought of
- After refactoring your architecture, you find that your original architecture was better
- After writing a component, you realize you could’ve slightly abstracted an existing component and solved both problems
- Never stop. So little of current tech products are based on advancements in technology. For the moment, we’re all working with the same basic constructs, repackaged in imaginative ways. There’s a tired joke about “spending longer automating something than it took to do by hand”. It’s funny, but it reflects the mindset that the most prolific creators have — always looking for the types of problems that can be solved with code. Not everything will be useful, not everything will be efficient, but that’s okay. If it could be that formulaic, it would’ve been taught in school.
The two most challenging classes I took in school were those “the whole class forms a startup”-type classes. It wasn’t difficult because of the assigned problem statement, or the engineering challenge it presented. It was difficult because we couldn’t move.
At the beginning of the semester, we self-organized into a familiar hierarchy — a “product manager” and “project manager” leading the class, followed by various “engineering teams”, each with their own “team lead”.
There were many now-laughable issues that doomed the classes, but a big one was the fact that no one really knew what we were doing, on many different levels.
I served as a team lead for a semester and about halfway through, I lost track of what each team member was doing. My daily status reports were vague because my understanding of the team’s status was also vague. And I was supposed to be the “lead”.
We didn’t know what our PMs wanted, when they wanted it, or why they wanted it. Later when I was a PM for another class, I was so lost that every answer I gave was ad hoc, leading to confusing, contradicting, incohesive visions.
As a class, we were all friends, some even best friends, but as a company, no one knew a thing about each other.
Communication is often talked about with reference to presentations, meetings, writing PRDs. Sometimes you’ll hear about tricks for emails, calendars, and Slack. I’m not discounting the value of these skills — a good PM should be the master of all communication mediums — but these are things you’ll figure out quickly.
What’s trickier is the content of your communication. Put yourself in roles where your main job is a communicator, and you’ll learn how to improve your content.
As a team lead, I learned that when I got lost, I gave up. Now I’m relentless about getting answers until I’m satisfied. I make others communicate with me so I can communicate better with others.
As a PM, I learned that putting out fires isn’t sustainable. Sure you can give everyone an answer, but you’re better off giving everyone a vision and empowering them to answer the questions themselves.
While you’re in school, you have the safety net to fall back on so you can learn your lessons about how you communicate. Find a club, a class, an informal group, and position yourself in the center of the communication structure. As a PM, communicating isn’t just about talking. It’s about figuring out what you need to hear and what others need to hear.
Your Built-In Startup Accelerator
True or false: Lectures, assignments, and exams are the most important parts of college.
You can probably already see where I’m going.
Let’s try and tease out what college’s differentiator is.
Textbooks can be bought, lectures can be recorded, and assignments can be found on other college’s websites, so the actual class apparatus probably isn’t what’s unique about college.
Professors are smart and know how to explain things, and TAs are like mini-professors. Getting feedback in the form of a graded assignment takes someone’s effort and time, so graded assignments and office hours are a privilege. But how often do you correct the mistakes in your project after getting your grade?
The access to the above resources probably is the college differentiator for a lot of majors. The insights those professors have are probably renowned in their fields, and hearing it from them is a legitimate advantage.
But not in CS.
Let’s set aside academics, and try to view college from a PM’s perspective.
For starters, students are no longer students, they’re users. And what’s incredible about these users is that along a lot of broad axises, they are all the same demographic. Sure there are variations in socioeconomic status and major, but look at the similarities.
Everyone is in the same geo. Everyone is the same age. Everyone has the same broken sleep schedule, goes to the same spots on campus, eats at the same restaurants, and perhaps most importantly, everyone has the same goals: To have fun, and to get a job.
You won’t find a more perfect group of users.
Let’s set aside the users, and view college from a founder’s perspective.
You’re trying to start something. You have an idea, a passion to build, and need someone like you to come along for the ride.
Why did you come here in the first place? People like you don’t just randomly make decisions; something about your school drew you in. Was there a particular lab, professor, or class? Was there a program or an institute? Whatever it is, find it, and you’ll find more people like you. There’s your cofounder.
There will always be people who have ideas, people who want to achieve beyond a class assignment, people who are just like you.
College is a fantastic incubator of ideas because it combines founder-like students, the easiest user base you can imagine, and an abundance of time to build. It’s an unbelievable opportunity — go do something with it.