Product Manager (Founders Software Stack)

• Sitting with students as they use the software - in the building, watching the actual usage, not reading survey results. You are the person who knows why a student abandoned a feature before the analytics do.

• Translating the program's teaching philosophy into product. When a guide says "students aren't getting past the validation stage," you turn that into a shipped change in the CoFounder App, not a note in a doc.

• Prototyping features yourself. You build the first version - a working prototype, a real UI, a functioning flow - and bring it to engineering as a starting point, not a wishlist.

• Owning the roadmap and the cadence. You decide what ships next, you cut scope ruthlessly, and you keep the whole stack moving on a weekly rhythm.

• Working shoulder-to-shoulder with engineering. You're in the codebase enough to have real conversations, review the shape of a feature, and unblock decisions in real time.

• Holding the three apps together as one system. The inter-app contracts - how expertise feeds the audience app, how both feed the business rails - are yours to define and defend.

• Writing PRDs and throwing them over the wall. If your model of product management is "gather requirements, write the spec, wait for eng" - this is the wrong job. You build.

• Running a Jira board as your primary output. Process serves shipping here; it doesn't replace it. Anyone can groom a backlog.

• Coaching students on their businesses. The guide team owns that. You own the software they use - you learn from students, you don't mentor them.

• Managing a large team. For the foreseeable future you are an individual builder-operator working directly with a small eng team, not running a PM org.

• Inventing the pedagogy. How we teach entrepreneurship is the team's call. You turn that pedagogy into product - you don't rewrite it.

• Sitting remote. This role is in the building with the students and the team.

Monday morning in the student space. Three students are stuck on the same step in the Expertise App - they can't tell the difference between an insight and a position, and the app isn't helping. You watch two of them hit the wall, you talk to the third, and by Monday night you've prototyped a revised flow with a worked example baked in. Tuesday you walk engineering through the working version. Thursday it's live and the next student who hits that step gets through it.

Wednesday with the team. Cameron flags that families in the sales process keep asking how they'll see their kid's progress. There's no parent-facing view of the CoFounder rails. You scope a dashboard, prototype the core screen that afternoon, and by the end of the week engineering has a real spec plus a working reference to build from - not a paragraph of requirements.

Friday shipping review. You've got the week's changes across all three apps in front of you. You know which ones students actually used, which one an EIR asked for that nobody touched, and which contract between the Audience and Expertise apps broke and got fixed. You cut two things from next week's plan because they don't move a student toward $1M, and you add one that does.

1. Students can actually build a business on the software. The stack is the medium through which we teach. If a student can't get from one-liner to real revenue using these tools, that's the problem you own.

2. The stack ships fast and works as one system. Weekly cadence, three apps behaving like one product, contracts that don't break. Velocity and coherence are both your number.

3. The software is a reason families enroll. When a parent sees what their kid builds and how they build it, the product should be part of why they choose us. You make the software good enough to sell the school.

At 12 months, all three apps are shipping on a tight cadence, they work together as one system, and the first cohort of students has built real businesses on top of them. You know the stack cold - every flow, every drop-off, every contract between the apps - and you've built the product playbook the program runs on.

As Founders School scales to more cities and more students, this role grows into Head of Product for the entire software stack - hiring the product and engineering team, owning the platform that every campus runs on, and defining what the product becomes as the program goes from 20 students to thousands. You're getting in early enough to write that from the ground floor.

• You are an AI-native builder yourself. You ship working software with AI as your leverage - prototypes, real UIs, functioning flows. If you had to prove who you are as an operator, you'd share your screen and build the thing live, not walk us through a slide. This is non-negotiable.

• You have shipped real software products that real people used. As a founder, an engineer, or a PM who genuinely built. Not "managed the roadmap for" - built and shipped.

• You are fluent enough in code to work directly with engineers, review the shape of a feature, and prototype independently. You don't need to be a career software engineer, but you write working code.

• You can hold three constituencies at once - students, program team, engineering - and translate fluidly between them without losing the thread. Product sense plus people sense.

• You are willing to work on-site in New York City (relocation support provided).

• You are legally authorized to work in the United States.

• Background as a founder or an early product hire who built a product from zero to real usage.

• Experience building consumer or education software where the user is the whole point and the usage data is unforgiving.

• A visible body of work - shipped apps, open-source tools, products you can point to and say "I built that."

• Prior experience working with or building for young people.

• A career PM who has never built anything and manages through process. If your value is coordination, not creation, this is the wrong role. We need a builder who can do product, not a product person who can't build.

• A K-12 education background. We are actively biased against it. If your instinct when a student struggles is to explain the pedagogy, you'll fail here. We need someone whose instinct is to open the laptop and fix the software.

• Big-company product experience without shipping ownership. Running a feature area inside a 200-person product org is a different job. We need zero-to-one, not optimize-the-machine.

• Anyone who needs a fixed roadmap handed to them. This role is undefined on purpose. You define it, week by week, from what students and the team need.

• Anyone who needs to be remote. There is no remote version of this role.