Overview
When the client first came to me, the brief was straightforward on the surface. They wanted a platform where students could access live courses and tutors could deliver them. An online learning space. Make everything accessible. Go.
I have heard versions of this brief dozens of times throughout my career in product strategy. And I have learned — the hard way, early on — that the moment a client says "make it accessible" without defining what accessible means to their specific user, you are already heading toward a product that will disappoint everyone.
So before I opened a single design document or wrote a single product requirement, I stopped. I asked the questions that the brief did not answer. Who exactly is the student? What is their technical comfort level? Where are they accessing this from? And equally important — who is the tutor? What does their experience of creating and delivering a live course actually look like?
Two different users. Two completely different sets of needs. One platform that had to serve both — seamlessly, simultaneously, without either group feeling like they were using something built for the other. That is a product challenge. And it starts long before the first screen gets designed.
"A learning platform is not a technology problem. It is a human behavior problem. Students learn differently than tutors teach. The product has to understand both — and make both experiences feel effortless, even when the engineering underneath them is not."
The Challenge
The challenge was not a lack of ambition. The client's vision was real and the market opportunity was clear. The challenge was the three gaps that almost every learning platform brief contains — and that almost nobody addresses before the build begins.
The student experience and the tutor experience are fundamentally different products
Students need frictionless access, intuitive navigation, and the confidence that the technology will not fail them mid-lesson. Tutors need control, flexibility, and a delivery environment that enhances rather than interrupts their teaching. Building both inside a single platform — without compromise on either side — requires two parallel thinking tracks running simultaneously from day one. Most platform briefs treat them as one problem. They are not.
Live courses create technical complexity that on-demand content does not
The client initially described this as a content platform. It was not — it was a live session platform. That distinction changes almost everything: the infrastructure requirements, the failure tolerance, the session management logic, the tutor scheduling workflow, and the student notification and access systems. None of this was in the original brief. All of it had to be discovered, named, and defined before a single line of code was written.
The client's vision was broader than the viable first version needed to be
The original scope included features that would have delayed the launch by months and added complexity that the core user journey did not require. The most important strategic work I did on this project was not building — it was defining what to leave out of the first version so that what shipped actually worked, and worked well, for the people who mattered most.
The Strategy
Three phases shaped how I approached turning the client's idea into a buildable product. Each one was necessary. None of them were in the brief.
Phase 01
Map both users completely before designing anything
Built the full student journey and the full tutor journey separately — every touchpoint, every decision, every potential friction point. Only then could we identify where they intersected and how the platform had to behave at those intersections.
Phase 02
Define what the first version must do perfectly — and nothing else
Live session access. Tutor course creation. Student enrollment and scheduling. Everything else deferred to version two. The first version's job was not to be comprehensive. It was to be right about the things that mattered.
Phase 03
Build the architecture around live delivery first
Because live sessions were the core product, the infrastructure had to be built for reliability under simultaneous live load. Technology decisions had to be made before design decisions — chosen for performance and scalability, not familiarity.
"The most valuable thing I contributed to the Horof project was not a feature. It was a decision about what not to build in the first version — and the ability to defend that decision when the pressure to add more was strongest."
The Story — The Session That Saved the Product
There is a moment in almost every product engagement where the real shape of the problem becomes visible — usually because a question gets asked that nobody thought to ask before. For Horof, that moment came about two weeks into the project, in a session where I was mapping the tutor workflow.
The client had described the tutor's experience as simple. I asked them to walk me through it. Step by step. From the moment a tutor decides to create a course to the moment a student completes a session.
What emerged was not simple. A tutor needed to: create a course profile, define the subject and level, set session availability, manage enrollment requests, prepare session materials, enter the live environment at the correct time, manage student access during the session, handle technical issues without losing the class, and follow up after the session ended.
That is eight distinct workflow stages. Each with its own logic, its own potential failure points, and its own user experience requirements. If we had built the platform the client described in the original brief, a tutor would have encountered friction at almost every one of those stages. They would have used the platform once, had a poor experience, and never returned.
The student experience — which depended entirely on tutors showing up, delivering well, and coming back — would have failed as a consequence. Not because of the student-facing product. Because of what we had done to the people producing the experience students were paying for.
The client had come into that session thinking they were building a student platform. They left it understanding that they were building a tutor platform first — and that the student experience was the output of that, not the product itself. That reframe changed the entire architecture, where we invested design attention, and what the first version prioritized above everything else.
"The most dangerous assumption in product development is that the person who commissions the platform understands the experience of the person who will use it. They almost never do. And the gap between those two understandings is where products fail."
The Build — Translating Strategy Into System
With the product strategy locked, the scope defined, and the architectural priorities established, the build phase translated the thinking into a live, functioning platform. Every technology choice was made in service of one outcome: a platform where a tutor could deliver a live course and a student could attend it — without either of them thinking about the technology at all.
The technology stack was chosen deliberately. GraphQL for efficient data querying across the platform's multiple user types. React with Ant Design for a fast, consistent, and professional UI. Next.js for server-side rendering that made the platform feel responsive at every load point. Java and Node.js on the backend for the reliability that live session delivery demands. TypeScript throughout for code quality that would compound in value as the platform scaled. A REST API architecture to ensure the system could integrate with future tools and expand without requiring a rebuild.
None of these choices were made because they were fashionable or because the team preferred them. They were made because the product requirements — specifically the demands of live, simultaneous, multi-user session delivery — demanded them. Technology serves the product. The product serves the user. That sequence does not reverse.
Results & Impact
The Horof platform launched as a fully operational e-learning environment. The results were not accidental. They were the direct output of the strategic decisions made before a single screen was designed.
Product Delivered
A live, operational e-learning platform
Horof launched as a fully functioning online learning space serving both students and tutors — with live course delivery, enrollment management, and a tutor creation workflow that supported the way educators actually work.
Scope Discipline
First version built for what mattered, not everything
By defining and defending a tightly scoped first version, the platform launched on time with the core experience working well — rather than launching late with everything half-finished.
Strategic Reframe
Tutor-first architecture that made the student experience possible
The decision to treat the tutor experience as the primary engineering priority was counterintuitive to the client and essential to the product. The student experience was only as good as the tutor experience that produced it.
New Venture Created
Revenue-generating product from a blank-page idea
The client arrived with an idea. The product strategy process turned that idea into a live platform — a new digital venture with real users, real courses, and real commercial potential that did not exist before the engagement began.
Key Learnings
These are the lessons that Horof taught me — and that have informed every product engagement I have worked on since. They apply equally to digital marketing campaign architecture, to B2B sales systems, and to any domain where the work involves building something that a real human being has to use.
Map every user type completely before designing anything
A platform that serves multiple user types is multiple products sharing one codebase. If you do not understand each user's full journey before you start designing, you will build friction into the product at every point where you made an assumption instead of doing the research.
The scope of the first version is the most important product decision you will make
A product that does three things excellently will always outperform a product that does ten things adequately. The first version's job is not to be comprehensive. Its job is to prove that the core value proposition works — for real users, in real conditions.
Technology choices are product decisions — not engineering decisions
The technologies chosen to build Horof were not chosen for preference or familiarity. They were chosen because the product required live session reliability, performance under simultaneous load, and a UI that served both technical and non-technical users. Technology serves the product requirement. Never the other way around.
The engine behind the experience matters more than the experience itself
Students experienced Horof through the quality of the courses they attended. The quality of those courses depended entirely on whether tutors found the platform easy enough to use consistently. Building the tutor experience first was the most counterintuitive and most important strategic decision of the project.
The client's brief is the starting point — not the destination
Every good product that gets built from a client brief requires the strategist to interrogate that brief before accepting it. The questions that are not in the brief — about users, behavior, context, and what failure looks like — are the questions that determine whether the product works or not.
A new venture is built from insight — not from ideas
The client's idea was the starting point. The insight — that the tutor experience was the real product and the student experience was the output — was what made the platform actually work. Ideas are abundant. The insight that makes an idea commercially viable is what product strategy is for.
Conclusion
Horof is the cleanest example I have of what product strategy, done properly, actually produces. A client came with an idea — broad, ambitious, and vague in the ways that matter most. I turned that idea into a product strategy, that strategy into a defined build, and that build into a live platform that serves real students and real tutors delivering real courses.
A new venture, created from a blank page. Revenue potential built from scratch. Cost controlled by the discipline of scope precision. And a client who left the engagement with something they did not have when they arrived — not just a product, but an understanding of what their platform actually needed to be in order to work.
The lesson that Horof reinforced, more clearly than any other project I have worked on, is this: the most valuable contribution a strategist makes is not the product they build. It is the question they ask before the building begins.
That question, asked early and honestly, is what separates the products that launch and work from the products that launch and disappoint.
"The best product strategy is the kind the client never fully sees — because what they see is a platform that works, users who come back, and a business that did not exist before they walked into the conversation."
Syed Hassan Osaid
Head of Digital Marketing · Softcino · Chicago, Illinois · formerly Cubix, VIDIZMO.AI, Soft Fellow
Let's build marketing that actually moves people.
From early-stage startups to scaling U.S. enterprises — I've driven growth at every level.
Let's talk
contact@hassanosaid.com
