I was sitting in my first real client meeting, trying to look like I belonged there. My notebook was open, pen ready, professional expression on my face. Inside? I was terrified.

The client—a small business owner looking to build a custom inventory management system—was explaining his problems. His current system was slow, his team was frustrated, and orders were getting mixed up. He was talking fast, using industry terms I'd never heard before, occasionally referencing "the old system" that I knew nothing about.

My manager was asking questions, taking notes, nodding thoughtfully. The senior solution designer was sketching something on his iPad. And I was sitting there thinking: "I have no idea what's happening. What am I supposed to be doing right now?"

Welcome to my internship at CuriousRubik, where I learned that real business is nothing like IB Business Management class.

How I Got Here (Mostly Luck and Timing)

Let me be honest about how this internship happened: I got lucky.

I'd been looking for opportunities to see how tech companies actually operate. I'd done some coding through Scaler, built ApniDukaan, learned the theory in Business Management class. But I wanted to understand the middle ground—how do you translate business problems into technical solutions? How do companies actually decide what to build? I found CuriousRubik through a connection. They were a tech consultancy working with various businesses to build custom software solutions. When I reached out, they were looking for a Business Analyst intern—someone who could help bridge the gap between clients and developers.

The job description intimidated me. "Experience with requirements gathering," "knowledge of agile methodologies," "familiarity with wireframing tools." I had maybe 30% of what they were asking for. But I applied anyway, was honest in the interview about what I didn't know, and somehow they said yes. Looking back, I think they appreciated that I admitted my gaps rather than pretending to know everything. My first day, I was given access to their project management tools, introduced to the team, and immediately put on three active client projects.

I had no idea what I was doing.

The Gap Between Theory and Reality

In IB Business Management, I'd learned about stakeholder analysis, market research, operations management. We'd done case studies about companies making strategic decisions. I'd written essays about competitive advantage and organizational structure. But sitting in that first client meeting, I realized: none of that prepared me for this.

In class, case studies are clean. The information is presented clearly. The problem is defined. You analyze it, write your answer, get your grade. In the real meeting, the client wasn't presenting a clear problem. He was venting. He was jumping between three different issues—inventory tracking, team communication, and customer notifications. He'd start explaining one thing, then remember something else, then go off on a tangent about his supplier.

My manager had to gently guide the conversation back, ask clarifying questions, dig deeper into what the real issue was. I was scribbling notes frantically, trying to keep up, but mostly feeling lost.

After the meeting, my manager asked me: "So what do you think the core problem is?" I looked at my notes—five pages of scattered information. I had no idea how to synthesize it into one clear problem statement. "Um... they need a better system?" I offered weakly. He smiled. Not unkindly, but in a way that said, "You're going to need to be more specific than that."

Learning to Listen (Which Is Harder Than It Sounds)

The first skill I had to develop wasn't technical—it was learning how to actually listen. In my second week, I was sitting in on a call with a client who ran a small e-commerce business. She was explaining how her team processed orders, and I was nodding along, thinking I understood. Afterwards, my manager asked me to draft the document based on that call. I spent three hours writing what I thought was a comprehensive document outlining what they needed.

When I showed it to him, he read through it quietly, then looked up. "This is what they said they wanted. But is it what they actually need?" I stared at him, confused. "Isn't that... the same thing?"

He pulled up the recording of the call and pointed to a specific moment. The client had mentioned, almost as an aside, that her team was manually checking every order for errors because they didn't trust the automated system."Why don't they trust it?" he asked me. I didn't know. I hadn't thought to ask.

That's when I learned: clients don't always know how to articulate their real problems. They tell you symptoms—"the system is slow," "my team is frustrated"—but not the root cause. Your job is to dig deeper, ask follow-up questions, and figure out what's actually broken. I started practicing this. In the next few meetings, I forced myself to ask more questions, even when I felt dumb for not understanding something obvious:

"Can you walk me through exactly how you do this now?" "What happens when this goes wrong?" "Why do you think this is happening?" Sometimes the seniors would look at me like, "We were about to ask that," but other times my questions led somewhere useful. More often, I was just trying to catch up to what everyone else already understood.

The Art of Translation

Here's what I didn't understand about being a Business Analyst: you're essentially a translator.

The client speaks in business terms—revenue, customer satisfaction, operational efficiency.

The developers speak in technical terms—APIs, database schemas, frontend frameworks.

Your job is to stand in the middle and make sure both sides understand each other. I was terrible at this initially. A client would say, "We need the system to be more intuitive," and I'd write that down verbatim in the requirements document. The developer would read it and ask, "What does 'intuitive' mean specifically? What should the interface do?"

I didn't know. I hadn't asked.

I learned to translate vague requirements into specific ones:

• "More intuitive" became "Users should be able to complete the checkout process in under four clicks"
• "Better reporting" became "Weekly automated reports showing sales by category, sent via email"
• "Faster system" became "Page load time under 2 seconds"

