Notes for Future Product Heads
- Tyler Hill
I wrote a large list of notes to myself while I was head of product. In the off chance that they will be helpful for future product heads, I have reproduced them below.
Before the Semester
Think about how many people you want, and the “engagedness” of your recruits.
Eg. 20 people who vaguely care about product, or 5 who are almost guaranteed to stick with you for the entire semester.
Also important for establishing how high-touch meetings and interactions are. Are these recruits going to be your friends, or is there a clear distinction in hierarchy?
Adjust your pitch for the above criteria.
Product is interesting because it has crossovers with every part of Nebula. Few engineers will want to be marketers, but everyone will be at least somewhat interested in product depending on how you frame the division.
Meet your recruits! Ask them about their goals and how Nebula can help.
Try not to make this so job-interviewy; this is something I failed on.
Many people will view Nebula through the gated application process and respond with formality. But it’s much better to have everyone relaxed and working somewhat informally. The intention is (at least for me) not to form a battalion of PMs - but to help people learn and have fun!
What is your goal for the semester? Mine was to teach everyone on my team how to think like a PM.
There are many others, ie. finishing a project, growing the organization, helping people make friends, introducing jobs/internships/industry speakers, etc.
Product is far more important than most people think. Without a functioning product division, things will not be done well, and everything will inexplicably feel harder.
How do you add the most value?
Week 1: What are we doing this semester?
Introduce the long-term project + goal (eg. Trends, Jupiter, etc.).
Introduce what we’ll be talking about this semester.
Show how we (the product heads) can add value to the team.
Ideologically, we are asking people to attend meetings, do good work, and contribute to the community. We must give an excellent justification for all this effort.
Many recruits may start the semester with tremendous motivation. How can we make their experience as good as possible?
Other things: team introductions, first assignment.
Best to keep meetings short and enjoyable, especially the first one; first impressions should not be ones of boredom and tedium.
Weeks 2 - ??: What is product?
Large range of possible topics here, from basic understanding, to case studies, to related topics, etc.
Not clear how to best structure meetings - lecture style? Interactive and discussion-based? Project-specific?
May be worth experimenting in the future.
If possible, best to build the habit of assigning one new assignment a week. Consider testing them beforehand to ensure they’re reasonable, and try to keep them simple; one hour max.
Assignments keep people engaged; generally it seems better to have easy (less useful) assignments with 100% completion rates than hard ones that fewer will do.
Also seems best to give feedback ASAP, directly noting good work when possible. People like seeing that their hard work was appreciated!
Projects
Trends
As of S25, core features of Trends are largely ‘done’. Future work seems to be composed of nice-to-haves, including AI-generated summaries of RMP reviews, course syllabi summaries, and fixing of misc. edge cases.
Mobile design, My Planner improvements, making the product more intuitive, more extensive marketing (particularly to non-ECS schools), and SEO are also all on the table.
Trends has historically run large, discussion-based meetings where all members are encouraged to give product suggestions. This is good! (but try to make sure that the product division also gets its say)
In other words, product is somewhat ‘replaceable’ for Trends - best to proactively look for places where product can be beneficial, rather than waiting for requests for help from project lead.
The latest version of Trends can be found at UTD TRENDS .
Jupiter
As of S25, Jupiter remains around ~35% away from launch (personal estimation). Progress is still needed on club searching (ie. tags), event/calendar scheduling, club backend (ie. how clubs add members, announce events, etc.), and general design/usability.
While this list looks quite extensive, I personally feel as though a minimal version of Jupiter could be launched within a semester.
Jupiter has historically not had many product needs, largely because development progress has been slow. That said, it may be worth chatting more extensively with the project lead to see what their vision for the project is (and coming up with ideas to help them bring that vision into reality).
Personally, I believe there are currently many areas where product could add value, from new features, to design changes, to feature prioritization, etc.
The latest version of Jupiter can be found at Jupiter - Nebula .
Communication
For Trends, Jupiter, and any future projects, it is currently essential that product leads have direct and frequent communication with project leads on what they want to accomplish, and how product can help.
Generally, people are quite good at coming up with design and engineering requests, but quite poor at articulating what they need from product. Often, they might not even understand what product does!
In other words: currently, product leads must create their own responsibilities!
This may change if product ever becomes fully integrated into projects, but I find this unlikely/ill-advised since project leads don’t tend to understand product as well as other divisions.
Team Structure
Product has an interesting structure currently:
It runs its own meetings, meaning product members are not easily integrated with projects, despite working on the projects themselves.
It generally runs autonomously (ie. no one tells product what to do, unlike marketing where requests + responsibilities from the rest of the org are very clear).
It has a cohort of returning members and new recruits, yielding widely different experience levels.
Not clear how best to account for these differences. Some ideas:
Have returning members attend project meetings. This somewhat integrates product with the rest of the org, and frees returning members from having to go through introductory product lessons.
Issues: project leads generally will not assign much meaningful work to product members, so product heads will have even more work to do. Product people in different projects will not know one another. Returning members may be less engaged.
Have returning members act as mentors for recruits. For instance, have them lead recruits in assignments, give lectures/presentations during the meeting, and generally act as mini product heads. This allows returning members to experience the ‘management’ side of being a PM.
Issues: hierarchy (do new members report to you or returning members?). Doesn’t solve the integration problem.
Have all members attend project meetings, ending product-specific meetings. Returning members can guide new members, who learn through experience. This completely integrates product with the rest of the org.
Issues: new members may struggle to learn upon being thrown into projects, particularly given documented struggle of project heads to give good assignments for product people. Product people in different projects will not know one another. Returning members may be less engaged.
Many other possibilities exist; personally, I currently think option 2 is the most promising, but experimentation is required.
Challenges
The greatest challenges of being head of product seem to be autonomy and responsibility.
There are many, many avenues for experimentation available to product heads that are not present in the rest of the org: curriculum, division structure, recruitment strategy, integration, etc.
It is not always easy to make the right choice, and often, it is not easy even making a choice in the first place.
For instance, how integrated should product be with the org? Personally, it is difficult to find any semblance of a ‘correct’ answer.
As Donald Rumsfeld once said, there are many unknown unknowns. Much time must be spent attempting to resolve these difficult issues (see: Staring into the abyss as a core life skill ).
Product heads juggle many responsibilities, many of which are largely self-imposed.
For instance, attending weekly project meetings - obviously not strictly necessary, and therefore it is easy to skip one or two when busy or overworked.
However, this has consequences: product will not be up to date with latest project changes. Assignments will be less relevant. To project heads, product will seem less engaged (and therefore future collaboration will be more difficult).
The true battle of being the head of product is the one against complacency.
Product largely has no deadlines, no hard responsibilities, and no overseer keeping score. And yet, for it to thrive, a large amount of work is needed to continually improve the division. If you do nothing for a week, no one will know.
If it wasn’t obvious, I struggled deeply with this idea - how easy it would have been to cancel meetings or come unprepared when midterms came around! And yet, how damaging would it have been for the division (and, by extension, the org as a whole)?
In its current form, success as product head therefore requires constant, (seemingly unnecessary) work to maintain the division. As the Chinese proverb notes: be vigilant in times of peace.
It is also worth noting that product is quite a thankless job.
When things are going well, the team shares the credit. And when things go poorly, it is your responsibility to fix them.
Often, your contributions will not be as visible as lines of code or Figma files. Nevertheless, your work matters! And without all the small, tiny changes you put forth, the product would undoubtedly be far worse.
Notes on Nebula (aka how to become a PM in the future)
To an extent scarcely understood by most, being head of product is functionally and optically equivalent to being a junior PM.
Many of the challenges faced by a PM (autonomy, missing context, prioritization, communication across teams, leading without authority, etc.) are all unintentionally replicated in Nebula’s framework.
Many of the goals (launching a product, data-driven conclusions, understanding users, earning credibility in a team) are likewise readily available to product heads.
While interviewing for full-time roles, I was largely able to answer my behaviorals exclusively with stories from my time at Nebula.
The above point implies a few things:
As it is currently organized, success at Nebula is strongly predictive of success as a PM.
To any competent hiring manager, any decent head of product will appear remarkably hireable.
For an average college student, being head of product is a challenge of significant difficulty.
Since I’ve already spoken in depth about the challenges, I thought I’d share a bit more about the first two points: becoming a PM after Nebula.
On one hand, this might be useful while looking for full-time roles; on the other, it should hopefully give some context to help plan what to work on + how you structure the product division with the future in mind.
Broadly, when speaking about Nebula I’ve found a lot of success in treating it the same way I would a startup.
This is a student org which is:
working really hard on something because they want to make the world (their school) a better place
extremely autonomous (no one tells you what to do, setting product roadmap by ourselves)
trying to move very quickly, iterating on product and speaking to users all the time
lacks hierarchy, very flat structure
pivots when necessary (eg. Trends as a ‘database’ in the past vs. Trends as a tool that makes decisions on users’ behalf now)
growing very quickly (Trends went from 0 to 12,000 users in two semesters, we’ve 5x’d the Trends and product team, 40% of the university relies on us to choose classes and professors)
If you can help interviewers understand these similarities, I think you’ll find that a lot of them will be quite interested.
I’ve noticed it’s often better to let interviewers connect the dots themselves (ie. rather than saying Nebula runs similar to a startup, say that it’s very autonomous, moves quickly, and grows rapidly, and let them draw their own conclusions)
The vast majority (~95%) of aspiring PMs have never launched a successful product in any capacity.
I interviewed exclusively at startups, where real impact is particularly important. Being able to say that I helped get a product from 0 → 12,000 users (and speaking about it convincingly) was often sufficient to land me a second interview on the spot.
In other words, being head of product makes you stand out, a lot.
Unfortunately, most interviewers must be shown this because most student orgs are useless and terrible.
Because of this, I think it’s best to talk about Nebula in conjunction with results (ie. we talked to users, built X feature, and saw users grow from Y to Z) so that people actually care.
I also think it is generally helpful to properly introduce Nebula before talking about specifics.
Personally, I always introduce it in my answer to ‘tell me about yourself’ so that interviewers immediately understand that this is a special, worthwhile organization.
Lastly, I think it’s best to ‘read’ into what a company is looking for before speaking about Nebula.
If it’s a high-growth startup looking for ambitious generalists, Nebula is literally the dream example to show that you would fit in (and they will very much care about your student org over traditional internships).
Otherwise, I would spend a lot of time thinking about how I want to be portrayed, and how Nebula fits into that portrayal.
Broadly, if you play your cards right, I genuinely believe that no successful head of product at Nebula should struggle to find a full-time role after graduation.
Some final pieces of advice for aspiring PMs
Learn to write clearly (perhaps the single largest differentiator of good and great PMs).
Never waste your teams’ time (even if it means you must waste yours!)
Think ten steps ahead of everyone else, and stay curious :D
And if, for some reason, you suspect that I could help with anything in the future, you can reach me any time at (602) 332 2725 or hi@spencer.ng.
Good luck!