I’m Sujith SH, currently working as an Intermediate QA Automation Engineer at Evertz Microsystems. Over the last 5 years, I’ve built my career at the intersection of product and engineering—starting out in QA automation, where I focused on solving user-impacting issues, optimizing testing frameworks, and improving release reliability. At Oracle Cerner and now at Evertz, I’ve worked closely with product and engineering teams, not just validating features but shaping them.

Along the way, I realized I was most excited about influencing what we build and why, which is what led me toward product management. To structure this transition and strengthen my product thinking, I enrolled in the Product Management course at Airtribe, where I gained hands-on experience in problem discovery, user research, prioritization, and product storytelling.

My background has given me strong analytical problem-solving, cross-functional collaboration, and technical depth—skills I now want to apply in a more strategic, end-to-end product role.

I’ve really enjoyed my time in QA because it gave me a front-row seat to how users experience the product. I wasn’t just finding defects—I was often analysing patterns, identifying root causes, and suggesting improvements that shaped what eventually went live.

Over time, I realized I’m most energized when I’m not just ensuring quality, but actually influencing what gets built and why. For example, at Evertz, while testing media workflows, I noticed integration issues across devices that made setup complicated for customers. Instead of just logging defects, I suggested we explore adopting NMOS standards to simplify interoperability. After discussions with product and engineering, the idea was incorporated into planning. As a result, setup time for cross-device workflows was reduced by nearly 25%, and defect reports related to device compatibility dropped by around 30%. That experience made me realize I’m energized not just by finding issues, but by shaping solutions that directly improve the customer experience.

So, moving into product management feels like a natural progression. My QA background has trained me to think critically about edge cases, system reliability, and user trust, and now I want to take that further by owning the problem discovery, prioritization, and roadmap decisions that directly impact customer experience and business growth.

My greatest strength is bringing clarity to complex, ambiguous situations by combining technical depth with a strong user-first mindset.

Coming from QA, I’m trained to see patterns, edge cases, and system-level impacts that others might miss. But I don’t stop at finding problems—I focus on framing them in a way that aligns engineering, product, and business stakeholders around the right priorities.

I also bring adaptability. In product work, priorities shift, trade-offs emerge, and new information often changes the path forward. I’ve learned to stay flexible without losing sight of the bigger goal—adjusting plans, re-prioritising, and keeping the team aligned even when things change.

For example, at Evertz, while testing media workflows, I noticed integration issues that made setup unnecessarily complex. Instead of just raising defects, I mapped out the root cause, suggested adopting NMOS standards, and worked with product and engineering to evaluate trade-offs. That shift reduced setup time by ~25% and cut device-compatibility issues by ~30%. What started as a QA observation became a product improvement because I could bridge technical detail with business and user impact—while adapting the solution approach as constraints and feedback evolved.

As a PM, I see this combination—clarity in ambiguity and adaptability—as central to driving structured prioritization, building alignment across teams, and ensuring we’re solving the right problems, not just shipping features

My greatest strength in life is adaptability. Life doesn’t always go as planned, and I’ve faced situations where I had to move to new places, adjust to unfamiliar environments, and work through personal setbacks. Each time, I’ve learned how to quickly reassess, focus on what’s in my control, and keep moving forward.

That adaptability has shaped who I am—it helps me stay calm under pressure, adjust my path when needed, and still make steady progress toward my goals. It’s a trait that’s carried me through challenges in life, and it’s one I continue to lean on every day.

One area I’ve been working on is letting go of details and delegating more effectively. Coming from a QA background, I was trained to spot edge cases, dig into system-level issues, and make sure nothing slipped through the cracks. That attention to detail is a strength, but sometimes it makes me want to personally chase down every issue, even when it’s not the best use of my time.

As I’ve moved closer to product responsibilities, I’ve realized that my role isn’t to solve every detail myself, but to empower the right people and keep the team focused on the bigger picture. I’ve been actively practicing this by prioritizing what truly requires my input, setting clear context, and trusting engineering and design to make trade-offs within their domains. It’s been a learning curve, but I’ve already seen how stepping back at the right moments helps the team move faster and gives me more space to focus on strategy and outcomes.

In my next opportunity, I’m looking for a role where I can directly shape what gets built and why—taking ownership of problem discovery, prioritization, and strategy, not just validation after the fact.

I want to be part of a team that values user-centric thinking, where I can use my technical depth to connect engineering realities with business goals, and where I’m challenged to grow into a well-rounded product manager. Most importantly, I’m looking for a place where I can contribute to building products that truly improve people’s lives while continuing to learn from strong mentors and cross-functional teams.

I’d start by taking the conversation away from who is asking, and anchor it on impact and strategy.

Clarify the goals: First, I’d make sure we all agree on the product’s current objectives — are we optimizing for growth, retention, revenue, or efficiency? That becomes the lens for prioritization.

Assess user and business impact: I’d look at data and user insights. Which feature solves the bigger user pain or moves the needle more on our key metrics?

Estimate effort and trade-offs: Work with engineering to understand complexity. If Feature A is high impact but takes 6 months, and Feature B is moderate impact but only 2 weeks, that factors into sequencing.

Present options with transparency: I’d create a simple impact/e ffort matrix or use a prioritization framework like RICE (Reach, Impact, Confidence, Effort) to make the trade-offs clear.

Facilitate alignment: Share the analysis with both executives, walk them through the reasoning, and recommend a path. The decision then feels data-driven, not opinion-driven.

