Listen to this episode on Spotify or Apple Podcasts
Partway through our conversation, I admit something to Khurram Mir that I’m not proud of.
“Whenever I have friction with a QA partner,” I tell him, “it’s because I feel like they’re being nitpicky about something.” They block the launch. They say no, this doesn’t work about something that, to me, looks finished enough to ship. I’ve been guilty of this recently — the quiet resentment that builds when the person whose entire job is to find problems keeps finding them at the exact moment you want to be done.
I expect Khurram to take my side. He has, after all, spent his career on the testing side of the table. He started in software testing in 2001, drawn to it because it asked him to think like a user instead of an engineer. He built Qualitum into a consulting firm with offices in five countries and more than fifteen years behind it. If anyone is going to defend the QA person against the impatient product manager, it should be him.
He doesn’t defend the QA person. He doesn’t defend me either. He does something more useful — he tells me the friction is a symptom, and then he tells me what it’s a symptom of.
“If you bring in QA early,” he says, “this is the best thing you could do for your own product.”
Then he stops, and takes a step back, the way you do when you realize the listener is holding the wrong frame entirely.
“Let’s not think QA as technical software engineers,” he says. “Let’s think of this person as somebody who is going to look at your application like an end user.”
I tell him I think I see where this is going, and he keeps pulling the thread. The QA person, he says, can be your beta user. Your friend who’s going to use the app. And then he says the line that reorganizes the whole problem for me.
“Let’s not even use the word test here. This person is going to use your application.”
There’s a weight on the word use when he says it — not a correction so much as a reveal, like he’s been waiting the whole conversation to put it that plainly. Because the consequence is immediate and it lands on me, not on the tester. “If you don’t bring this guy up to the speed on what the product is supposed to do,” he says, “and you don’t give them enough time and enough understanding of how the product is supposed to work as a user, they cannot really look into this application and give you any valuable feedback.”
I want to argue. I don’t, because I already know he’s right, and I know it because of a complaint I make about my own QA partners constantly. They tell me the form isn’t working. The submit button isn’t working. The field doesn’t validate. Khurram names this before I can.
“They may be able to tell you, this form is not working, this field is not working, my submit button is not working,“ he says, “but that even a CTO can figure out.”
That stings in the specific way that true things sting. The feedback I’ve been dismissing as nitpicky is exactly the feedback a context-starved tester is able to give. It’s the floor. It’s what’s left when you hand someone a finished build and no reason to care about it.
Earlier in our conversation I’d reached for a metaphor without realizing it was about to indict me. I’d been talking about video game testers — the ones you see in shows like Mythic Quest, paid to sit and play a game all day and log what breaks.
The reframe I loved was that they’re not outside the game. They’re playing it. They’re immersed, in character, trying to be the god of war in the game about being the god of war. And then I’d said the part I should have heard more carefully the first time: if all you do is hand someone a game with no context and tell them to play it, what can they possibly give you back?
“You just point out all the — everything that’s wrong with it,” I’d said. “Well, yeah, this button doesn’t work. Oh, the border radius is off by this many pixels.“ Because, I’d told him, “I need to justify my position, and you’re not giving me a lot to work with.”
The border radius. That’s the picture I can’t shake now. A person who was hired to protect the quality of your product, reduced to counting pixels, because counting pixels is the only thing left to do when nobody told them what the product was for. The nitpicking isn’t pettiness. It’s a person doing the only job you actually gave them.
Khurram takes the idea somewhere I hadn’t. The difference between a developer and a tester, he tells me, isn’t seniority or skill. It’s what they do with a user story.
“If you share a user story,” he says, “the developer will think, Oh, I need to implement this user story, and I have to write the code this way. But a tester needs to think of everything around that user story.”
He lets that sit, and then sharpens it.
“What is not written in that user story is what a tester has to think about.”
This is the whole craft compressed into a sentence. The developer builds what the story says. The tester is responsible for the negative space — every way a real person will use the thing that nobody bothered to write down, because the feature you shipped to be used one way will reach a customer who uses it some other way entirely. And a person can only see the negative space if you’ve shown them the whole picture first. You cannot ask someone to imagine what’s missing from a document they were never given.
Which is when Khurram describes the trap his testers live inside, and I recognize it as the exact trap I’ve been blaming them for.
“QA guys have this problem,” he says. “If they don’t report everything, then the team says, Oh, you didn’t report this. And if they over-report, then people say, Oh, you are wasting your time, because we have to filter out all the unnecessary stuff.“
So the tester logs everything, including the border radius, because the one time they don’t log something it becomes the thing that shipped, and then it’s their fault. Over-report and you’re nitpicky. Under-report and you’re negligent. There is no safe move available to a person who doesn’t know what matters. The double-bind isn’t a personality flaw in the QA team. It’s the predictable output of a system where nobody told them what to care about.
I say it out loud, because by now it’s the only honest thing left to say. If QA is being nitpicky, it’s my fault — because they don’t know what to look at. They don’t know what to evaluate.
Khurram answers with a question I’ve been circling the entire conversation without landing on.
“What is the priority?”
He says it like the question contains its own answer, and it does. “As a product manager,” he says, “you must prioritize it for them. You must tell them, Look, in terms of priority, these are the features that we need to look at.“ Not because the tester is incapable of judgment — the opposite. He’s clear that QA needs to come back with their own opinion, their own suggestions, their own sense of where the product could be better. But the priority, the frame, the this is what good looks like for this release — that has to come from the person holding the vision. That’s not testing work. That’s product work. I’d been outsourcing my own job and then resenting the people I outsourced it to for doing it badly.
There’s a number Khurram offers that makes the cost of getting this wrong concrete. He tells me you are far better off having a QA person hand you two extra bugs than having a customer send you a single one. The math isn’t close. A bug a customer finds engages your support team, your developers, your reputation, and your own attention, all at once, at the worst possible time. A bug your tester finds costs you a conversation. The nitpicky QA person you’ve been quietly resenting is the cheapest insurance you will ever buy, and the resentment is just the sound of you misreading the invoice.
Near the end, Khurram makes the shift explicit, and it reframes the whole category for me. Imagine, he says, the tester comes back not with a list of broken buttons but with something else: I used this. Here’s how you could make it better.
“QA shifts, in my opinion, from a cost center to a value center,” he says, “the moment you start thinking of QA as not just somebody finding me issues.”
I’ve spent years treating the QA function as a tollbooth between me and shipping.
A job family that exists to slow me down — and occasionally to embarrass me.
Khurram has spent his career on the other side of that glass, watching product managers like me hand a finished build to a stranger, withhold every reason to care about it, and then take the resulting pixel-counting as proof that testing is a tax.
The border radius was never the problem. The border radius was the answer to the only question I’d actually asked.
Guest Bio: Khurram Mir
Khurram Mir is the Co-Founder and Chief Marketing Officer of Kualitatem, a specialized software quality engineering and information systems auditing firm operating across the United States, UAE, Saudi Arabia, Qatar, the United Kingdom, the Nordics, and Asia, and the Co-Founder of Kualitee, an AI-powered test management platform that grew out of Kualitatem’s internal tooling. Rising to prominence after beginning his career in software testing in 2001, Mir has spent more than two decades building the methodology and infrastructure that define enterprise QA at scale, accumulating over 500,000 hours of testing delivery and working with more than 200 client organizations across more than 350 applications.
Mir co-founded Kualitatem in 2009 on the conviction that independent quality assurance should be a non-negotiable phase of every software development lifecycle, not an afterthought appended at the end of a release cycle. The firm achieved TMMi Level 5 certification — the highest maturity designation in the Testing Maturity Model integration framework — and has maintained ISO 27001 and ISO 9001 certification for six consecutive years. Kualitatem also developed an internal training institute to build consistent QA discipline across its geographically distributed team. A banking engagement that became a defining case study demonstrated that involving QA teams at the requirements stage — a shift-left approach — eliminated 33 percent of defects before formal testing even began.
In 2016, Kualitatem productized the internal consistency tooling it had built to maintain uniform service quality across multiple countries, launching Kualitee as a standalone test management platform. The platform’s generative AI engine produces test cases directly from user stories and test scenarios, with Kualitatem’s own teams reporting a 23 to 27 percent reduction in testing time as a result. Kualitee now serves more than 2,000 engineering teams worldwide, including clients such as Emirates, T-Mobile, and Cox Enterprises, and has been recognized by G2 as a leading test management solution across multiple regional and segment reports. Mir serves as product manager for Kualitee in addition to his operational role at Kualitatem — a dual function that reflects the firm’s broader thesis: that the services mindset and the product mindset must be learned separately, even when one organization spawns the other.
Hey,
Thanks for reading this. I mean that. There's a lot of content out there competing for your attention, and you spent some of it here. I hope it was worth it. Even better, I hope it prompted you to think about something differently enough that you'd share it with someone who'd get something out of it too.
I started this podcast because tactics never stuck with me. What stuck were stories — business biographies, autobiographies, the decisions people made and why they made them. The principle only clicks once you know the story behind it.
So I built the thing I wanted to read. Every week I have two conversations with people who build in technology and product. Then I write the essay I wish I could find — one that puts you inside the conversation, through my eyes. What caught me off guard. What I kept thinking about after we hung up. Where the principle actually lives once you strip away the jargon.
I make this for myself first. If you read the way I do, you’ll want it too.
PS — If you want to pitch coming on the show, or you know someone I should talk to, shoot me an email at caden@hey.com with "January752" in the subject line so it gets past my filters. I'm not optimizing for famous guests. I'm optimizing for interesting conversations, even from people who aren't LinkedIn influencers.
