The unglamorous beginning is where the real history lives

Introduction

Foundations don’t photograph well. In the early rooms that set an industry, the only glossy surface is the laminated badge you forget to return at night. The rest is scuffed carpet, a folding table with power strips zip-tied to a leg, a whiteboard that ghosts old diagrams, and a stack of purchase orders held by a binder clip too small for the job. That is where categories form — not under spotlights but under fluorescent hum. In 1997, that was the daily texture of building the tools that would become a learning management market.

In those rooms, the work is operational, not rhetorical. You start with what must run on Monday: a course shell for Biology 101, faculty roles mapped correctly, students enrolled from a registrar file whose header row is a decade old, and a system that can survive the first wave of logins. The job is to connect what a university already has — directories, student information systems, procurement processes — to something new that cannot ask the institution to change first. The early days looked like crossover cables, phone calls to network admins, and manual checklists taped to a monitor. You learn quickly that history, when it sticks, is the record of what people did under those constraints.

This record aims to preserve the unglamorous beginning of a category, through the work that made it real. In 1997, I co-founded CourseInfo at Cornell University with Daniel Cane. By 1998, we were operating as one with Blackboard, building the pieces of a common platform for course management. The narrative available on conference stages never quite captures the operational reality that both limited and enabled the work. It’s the trench-digging and rebar tying of a building that will later look effortless from the street.

This is a record drained of founder mythology. Names, dates, and sequence matter because they explain how choices were made and how a market professionalized. It also credits the people who rarely make it into the highlight reel: the campus administrators who ran the systems, the faculty who piloted features, and the support staff who cleared queues before first period. The unglamorous beginning is where the real history lives because it preserves how the thing actually formed.

How categories start rough

The first signal a category exists is not a manifesto; it’s a pattern in the work. You see the same request show up across institutions, the same workaround appear on user lists, and the same operational failure repeat at the same academic calendar moment. That pattern is the earliest data series the market offers. In 1997 and 1998, the signals around course websites were quiet and concrete: a department put a syllabus online; a professor wanted a grade book they didn’t need to hand-code; an administrator wanted one page where students could find all their courses.

A common mistake in retelling early history is to retrofit clarity — to pretend the shape of the category was obvious from the start. It wasn’t. In those first months we called things by function, not by category: “course sites,” “file posting,” “discussion tools.” The umbrella term that later stuck — learning management system — was still in circulation, not consensus. WebCT, created at the University of British Columbia under Murray Goldberg, carried one line of the DNA; CourseInfo carried another. Customers didn’t care about category names. They cared that a course roster matched, that files uploaded, and that the system stayed up through midterms.

Paperwork before product

Before a feature could become real, it had to survive procurement. A department might buy with a purchasing card; a campus might post a request for proposals that governed what any vendor could even discuss. These RFPs read like policy mixed with wish list — captions about accessibility, identity management requirements, and export formats for grade data that reflected existing campus systems more than any vendor’s preferences. This is not the part of the story that makes for an inspiring slide, but it is the part that builds a company’s operational reflexes.

Lesson — Treat procurement documents as design briefs from the institutions you want to serve.

These requests for proposals define everything from accessibility to data export formats and reflect deep institutional needs. The discipline of hearing procurement requests as a map—not a hurdle—saves time. Learning to read, respond, and audit against these documents is how software earns permission to become a product.

> Without the ability to respond to a procurement document, you do not have a product; you have software in search of permission.

The first contracts were short and provisional. Price points were measured against department equipment budgets. Often a pilot preceded a purchase order. We would set up a small deployment on campus hardware for a semester with a named faculty sponsor, track what worked and what failed, and then stand in a conference room answering questions not about vision but about backup procedures, authentication, and where logs were kept. Those answers — not taglines — are what moved a department from “try” to “buy.”

Naming comes after use

Categories harden their names only after enough people use them under pressure. “CourseInfo” carried a descriptive intent: make the information of the course available. “Blackboard” carried a metaphor for teaching surfaces. The field did not become a capital-L Learning Management System until enough campuses ran the tools through full academic cycles and began to ask for comparables. That is when procurement officers, CIOs, and faculty committees need a short name to describe a long list of functions. The shorthand, once in use, rearranges the roadmap. You stop thinking in discrete utilities and start thinking in platform surfaces.