But this took time to learn. I'd go back to clients multiple times asking for clarification, feeling embarrassed that I didn't get it the first time. My manager kept reminding me: "It's better to ask now than to build the wrong thing." Still, I felt like I was bothering people with basic questions.

The MIRO Flows and Prototypes I Didn't Know How to Create

After a few weeks of sitting in meetings and writing BRDs, my manager asked me to create a MIRO flow for a new project.

I nodded confidently. Internally, I panicked. What's a MIRO flow? I Googled it quickly. MIRO is a digital whiteboard tool. A "flow" is basically a visual representation of how users will move through a system. Okay, that makes sense conceptually.

Creating one? Completely different story. I spent four hours making my first MIRO flow. It was a mess—boxes everywhere, arrows going in illogical directions, trying to map out every possible scenario. I showed it to my manager the next day, already knowing it wasn't right.

He looked at it for about thirty seconds. "This is too complicated. What's the simplest path a user would take?" I hadn't thought about the simplest path. I'd tried to map everything at once.

He walked me through it: start with the main user journey. Just the basics. Then add edge cases later. Think about what the user wants to accomplish, not every possible thing they could do. We redid it together. His version was clean, logical, easy to understand. Mine had been a visual representation of my confused brain.

I got better at this over time. I learned that good flows aren't about being comprehensive—they're about being clear. But every new project still takes me multiple attempts before I create something that actually helps the developers understand what to build.

Testing As a "User Persona"

One of my roles was to test features before they went to the client. I was supposed to step into different "user personas"—act like I was the sales manager, or the warehouse operator, or the customer—and see if the system made sense from their perspective.

This sounds straightforward. It wasn't.

I'm 17. I've never managed a warehouse. I've never run a sales team. How am I supposed to know if this interface makes sense for them? I remember testing an inventory management feature and thinking, "This seems fine." But I had no real context for whether it actually solved the problem. I was just clicking buttons and making sure they worked technically. My manager noticed I wasn't catching issues. "You're testing like a developer," he said. "Test like a user who has five other things to worry about and just wants to get this task done quickly." That perspective shift helped. I started thinking: if I were overwhelmed and busy, would I figure out how to use this? If I'd never seen software like this before, would it make sense? I started catching issues: buttons that were technically functional but placed in illogical spots. Features that worked but required too many steps. Labels that made sense to us but would confuse the actual users.

But I still felt like I was guessing half the time. I didn't have the real-world experience to know what users actually needed. I was extrapolating from my limited understanding.

The Coordination Dance With Developers

Here's something I underestimated: developers are incredibly smart, but they're not mind readers. I'd write a requirement like "The system should send a notification when inventory is low," and think I'd been perfectly clear. The developer would implement it, and then I'd see it in action and realize: oh, they're sending a notification every single time someone opens the inventory page if something is low. That's not what I meant. I meant a daily summary notification. But I hadn't specified that. I'd assumed it was obvious.

I learned to be painfully specific:

• When should the notification be sent? (Daily at 9 AM)
• Who should receive it? (Warehouse manager only)
• What should it include? (List of items below threshold, with current quantities)
• What should the threshold be? (Client to define)

Even then, I'd miss things. There was always some edge case I hadn't thought of.

The developers were patient with me, mostly. Sometimes I could tell they were frustrated when I'd come back with changes to requirements they'd already built. I felt guilty every time, but I also didn't know what I didn't know until I saw it actually working. I learned to involve developers earlier in the process, showing them my requirements documents before marking them final. They'd point out ambiguities or technical impossibilities that I hadn't considered. This saved time, even though it meant admitting I needed help before claiming something was "done."

What IB Business Management Didn't Teach Me

I'm grateful for what I'm learning in Business Management class. The concepts—understanding stakeholders, analyzing markets, thinking about organizational structure—are genuinely useful.

But there's so much it doesn't cover:

1. The emotional labor of managing client expectations: Sometimes clients want something that's technically impossible or would cost way more than they can afford. Having those conversations—being honest but not discouraging—is a skill I'm still developing. In class, we analyze case studies from an objective distance. In real life, you're telling someone who's excited about their business idea that their vision isn't feasible, and watching their face fall.
2. The messiness of real projects: In class, projects have clear phases and timelines. In reality, clients change their minds halfway through. Requirements evolve. What you thought was a three-week project becomes two months. You have to adapt constantly.
3. The importance of relationships: The theory teaches you about formal organizational structures and communication channels. But in practice, having a good relationship with the developers means they'll give you honest feedback when your requirements don't make sense. Having trust with clients means they'll be honest about their budget constraints. These relationship skills aren't in the textbook.
4. How many things can go wrong simultaneously: We had a project where the client was late providing information, the developer assigned to it got sick, and the tool we were using for prototyping had a technical glitch. All in the same week. Your case studies don't prepare you for juggling multiple problems while still moving forward.
5. What I'm Still Really Bad At

