Product Manager (App Owner)

You don't write PRDs and hand them off. You open Claude, spin up the prototype yourself, and show up to the eng meeting with a working thing instead of a doc. You've shipped software, maybe as a founder, maybe as an engineer who drifted into product, maybe as the PM everyone knew could actually build. If your instinct when you spot a product gap is to schedule a meeting about it, this isn't for you.

Founders School is a 4-year program where students build real companies targeting $1M in profit by graduation. The entire program runs on software we build ourselves: apps for building a business, growing an audience, developing real expertise, and tracking progress. That ecosystem is the product. It's how we teach entrepreneurship and how we prove the program works.

We're hiring Product Managers who each own one app in that ecosystem, end to end. Not a slice of a feature area. The whole app: its users, its roadmap, its quality, and whether it actually moves students toward a real business. You'll be the person who knows your app better than anyone alive.

The Role

You own a single app in the Founders School software ecosystem, such as the CoFounder App (business-progression rails from one-liner to scale), the Followers App (daily posting and an in-app coach that diagnoses what's working), or the Expertise App (a layered knowledge graph that proves genuine expertise). Which app you own depends on fit and where we need the most horsepower.

You're with the students every week, watching them use your app and understanding where they get stuck before they can say it. You're with the program team, turning how we teach into what your app has to do. And you're with engineering, turning all of that into shipped features on a weekly cadence. You build alongside the engineers, not just direct them.

What you will be doing

• Sitting with students as they use your app, in the building, watching real usage instead of reading survey results. You know why a student abandoned a feature before the analytics do.

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

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

• Owning your app's roadmap and cadence. You decide what ships next, cut scope ruthlessly, and keep it moving weekly.

• 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.

• Keeping your app's connections to the rest of the ecosystem clean, so data and flows between apps don't break.

What you will NOT be doing

• Writing PRDs and throwing them over the wall. You build.

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

• Spreading yourself across every app. You go deep on one.

• Coaching students on their businesses. Guides own that. You learn from students; you don't mentor them.

• Inventing the pedagogy. How we teach is the team's call. You turn it into product.

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

What this looks like in practice

Monday in the student space. Three students are stuck on the same step in your app and the app isn't helping. You watch two of them hit the wall, 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 it. Thursday it’s live, and the next student gets through.

Wednesday with the team. A guide flags that families want to see their kid's progress in your app. You scope a view, prototype the core screen that afternoon, and by Friday engineering has a real spec plus a working reference to build from.

Friday shipping review. You know which of this week's changes students actually used, which one nobody touched, and which hand-off to another app broke and got fixed. You cut two things from next week because they don't move a student toward $1M, and add one that does.

The three things that matter most

1. Students can actually make progress on their business using your app. If they can't, that's the problem you own.

2. Your app ships fast and plays well with the rest of the ecosystem. Weekly cadence, clean hand-offs, nothing breaking downstream.

3. Your app is something families notice. When a parent sees what their kid built with it, it should be part of why they chose us.

What this becomes

At 6 months , your app has a weekly shipping rhythm, you know every flow and every drop-off, and the students using it daily would notice and complain if it got worse.

At 12 months , your app is a genuine strength of the program. The first cohort has made real progress on it, you've written the product playbook for it, and it's ready to scale to new campuses without you babysitting it.

As Founders School scales to more cities and thousands of students, each app becomes its own product line. This seat grows into leading that line, with your own engineers and the authority to define where it goes next.

Candidate requirements

• You are an AI-native builder. You ship working software with AI as your leverage. If you had to prove who you are, 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 that real people used, as a founder, an engineer, or a PM who genuinely built. Not "managed the roadmap for." Built and shipped.

• You write working code. You don't need to be a career software engineer, but you can prototype independently and hold your own with engineers.

• You can hold three groups at once (students, program team, engineering) and translate between them without losing the thread.

• You are willing to work on‑site (relocation support provided).

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

Nice to have

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

• Experience building consumer or education software where 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.

What we explicitly don't need

• A career PM who has never built anything and manages through process. We need a builder who can do product, not a product person who can't build.

• A K-12 education background. We're actively biased against it. When a student struggles, your instinct should be to open the laptop and fix the software, not explain the pedagogy.

• Big-company product experience without shipping ownership. We need zero-to-one, not optimize-the-machine.

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

#J-18808-Ljbffr Jobleads-US