The early edtech field conditions

The late 1990s internet was uneven. Bandwidth on campus might be generous in a lab and stingy in a dorm. Off-campus access for adjuncts or students was often dial-up. Browser compatibility was a daily constraint — you learned the differences between what a page did in Netscape and Internet Explorer because your support queue taught you. Authentication was not yet federated across everything; campus directories and LDAP servers behaved a bit differently building to building. These are not details for nostalgia; they’re the operational facts that shaped how features were sequenced and tested.

Lesson — Design for the real-world operational facts of your users, not for an idealized environment.

The internet of the time was inconsistent, with bandwidth varying from labs to dorms and off-campus access often on dial-up. Browser compatibility was a daily challenge that your support queue would quickly reveal. Ignoring these operational facts meant writing an elegant spec that shipped into silence and caused support pain.

On the institutional side, the calendar ruled. A missed deadline in August or January didn’t slip a week; it slipped a term. Faculty training sat in narrow windows between grading and committee meetings. A product manager who ignored the calendar would write a spec that shipped into support pain.

Campus networks and constraints

The deployment model also varied. Some campuses demanded on-premises installs. Others preferred hosted pilots before moving on-prem. A few wanted fully hosted from the beginning. That meant writing the same code for three operational realities and maintaining release discipline that could survive each. It meant scripts to provision new instances reproducibly and handoffs to campus staff that respected their practices rather than tried to replace them. The mundane choices carry the weight because that is where uptime actually lives.

Procurement shaped the roadmap

Much of what later looked like a coherent roadmap was an accumulation of constraints turned into decisions. If a request for proposals from a state university system specified grade export in a format that matched their student information system, that item jumped to the top. If a consortium of private colleges asked for single sign-on behavior, you learned to speak their language and then built what they could adopt on their schedule. The discipline of hearing procurement as a map saved time and built trust with administrators.

What we actually did each day

A record without the day-to-day loses credibility. The early job looked like this. There was a ticket queue that grew predictable humps at the start of term and around midterms. There were CSV files incoming from registrar systems with column headers that sometimes changed without notice. There were builds late at night and people in the office early to catch breakage before faculty did. There were onboarding calls with campus administrators where the work was less demo than translation — aligning our options with their policy and schedule.

Ticket queue and course shell creation

The mechanics of creating course sites taught us the important parts.

Lesson — Prioritize the "front door" features that establish immediate trust with your users.

We learned quickly that roster accuracy and role mapping weren’t sub-features; they were the first test of reliability. If the front door stuck, no one explored the house. We built forgiveness into our importers and added logging so support could explain, with a timestamp, why a student was or was not in a course, preserving the ability to repair trust.

> We learned quickly that roster accuracy and role mapping weren’t sub-features. They were the front door.

A practical example: a department uploaded a file where the instructor-of-record had two campus identities because of a recent appointment change. The system had to decide which ID to respect and how to show the result to both the admin and the instructor without causing panic. We built a reconciliation step the admin could run, with warnings that could be copied into an email. It was not glamorous, but it prevented dozens of tickets.

Release rituals and rollback plans

Release management was ritualized because the calendar enforced it. We made checklists for upgrades by instance. We scheduled maintenance windows with campuses weeks in advance. We kept a changelog written in a way that a non-developer administrator could understand. And we held back features if they added uncertainty near a critical academic date. That discipline is the unglamorous part every customer counts on.

Rollback plans mattered. A feature fail that knocks a course offline in week six of term is worse than a feature delay. We kept older builds staged and wrote scripts to revert a deployment quickly, preserving content and enrollments. You only need to do one live rollback under pressure to learn that the process page must be printable, short, and updated every time something changes. That page is where reliability lives.

Partners and Building Blocks

As campuses adopted the platform, they wanted to connect what they already used: plagiarism detection services, lecture capture systems, and library reserves. We needed a way to make those connections part of the product without hardwiring each integration. Building Blocks — Blackboard’s extension framework from the early 2000s — came from this operational need. The program turned a set of APIs into a predictable way to extend the system without breaking upgrades. A good extension framework is less about elegance and more about guardrails that allow many parties to move without colliding.

How standards formed from friction

