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.
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.
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."
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.
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:
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.
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.
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.
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:
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."
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:
Let me be clear about what I haven't figured out:
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.
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.
If you're thinking about doing an internship while juggling IB or other studies, here's what I'd say:
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 ?