Shipping a live classroom in 10 weeks
The brief: lead the first usable release of an interactive live-classroom product for MENA EdTech platforms, remote team, eight to ten weeks. Below is the whole reasoning chain: assumptions, personas, the questions I'd ask before building anything, four scoped stories, the flow, and who decides what when people disagree.
Originally delivered in Arabic; this is my own translation, tightened. Figma was used to draw the teacher flow and ChatGPT to tighten the language. Both were used to make the thinking legible, not to make the decisions. Company contact details from the original letterhead are omitted.
01Assumptions, stated before anything else
A plan with no stated assumptions is a guess wearing a suit. Every decision downstream inherits these, so they go first and they go in writing.
| Area | What I'm assuming |
|---|---|
| Market | Mid-to-large MENA EdTech platforms that already run an LMS and want an integrated live-classroom layer they can drop in over API/SDK. The market is moving toward purpose-built teaching tools and away from general meeting tools. |
| Users | Teachers have moderate technical fluency and use digital tools daily, but struggle to manage interaction in a live room. Students are on mixed devices and mixed bandwidth. Platform admins care about operational reporting and stability, in that order. |
| Technical | Enterprise architecture, scalable to many concurrent sessions without losing performance. Priority order: stream stability, fast API integration, data security. |
| Business model | Buyers evaluate on ease of integration, reliability, and direct effect on learning quality. Speed of implementation and lower support cost move the purchase decision. |
| Constraints | Five developers, two-week sprints, a short window to a usable first release. That forces a small MVP rather than a rhetorical one. |
02Two people, not "the user"
Fatma Hassan
Wants: an interactive session that feels like a real classroom, class time she can manage, and a live read on whether students are following.
- Fights: controlling interaction at scale, attention split across too many tools, technical failures mid-stream.
- Hates: losing the room when the connection weakens; interactive tools that lag; switching platforms mid-lesson.
- Value to her: one place to run the class, so her attention goes to teaching instead of tool management.
Omar Khaled
Wants: to follow the lesson without interruption, ask a question when he needs to, and get the recording afterwards.
- Fights: patchy connection, getting a word in during large classes, interfaces busy enough to break concentration.
- Hates: audio and video lag; missing the window to ask; not being able to review the material later.
- Value to him: a session that adapts to his bandwidth, with interaction simple enough to use one-handed.
03The questions I'd ask before writing a single story
Grouped by what the answer would change. A question that changes nothing doesn't get asked.
Founders & leadership
- Which customers are we for in phase one: large platforms or mid-size?
- What are the success criteria for the first release, stated as numbers?
- How is this priced, and does the pricing model change what we build first?
- Which features do you consider non-negotiable for the MVP?
- Are there launch dates already tied to commercial commitments?
The engineering team
- How many concurrent users must phase one support?
- What are the security and data-protection requirements?
- How will the API be designed so integration stays cheap for the customer?
- What are the biggest technical risks you already see, and are any technologies imposed on us?
- What performance floor is acceptable for release one?
- Which usage scenarios most need improving, and how simple does the teacher's interface have to be?
Sales
- What do customers complain about most in the tools they use today?
- Which features decide the purchase, as opposed to appearing on the comparison sheet?
- What do they expect on performance and stability, and how do they compare us to competitors?
04Four stories, and the format they're written in
Every story carries priority, points, dependencies, the layers it touches, acceptance criteria, and a named edge case with its handling. That last one does most of the work. A story without an edge case is a story whose estimate is fiction.
| Story | Priority | Pts | Touches | The edge case that shapes it |
|---|---|---|---|---|
| Start the class Teacher | Must have | 8 | Backend (sessions), Frontend (teacher UI), Infra (streaming) | Session creation fails as the class is starting |
| Manage interaction Teacher | Must have | 5 | Frontend (control panel), Backend (realtime messaging) | Interaction updates arrive late or not at all |
| Join the class Student | Must have | 3 | Frontend (student UI), Backend (access) | Student drops mid-session |
| Attendance report Platform admin | Should have | 2 | Backend (storage), Dashboard (reporting) | Attendance data is lost |
Written out in full, the first one looks like this:
As a teacher, I want to create and start a live class easily, so that I can begin teaching immediately without technical friction.
Why it's first: this is the entry point to the entire product for a teacher. If it is slow or unreliable, nothing downstream gets a fair hearing.
Acceptance criteria. A session can be created in 5 seconds or less; a unique join link is generated automatically; connection status is visible at all times; the session can be started and stopped without hunting for the control.
Edge case. Session creation fails at the moment the class is due to start. Handling: cache the session state, retry automatically, notify the teacher in plain language, and fall back to audio-only rather than to nothing.
Notes for the team. Automatic retry, a minimal interface that reduces the number of decisions in a moment of stress, and error logging for monitoring.
The same discipline runs through the rest. Hand-raise requests must appear instantly with no refresh, ordered chronologically, accept or reject in one action. When updates lag, resync automatically and show the connection state rather than leaving the teacher guessing. Students join in three steps or fewer with no plugin install and automatic quality adaptation. On a drop, reconnect automatically and restore the prior state. Attendance logs entry and exit per user, generates after the session ends, and exports to PDF and CSV, with live backup because a lost attendance record is a compliance problem, not an inconvenience.
05The teacher's flow, including the part that fails
Most flow diagrams draw the happy path and label the rest "error handling." The connection branch is not an error state here. On mixed MENA bandwidth it is a routine state, so it gets drawn as one.
06The Decision Owner Rule
Every decision has exactly one owner, and the owner is named before the disagreement, not during it.
| Decision type | Owner | How it gets made |
|---|---|---|
| Product | Product Owner | Owner decides, after consulting the team. Consulting is not the same as consensus. |
| Technical | Tech Lead | Architecture, technical risk, code quality and performance. The PO does not overrule these. |
| Shared | Both, together | Short planning sessions aimed at a fast alignment, not a full debate. |
The PO owns vision, release goals, backlog order, translating business need into clear stories, and every decision tied to value and user experience. The Tech Lead owns architecture, technical risk assessment, implementation, and quality. Value decisions go to the PO. Execution decisions go to the Tech Lead. Everything else gets fifteen minutes.
The point of writing this down before the project starts is simple: slow decisions are the most expensive thing a remote team can do to itself, and transparency is what makes a fast decision survivable.
07Five sprints
| Sprint | Theme | Shipped |
|---|---|---|
| 1–2 | Core classroom infrastructure | Session creation, joining, stable streaming. Nothing else, because nothing else matters if these three are shaky. |
| 3 | Interaction layer | Interaction tools and performance work. |
| 4 | Reporting & stability | Attendance reporting, stability hardening. |
| 5 | Polish & optimisation | UX refinement and the technical debt parked on purpose in sprints 1–4. |
The working loop between teams is short and repeating: Product sets priorities → UX turns requirements into buildable designs → Engineering builds and returns feedback early. Communication is continuous through shared tools, because the real risk on a remote team isn't disagreement, it's people working in isolation and only discovering it at review.
08Async-first, and what that costs you
Asynchronous by default, with short meetings when a decision needs one. Four ceremonies: planning, daily standup, review, retrospective. Meetings are for decisions and for clearing blockers, not for status updates a board delivers better.
Async only works if the written artefacts carry their weight, so: a backlog that is current, stories detailed enough to build from without a call, important decisions documented and circulated to everyone affected, and a progress board visible to all. Skip any of those and "async-first" becomes "nobody knows anything."
The backlog itself is ordered around three things: user value, technical risk, and dependencies. The PO owns the final order after the team has had its say.
09When it goes wrong
The release is going to be late
- Name the cause: scope, technical, or resources. They have different fixes and only one of them is solved by working harder.
- Cut scope, don't extend time. Hold the core value and let the rest go.
- Update stakeholder expectations early, while the news is still cheap.
- This is easier when stories were kept small and features were sliced into pieces that each deliver value alone. Slicing is not a formality; it's what makes cutting scope possible without cutting value.
The team disagrees on a technical call
- Take it out of the meeting if it doesn't concern everyone. Other people's time is a real cost.
- Hear both positions properly, then return to the product goal.
- Final call sits with the Tech Lead. As long as the value lands either way, the decision matters less than the speed of making it.
The team says requirements keep moving
- Explain the value, then re-order priorities and explain why that order. Priorities without reasons read as randomness.
- Update the stories so the written source of truth matches what was said.
- Protect the sprint from mid-flight change wherever possible. Every unprotected sprint is a rework invoice arriving later.
- When change is necessary: assess the impact on the goal, tell stakeholders what it costs the rest of the delivery date, defer anything non-urgent to a later sprint, and use feature flags so a half-built capability can be hidden rather than rushed.
A backlog tells people what to build. A named decision owner tells them what to do when they disagree about it. Only one of those is usually written down.