Standards are often narrated as clean, top-down solutions. In practice, they come from trouble tickets that repeat across organizations until someone decides to name the problem. In the late 1990s, the IMS Global Learning Consortium attempted to describe the objects and relationships in a course context so that tools wouldn’t have to guess. Around the same time, the Advanced Distributed Learning initiative (ADL) pushed SCORM — a set of constraints for packaging and sequencing content. These efforts responded to administrators and vendors who were tired of building bespoke conversions at every boundary.

IMS vocabulary and institutional memory

IMS gave us a vocabulary that could bridge RFPs and product specs. When a campus asked for certain behaviors around assessment or content, a vendor could point to a named specification and ask a clear question. It did not remove the work; it removed ambiguity. It also built institutional memory. A new administrator could read a past procurement response and understand the terms of what they had inherited. A team that can speak in a shared vocabulary can also estimate, test, and document more consistently.

SCORM constraints and support counts

SCORM — particularly in its early 2000s iterations — was less inspiring than constraining, and that was the point.

Lesson — Use industry standards to reduce support costs and ambiguity, not just for theoretical compliance.

Standards often emerge from repeating trouble tickets. SCORM provided a known structure for content packages that directly reduced the support burden when a campus imported publisher materials. The victory appeared as fewer support tickets and an admin who could explain behavior without inventing a story. In the unglamorous beginning, a standard is good when it prevents a Friday night call.

APIs become marketplaces

As extension surfaces stabilized, a marketplace formed. Not because someone declared one, but because partners could reliably build for a moving target that moved predictably. Building Blocks matured into a program with certification, documentation, and community. That program allowed smaller companies and campus teams to meet their own operational realities without waiting for a core release. When many partners implemented the same extension in slightly different ways to meet the same need, we knew the core should evolve.

Removing mythology from the record

Historical accuracy is not self-effacement; it’s respect for the people who did the work and for the institutions that took the risk to adopt early. The temptation, once a market consolidates, is to write the story backward from a milestone — an acquisition, an IPO — and to make that moment the origin. The truth is plainer and more instructive.

Credit the administrators

Campus administrators carried more of the early load than anyone credits. They learned new systems while keeping the old ones alive. They mediated between faculty needs and policy. They called after hours when enrollment feeds hiccupped and then wrote the email that preserved confidence the next morning. Their constraints — data retention policies, audit requirements, accessibility mandates — shaped the product more than any keynote. The first online quiz that saved grading time scaled because a faculty champion took a risk in a real course with real students.

Competitor pressure clarified the category

WebCT provided a strong alternative in the same time frame, with its own academic DNA and deployment realities. Later, ANGEL Learning offered another line of pressure. Their presence forced clarity. You had to decide which surfaces were differentiators and which were table stakes. You had to earn migrations by making them survivable.

> The category did not mature through slogans; it matured through side-by-side pilots and after-action reports.

Mistakes that forced improvements

The errors are part of the record. We misestimated feature effort when browser behavior changed underneath us. We released an integration assuming an identity field would be stable and learned otherwise. We paused a capability near term start because uncertainty was worse than delay. Each mistake tightened a process: verifying assumptions about campus data, staging releases further from academic cliffs, and writing documentation that met the administrator where they worked. This is how reliability forms.

The move from tools to a market

A collection of tools becomes a market when buyers compare on more than features. Support response times, integration posture, auditability, accessibility, training materials — these are the things people weigh once functionality is broadly comparable. That shift happened as deployments grew from a department to a campus and from a campus to a system. When the paperwork professionalizes, the vendors must as well.

Commercialization and consolidation

As adoption widened, companies needed to scale support, sales operations, and partner programs. You cannot serve a system-wide deployment with the same rhythms that served a department pilot. You need named account support, implementation project plans, and an escalation path that includes people who can change the code. Those things are unglamorous to describe, but they are what a market is built on. They are also what later allows mergers to make operational sense.

Professionalization and the people who did it

Professionalization looks like hiring a documentation team that writes for administrators first. It looks like formalizing a beta program with campuses that volunteer real courses and gradebooks, not just demos. It looks like compliance checklists that are boring on purpose. And it looks like a partner framework — Building Blocks in Blackboard’s case — that signals you are a platform others can bet on. The people who built those functions should show up in the history.

What public markets recognized

