My First PM Internship: Lessons from Scholar Assist | Rituraj Singh

What Managing My First Real Software Project Taught Me About Being a PM

There's a version of project management that lives in textbooks and YouTube videos — colour-coded Gantt charts, perfectly scoped backlogs, stakeholders who respond to emails on time.

Then there's the version I experienced during my internship, managing Scholar Assist: an AI-powered academic writing and integrity platform built from scratch, with real deadlines, real technical constraints, and absolutely no safety net.

This is what that experience actually taught me.

// A Little Context: What Was Scholar Assist?

Scholar Assist was a full-stack web platform designed to help students and researchers maintain academic integrity. It combined AI content detection, plagiarism analysis, smart editing, and citation generation — all in one place.

On paper, it was a well-scoped project. In practice, it was my crash course in what project management really demands.

I wasn't just tracking tasks. I was coordinating a tech stack (React, Node.js, Firebase, OpenAI API), managing scope expectations, and making calls when the team hit ambiguity — which was often.

// Lesson 1: Scope Creep Doesn't Knock. It Sneaks In.

Early in the project, someone suggested we add a real-time collaboration feature — the ability for students and supervisors to co-edit documents inside the platform. It sounded exciting. The team was enthusiastic. I nearly said yes.

I didn't.

Not because the idea was bad, but because I had just finished mapping our current sprint against our delivery deadline — and I could see exactly what saying yes would cost us. Two weeks. Minimum.

"A PM's job isn't to say no to good ideas. It's to protect the project from good ideas arriving at the wrong time."

That became my personal rule for the rest of the internship. Every new suggestion got the same question: Is this the right idea for right now?

// Lesson 2: Technical Uncertainty Is a Risk, Not an Excuse

About three weeks in, our AI detection module started producing inconsistent results. The confidence scores were fluctuating in ways we couldn't explain. The developer came to me and said, "We might need two more weeks to fix this."

My first instinct was to take that at face value. My second instinct — the better one — was to ask more questions.

After a proper conversation, we identified that the problem wasn't the model itself. It was how we were pre-processing the input text before passing it to the OpenAI API. A targeted fix took two days, not two weeks.

What I learned: When a team member says "this will take X time," that's an estimate based on their current understanding. A good PM digs into the why behind the estimate — not to challenge the person, but to understand the problem well enough to help remove blockers.

// Lesson 3: The Dashboard Nobody Asked For Was the Feature Everyone Needed

Halfway through the project, I proposed adding a performance dashboard that would consolidate the AI score, plagiarism percentage, and readability metrics into a single view.

It wasn't in the original brief. My reasoning was simple: we had three separate output modules, but no single place where a user could make sense of their document's overall health. The data existed — it just wasn't connected.

The team built it. In our internal testing, it became the most-used part of the platform.

This taught me something important: the best PM contributions aren't always about managing what's already planned. Sometimes they're about noticing a gap nobody articulated yet and making the case to fill it.

// Lesson 4: Status Updates Are Not the Same as Communication

Early on, I was sending weekly status updates to stakeholders. Clean format. Clear bullet points. Delivered on time.

Nobody read them properly.

What actually worked was a short, informal message at the end of each sprint that answered three questions: What did we finish? What's next? Is there anything we need from you?

Three sentences. Conversational tone. Specific ask at the end.

Response rates went up. Decision turnaround improved. The project moved faster — not because of better tools, but because I stopped writing for the format and started writing for the reader.

"Communication isn't about what you send. It's about what lands."

// Lesson 5: A PM Who Doesn't Understand the Product Is Just a Scheduler

This is the one that humbled me most.

There was a moment mid-project where the team was debating how to handle the citation generator module — specifically, whether to support IEEE format in the first release or defer it to a later phase.

I had no context. I didn't know what IEEE citation format was, why it mattered to the target user base, or how technically different it was to implement compared to APA and MLA.

So I sat out of the decision. I let the team debate it without proper PM input.

Later, I realised this was a strategic product decision disguised as a technical one. IEEE was critical for engineering and computer science researchers — exactly the user segment we most needed to win. Deferring it would have been the wrong call.

I made it my job from that point forward to develop enough product literacy to participate meaningfully in every decision — not just facilitate the meeting.

// Where I Am Now

Scholar Assist shipped. It works. And more importantly, it gave me a real answer to the question every recruiter eventually asks: "Tell me about a time you had to make a hard call."

I have several. And I learned something from each one.

If you're a hiring manager reading this, here's what I want you to take away: I am not a PM who has mastered the craft. I'm a PM who has started to understand it — through real projects, real mistakes, and a genuine hunger to get better.

That, I think, is exactly the right place to be at this stage of a career.