Product managers are responsible for shipping things and have authority over almost no one. They can't assign work, can't fire anyone, and can't overrule the people doing the work. They ship anyway, through structure and clarity rather than power.
That is precisely the situation you're in on an MBA team. Which is why some of the PM toolkit transfers unusually well—and why the parts built for permanent teams mostly don't.
Why teams fail even when everyone works hard
The common diagnosis for a bad group project is that someone didn't pull their weight. Sometimes true. More often, the team organized around conversations instead of commitments: work discussed but never assigned, "finished" meaning different things to different people, scope quietly expanding while the deadline stayed put.
Those are the three failures the PM discipline exists to prevent. Take those three ideas and leave the rest.
Idea 1: Write the definition of done first
This is the highest-value habit on the list. Before anyone starts, write down what "finished" means for each deliverable—concretely enough that two people would agree on whether it's met.
Not "market analysis section." Instead: four to five pages, three named competitors with sourced share figures, one exhibit, recommendation stated in the first paragraph, formatted to the deck template.
Most rework on student teams isn't caused by anyone being lazy. It's caused by one person delivering exactly what they thought was asked, and the team needing something else. A definition of done is ten minutes of writing that prevents a week of that.
Idea 2: One owner per deliverable, and say it out loud
Shared ownership means no ownership. Two people "on" the financial model produces either duplicated work or a mutual assumption the other started.
Every deliverable gets exactly one name attached—the person accountable for it existing and being done, not necessarily the only person touching it. If that sounds like a responsibility matrix, it is; there's a lightweight version that fits student teams without the corporate overhead.
Say ownership out loud at the end of every meeting. "So Marcus owns the model by Tuesday, Aisha owns the competitor section by Wednesday." Ambiguity dies in the restating.
Idea 3: Defend the scope
Scope creep on a student team rarely arrives as a decision. It arrives as enthusiasm: someone finds an interesting dataset, someone else thinks a fourth case would strengthen the argument, and nobody wants to be the person who says no to a good idea.
The PM move is to make the trade explicit rather than refuse: "We can add the international comparison if we cut the sensitivity analysis or move the internal deadline out two days. Which?" Framed that way it's a normal choice, not a rejection—and about half the time the person proposing it decides it isn't worth the trade.
A rhythm that fits a term, not a company
Ceremonies designed for full-time teams collapse when applied to five people with classes and jobs. Daily standups are the classic mistake: they assume enough changes in 24 hours to be worth reporting. On a student team it usually hasn't.
What works:
- Kickoff (60 minutes, once). Scope, definitions of done, owners, deadlines, and how you'll communicate. This is the meeting worth its full length.
- Weekly check-in (25 minutes). Blockers and decisions only. Status belongs on a shared board nobody has to attend a meeting to read.
- Integration session (before the deadline, scheduled at kickoff). The point where pieces become one artifact. Teams that don't schedule this discover they needed it at midnight.
- Retrospective (20 minutes, after each major deliverable). Only worth it if it produces one or two behaviour changes; the format matters more than the intention.
Make status ambient
The reason weekly check-ins bloat is that people use them to find out what's happening. If deliverables, owners, and due dates live somewhere everyone can see without asking, the meeting stops being a status readout and becomes a decision forum—which is the only thing it's actually good for. Keeping that in one shared place is exactly what MBA Lab is built for, though a shared board of any kind beats reconstructing state from chat.
What not to borrow
Skip story points, velocity, and burndown charts. They exist to forecast a team's throughput over many repetitions—useful when you'll run twenty sprints together, meaningless when you'll run three and then never work together again. Estimating in hours, badly, is fine at this scale.
Skip elaborate tooling too. Whatever you pick, everyone has to open it voluntarily on a Tuesday night while behind on a case. A simple system people use beats a sophisticated one two people check.
The part that's genuinely hard
None of this gives you authority, and that's the real lesson the PM comparison teaches. When a teammate misses a deadline, structure tells you it happened—it doesn't tell you what to say. Clear owners and definitions of done make the conversation easier, because you're pointing at a shared agreement rather than a personal impression. But you still have to have the conversation, and no framework does that part for you.