On June 18, 2004, Blackboard began trading on NASDAQ under the ticker BBBB. That line shows up in bios because it is easy to date and it satisfies a form of narrative closure. It belongs in the record not as a coronation but as a measurement. Public markets recognized that the operational base — the administrators, the deployments that survived term turns, the extension ecosystem, the standards participation — added up to a business with predictable rhythms.

The milestone did not retroactively change the origin. The rooms stayed the same for a while: the folding tables, the whiteboards, the binders of contracts. What changed is what had to be reported and how often. Reliability, which had already been the job, became the headline metric outside the walls as well as inside them. Public recognition also clarified obligations. Support response times were not just a courtesy; they were a risk factor. The market that had formed around unglamorous work stayed grounded in it.

Why the unglamorous beginning lasts

The value of preserving the unglamorous beginning is not nostalgia. It is method. When you document how a category formed — with names, dates, calendar constraints, and the tense conversations that ended in a workable compromise — you create a manual for the next formation. New technologies will rearrange surfaces, but institutions will still buy on proof and reliability. Standards will still emerge from repeated friction. Extensions will still become markets when the substrate moves predictably. The unglamorous details outlast the tools because they describe how people organize to get dependable results.

The sustained metaphor here returns: the building that later looks sleek from the sidewalk stands because someone laid footings in cold weather, checked forms for square, and set rebar on the right chairs so concrete covered it fully. Those choices are unphotogenic, but they hold. In the same way, an industry stands on the documentation you could hand to a new administrator on a Monday morning and trust that they could run the system.

The bet I'd make today

If I had to pick one consistent bet after watching a category form from folding tables to a public ticker, it would be this: start where the unglamorous work already lives and write down what you find. Build in the order the operations demand — the front door that must open first, the logs that must explain what happened, the extension points that let others bring their realities with them.

I would bet on finding the pattern in the support queue before naming the product on the website. I would bet on reading procurement not as a hurdle but as a design brief from the institution you want to serve. I would bet on standards participation not to win arguments but to reduce guesswork for the person who has to import a package on a Friday afternoon. And I would bet on an extension program early, as it demonstrates respect for the tools your customers already run.

I would also bet on recording the work accurately: dates, versions, who decided what and why. When you write history later, those notes will keep you honest. More importantly, they will give the next team enough fidelity to adapt without reliving the same mistakes. The administrators will still be there; the calendars will still cut the year into windows that cannot be missed; the standards bodies will still move at the speed of consensus and proof.

The unglamorous beginning is not the prelude; it is the place where the structure is set. The footings either carry the load or they don’t. If you are building a tool, a company, or a category, that is where to start, and that is what to keep in the record. When someone later asks where the real history lives, you will know where to point: the rooms with the folding tables, the checklists, the logs, and the names written next to decisions that held under pressure.

The most reliable history of any industry hides in unglamorous rooms.

Not the keynote stage. The folding tables with mislabeled power strips. The registrar’s CSV that only opens in one version of Excel. The sysadmin who keeps a stack of spare drives and a paper binder of contacts for after-hours calls.

That is where edtech began for me. In 1997, I co-founded CourseInfo at Cornell with Daniel Cane. By 1998, we were operating as one with Blackboard. The work was ordinary in a way that matters: provisioning course shells, mapping roles, parsing files from student systems, answering support emails before class on Monday.

Procurement shaped the roadmap. If the RFP asked for a rubric tool, you built it. If it asked for grade export to a particular system, you learned that system’s quirks. The result wasn’t a slogan; it was software that survived first contact with a semester.

Standards weren’t abstract. IMS (launched in 1997) gave us a vocabulary; SCORM in the early 2000s constrained payloads; and campus directory conventions set the edges of identity. We created Building Blocks so partners could extend the surface area. That program turned into a market because others needed to meet their own unglamorous realities.

Competitors—WebCT and later ANGEL—made the category clearer. Pressure from real deployments sorted differentiators from decoration. In 2004, Blackboard went public on NASDAQ as BBBB. That was not the origin; it was a mile marker on a road paved by admins, faculty champions, engineers, and support teams who did the patient work.

Why write this now? Because the unglamorous beginning is where the teachable parts live. If you build, start there. If you buy, ask to see it. If you record history, keep the names, dates, and the operations that made it real.

Read the full piece and share your own unglamorous start. #RealHistory #EdTech #IndustryFormation