Let me be clear about what I haven't figured out:

• Estimating time: When my manager asks "How long will it take you to create that requirements document?" I genuinely don't know. Sometimes it takes two hours. Sometimes it takes eight. I'm getting better at building in buffer time, but I still underestimate more often than not.
• Knowing when to escalate issues: Sometimes I spend hours trying to solve a problem that my manager could have answered in five minutes. Other times I ask questions too early, when I should have tried figuring it out myself first. I haven't found the right balance.
• Reading between the lines: Senior team members can listen to a client call and immediately identify what's not being said—the concerns they're hesitant to voice, the budget they haven't mentioned, the timeline pressure they're under. I'm not there yet. I hear the words, but I miss the subtext.
• Technical depth: I can translate between business and technical language at a basic level, but when conversations get deeply technical, I'm lost. I nod along like I understand, then Google terms afterwards. I'm learning, but there's a huge gap between my current knowledge and where I need to be.
• Why I'm Grateful For This Opportunity

I'm aware that getting this internship at 17 is not normal. Most students my age aren't sitting in client meetings or working on real business projects. I don't say this to brag—I say it because I'm genuinely grateful, and I don't take it for granted.

CuriousRubik didn't have to hire a student with minimal experience. They could have brought on someone with actual business analysis experience who wouldn't need constant guidance. But they took a chance on someone willing to learn. And more importantly, they created an environment where it was okay to not know things, to ask questions, to make mistakes.

My manager never made me feel stupid for misunderstanding something. The senior solution designers patiently explained concepts I should have known. The developers tolerated my vague requirements and helped me improve them. This kind of environment—where learning is expected and supported—is rare. I know this because I've heard stories from friends who had internships where they were treated like they should already know everything.

What This Experience Changed

Before this internship, I thought understanding business meant knowing theory—market segmentation, financial ratios, organizational structures. Now I understand that real business is about people. It's about understanding what clients actually need (even when they can't articulate it), coordinating with team members who have different priorities, managing expectations when things don't go as planned.

The theory is useful—it gives you frameworks to think through problems. But the practice is where you actually learn how things work. I'm more comfortable with ambiguity now. In school, there's usually a right answer. In business, there are just different approaches with different trade-offs. You make the best decision you can with incomplete information, and then adjust when you learn more.

I'm also more aware of how much I don't know. Before, I thought I understood how businesses worked. Now I realize I'm just beginning to scratch the surface. Every project shows me new layers of complexity I hadn't considered.

And weirdly, that feels good. Not knowing everything used to scare me. Now it feels like proof that I'm learning something real.

To Anyone Considering an Internship While Still in School

If you're thinking about doing an internship while juggling IB or other studies, here's what I'd say:

• Expect to feel lost. You'll be in meetings where you don't understand half of what's being discussed. That's normal. Don't fake understanding—ask questions and take notes.
• Your age is both an advantage and a disadvantage. Disadvantage: you lack experience and context that others have. Advantage: people expect you to ask basic questions and be learning. Use that. Ask everything. Nobody expects you to already know it all.
• The work will take longer than you think. What takes a senior team member an hour might take you four hours. That's okay. You're learning while doing it. Build extra time into your estimates, and be honest with your supervisors about your pace.
• You'll make mistakes. I've made so many. The key is learning from them and not making the same mistake twice. (I've definitely made some mistakes more than twice, to be honest, but I'm working on it.)
• Balance is hard. I won't pretend it's easy to do an internship alongside IB. There are weeks when I'm overwhelmed. But for me, the learning is worth the stress. You have to decide if that trade-off works for you.

Still Learning

I'm still at CuriousRubik, still learning, still making mistakes. Just last week, I sent a client presentation with the wrong data in it because I'd pulled from an old version of the file. Embarrassing, but fixable.My manager keeps telling me: "You're not supposed to be good at this yet. You're supposed to be learning."

That's the mindset I'm trying to embrace. I'm not here to prove I already know everything. I'm here to figure out what I don't know and get better at it. Every client meeting teaches me something new about how to listen. Every requirements document I create is slightly less terrible than the last one. Every mistake shows me what to watch out for next time. I don't know if I want to be a Business Analyst long-term. I'm still figuring out if I'm more drawn to the technical side (building things) or the business side (understanding what to build). Maybe both, somehow.

But I know that this experience—being uncomfortable, being challenged, being in rooms where I'm the least experienced person—is teaching me things that will be useful regardless of what I end up doing.And that first client meeting where I felt completely lost? I'm still sitting in meetings where I feel that way sometimes. But now I know it's part of the process, not a sign that I don't belong there.

If you've had internship experiences—especially ones where you felt in over your head—I'd love to hear about them. How did you handle it? What did you learn ?