From QA to Head of Product: What Breaking Things Taught Me About Building Them
From QA to Head of Product: What Breaking Things Taught Me About Building Them
I didn't start in product. I started by breaking things on purpose. For years my job was to find the seam where a feature falls apart, the empty state nobody designed, the timeout nobody handled, the flow that works for the demo and fails for the third user. That instinct never left me, and it turned out to be the most useful thing I brought to product leadership.
QA teaches you to distrust the happy path
Most product decks describe the happy path: the user signs up, does the thing, and is delighted. QA is the discipline of asking "and then what?" What happens when the payment is half-processed? When the tenant uploads the wrong document? When the network drops mid-transaction?
In fintech and proptech, the unhappy paths *are* the product. Money and contracts don't tolerate ambiguity. Years of testing financial systems taught me to design for the failure modes first and the demo second. A feature isn't done when it works, it's done when it fails safely.
The best product managers are professional translators
I understand engineering enough to challenge the "how," and product enough to keep everyone honest on the "why." That sentence is basically my job description.
Sitting between users, business, and engineering, my real value isn't having the best idea in the room, it's making sure the three groups are actually talking about the same thing. Engineers optimise for correctness, business optimises for outcomes, users optimise for getting on with their day. When those three drift apart, you ship the wrong thing beautifully.
Quality is a product strategy, not a phase
The biggest mistake I see teams make is treating quality as the step before launch. In a startup moving fast, that step always gets compressed to zero. So I stopped treating quality as a phase and started treating it as a property of how we work.
That means clear acceptance criteria written *before* a single line of code. It means the person who defined the requirement is in the room when it ships. It means we measure the second action, not just the first, because the first action is easy to fake and the second is where trust is earned.
What I carry from every role
Sales taught me to listen for the real need behind the stated one. Business analysis taught me to write things down until they're unambiguous. QA taught me to assume I'm wrong until the system proves I'm right. Product leadership is just all three at once, with a roadmap attached.
The path from QA to Head of Product wasn't a pivot, it was an accumulation. Every role added a lens. The job now is to keep all of them in focus at the same time, stay close to the problem, and ship work that moves the needle.
Noor skipped presentations and built real AI products.
Noor Tabbalat was part of the April 2026 cohort at Curious PM, alongside 18 other talented participants.