For example, if Feature A supports long-term strategy but Feature B delivers a quick win on a short-term KPI, I might recommend shipping B first while planning A in the upcoming quarter.

“My job as a PM is to move the discussion from who is asking louder to what delivers more value for users and the business, backed by data and a clear framework.”

At Evertz, I once had a conflict with a product stakeholder who was pushing hard for a quick release of a new feature. From their perspective, speed to market was critical for a client demo. From my QA standpoint, I saw stability issues that could have caused reliability problems if we rushed.

Initially, the discussions were tense—I was flagging risks while they were focused on deadlines. Instead of just saying ‘we can’t release,’ I reframed the conversation around user trust and long-term impact. I presented data on defect trends, showed how similar issues in the past had led to escalations, and proposed a compromise: we could scope down the feature to a smaller, demo-ready version that passed critical reliability checks, while planning the full rollout in the next sprint.

That approach helped shift the discussion from personal opinions to shared goals—delivering value quickly without sacrificing quality. The stakeholder agreed, the demo went smoothly, and we avoided the risk of damaging client trust.

For me, the key learning was that conflicts usually come from different priorities, not from bad intentions. By grounding the discussion in user impact and offering options, I was able to turn conflict into alignment.

At Oracle Cerner, we had a particularly challenging release cycle where the test suite kept failing due to unstable automation scripts. The team was frustrated—every failure felt like a blocker, and morale was dipping because people were spending more time debugging the framework than testing features.

I took the initiative to reframe the situation. Instead of letting everyone feel stuck, I organized a short knowledge-sharing session where I broke down the failure patterns I’d identified and proposed a new structure for how we triaged test results. I also paired up with teammates to help them quickly fix recurring issues so they could see progress.

By shifting the focus from ‘we’re stuck with broken automation’ to ‘we’re improving the framework step by step,’ the mood lifted. Within two weeks, failure rates dropped significantly, and the team felt more confident moving forward.

That experience taught me that motivating coworkers isn’t always about big speeches—it’s about creating clarity, celebrating small wins, and reminding the team that progress is possible.

You shouldn’t hire me if you’re looking for someone to just churn out code or move fast without considering the bigger picture. I thrive on solving root problems, building cohesive systems, and aligning stakeholders. If speed at all costs is the priority, I may not be the best fit. But if you’re looking for someone who can drive meaningful, scalable solutions and collaborate for long-term success, then I believe I’d bring strong value to the team.

If my team disagreed with my ideas, I wouldn’t see it as a setback—I’d see it as an opportunity to uncover blind spots and build alignment.

For example, during a release cycle, I proposed redesigning part of a workflow to simplify error handling. Some team members pushed back, saying it would delay delivery. Instead of insisting on my idea, I first listened carefully to their concerns to understand where they are coming from. Then I reframed the discussion around the bigger goal—user trust and long-term reliability—rather than just ‘my solution vs. theirs.’

To move forward, I put together a side-by-side analysis: what would happen if we shipped quickly vs. what value we’d gain from investing in a better design. I also proposed a phased approach—releasing a smaller improvement immediately while planning the full redesign in a later sprint.

That compromise helped the team feel heard and gave us common ground. The smaller release went out on time, and we avoided quality risks, while still committing to the long-term fix.

What I’ve learned is that disagreements usually come from different priorities, not resistance. By grounding the conversation in user impact and exploring options, I can turn disagreement into collaboration.

➡️ Situation:
One of the most challenging situations I faced was when a critical feature we were building was at risk of delay because of stability issues. The business team was pushing hard to meet a client commitment, while from a QA and engineering perspective, we knew the release could damage trust if it went out unstable. Tensions were high because both timelines and quality were non-negotiable in their eyes.

➡️ Task:
As someone bridging product and engineering, my responsibility was to find a way to protect user trust without derailing the business objective. I needed to de-escalate the conflict, align stakeholders, and create a path forward that balanced speed with reliability.

➡️ Action:
I approached this by first gathering data—looking at defect trends and past escalations where rushing caused client dissatisfaction. Then, instead of framing it as “we can’t deliver,” I reframed it around user trust and long-term impact. I proposed a compromise: we’d scope down the release into a smaller, demo-ready version that passed critical reliability checks, and schedule the full rollout for the next sprint. I facilitated discussions so that both product and engineering could see we were solving for the same goal: delivering value while protecting reputation.

➡️ Result:
The smaller release went out on time, the client demo was successful, and we avoided potential fallout from reliability issues. More importantly, the process helped reset how stakeholders and engineers communicated. The trust built in that moment made future negotiations far smoother.

➡️ Reflection:
For me, the biggest learning was that the hardest situations are rarely about people being “difficult”—they’re about different priorities. By grounding discussions in user impact and offering options, I was able to turn a tense conflict into alignment.

Yes, I’ve worked with clients directly — one example that stands out was at Evertz. I started noticing a recurring backlog of interoperability issues coming from one of our key broadcast clients. Their setup involved multiple vendor devices, and integration problems were slowing down their workflow.

After analyzing the backlog trends and logs, I realized many of these issues could be avoided by adopting NMOS standards for device discovery and registration. I reached out to the client to explain how NMOS could simplify their setup and improve interoperability across systems. They were open to the idea, so I collaborated with our internal product and engineering teams to validate the configuration and ensure it aligned with our roadmap.

Once implemented, the client saw setup times drop by nearly 25%, and compatibility-related defects reduced by around 30%. That experience gave me a deeper appreciation for connecting technical insight with user pain points — and reinforced my interest in product management, where I can proactively drive such solutions end-to-end.