Web3 Should Be "Lived," Not "Studied": How Parity Is Redefining Product-First Development Under Gavin Wood's Vision

When Gavin Wood returned to Parity, the company’s mission underwent a quiet but profound shift. The focus isn’t just on optimizing blockchain protocols anymore—it’s on building products that ordinary people can actually use. At the center of this transformation is Karim Jedda, Parity’s Director of Product Engineering, a figure whose approach to problem-solving embodies a philosophy that’s increasingly rare in the Web3 space: turn curiosity into executable reality, no matter how unconventional the path.

The Maker’s Mindset: From Obsession to Innovation

Karim’s career trajectory reads like a series of tangential experiments that somehow form a coherent philosophy. He once confined his phone to a black box while feeding it AI-generated audio triggers to test whether it was actually “listening” to him for ad targeting—the experiment went viral with over a million Twitter views. He designed physical Polkadot tokens embedded with NFC chips over a weekend, not as merchandise, but as a tangible gateway into the ecosystem. He orchestrated a system where three AI agents independently vote on governance proposals, each with distinct algorithmic “personalities”—a strategist, an investor, and an economist—that filter Polkadot decisions rather than making them.

Behind each experiment lies an identical driver: obsessive curiosity that demands immediate execution. Karim describes it plainly: “Once an idea takes root in my mind, I have to make it happen. If it isn’t realized, I can’t work normally. Sometimes I can’t even eat.” This isn’t a productivity hack or a marketing strategy. It’s a compulsion that has become Parity’s unfair advantage in an industry drowning in theoretical discussions and vaporware promises.

The through-line connecting his side projects isn’t technical sophistication—it’s radical accessibility. Whether it’s generative art that proves NFTs are “actually simple,” or AI-powered dApp builders running on a home server, Karim’s work consistently asks: How do I make this so intuitive that non-technical users don’t need to understand the mechanism? This question is now the north star of Parity’s product engineering department, a team founded roughly a year ago with the hypothesis that building products would deepen protocol understanding. That hypothesis has evolved into something more ambitious: building products for Web3 users themselves, not just for developers.

Protocol-Driven by Product Need, Not the Other Way Around

Under Gavin Wood’s leadership, Parity introduced a conceptual framework dividing future products into two categories: Life (daily life applications) and Space (real-world blockchain interactions). Karim is drawn to Space—the intersection of physical interaction and decentralized verification. What does this look like? Payment terminals that accept on-chain wallets directly, with no intermediaries. Security cameras that sync across devices using blockchain consensus, automatically rejecting footage from tampered sources. Offline experiences that make the concept of “holding your own keys” visceral rather than abstract.

The ambition is radical but the methodology is disciplined. Gavin Wood has set an explicit target: deliver one minimum viable product (MVP) every two weeks. Not a finished feature—a prototype or proof of concept, deployed quickly to gather real feedback. From Parity’s current state to that velocity requires solving a specific problem: identifying what infrastructure gaps block product development. Karim’s insight is counterintuitive but powerful: in Web3, many technical decisions don’t demand heavy engineering—you simply accept blockchain’s natural speed constraints without obsessing over service architecture or database optimization. This inverts the traditional product development hierarchy. Needs come from product teams building real solutions, not from protocol engineers speculating about requirements.

For example, should Polkadot get faster? Should it prioritize storage over throughput? These aren’t abstract engineering questions—they’re answers determined by which products users actually demand. The Product Engineering department becomes a research laboratory for protocol evolution.

Building Teams That Actually Ship

As both a developer and manager, Karim operates by what he calls “persuasive leadership”—ensuring every team member understands not just the what, but the why. Why build a fully Web3 tool instead of a centralized shortcut? What advantages matter? Getting genuine buy-in matters more than compliance. Then comes structured support: documentation access, senior developer consultation windows, clear quarterly targets, and—crucially—leading by example.

This last point isn’t rhetorical. Karim doesn’t just assign projects; he participates in product squads, joins problem-solving meetings, and presents his own work alongside his team’s. Recent hackathon winners from the Product Engineering department didn’t succeed because of management directives—they succeeded because they watched their leader prototype rapidly and saw that the bar wasn’t perfection, it was iteration.

His team management philosophy also includes something Web3 often lacks: honest communication about obstacles. When teams get stuck, uncertainty paralyzes them. Karim’s role includes unblocking these moments—coordinating dependencies, clarifying direction, removing friction. The outcome: teams experience not just project completion, but the full emotional arc of development—from ideation to user feedback to iteration. This creates sustainable motivation in a space where burnout is endemic.

How to Know When You’re Done (And When You’re Just Beginning)

Success metrics shift depending on product stage. Initially, Parity validates internally—small trials, bug fixes, Web3 feature verification. Once it graduates to public release, the only metrics that matter are the ones users actually generate: adoption, retention, satisfaction, and ecosystem benefit. The core question becomes brutally simple: Are people using it? Do they like it? Do they stop if something breaks?

This pragmatism represents a clean break from academic blockchain discourse. It’s not about theoretical superiority or feature completeness—it’s about whether real humans find the product useful enough to choose it repeatedly. Failures teach faster than victories; a product abandoned after two weeks teaches more than a project frozen in perpetual development hell.

The Message to Builders: Start Where You Are

For Web3 enthusiasts burning with ideas but paralyzed by scope, Karim offers practical direction without false motivational platitudes: find the smallest viable first step. Not the minimum viable product in the startup sense, but the easiest real action that moves the concept forward. Maybe that’s recruiting one user for feedback. Maybe it’s finding someone who can validate a hypothesis. Maybe it’s coding a quick prototype to confirm technical feasibility.

The unifying principle: get something into real hands as soon as possible. Abstract ideas stay abstract until they collide with reality. Only when actual users react—“this is good” or “this is broken”—does genuinely useful information emerge. Building requires resilience, because Web3 infrastructure remains frustratingly difficult. Documentation gaps are real. Getting answers is hard. Expert availability is limited.

Yet Karim also offers something increasingly rare in Web3: genuine welcome to contributors. “If you want to contribute to making Web3 real, you’re very welcome. There’s definitely a place for you here.” Not empty recruiter speak, but a standing offer from someone whose track record proves he’ll actually help.

Why This Moment Matters for Polkadot

What’s happening at Parity under Gavin Wood’s renewed focus and Karim’s product engineering approach is a quiet inflection point. Most blockchain projects treat products as afterthoughts—nice-to-haves bolted onto infrastructure. Parity is inverting that hierarchy. Products drive protocol requirements. User feedback shapes technical roadmaps. Curiosity-driven experimentation generates the next generation of ecosystem tools.

The two-week MVP cycle, if achieved, won’t just accelerate feature shipping. It’ll establish a cultural norm: in Web3, fast iteration beats perfect planning. Small bets beat massive coordinated efforts. Real user reaction beats internal consensus. For an industry often paralyzed by either hype cycles or over-engineering, that’s genuinely disruptive.

What Web3 still lacks, Karim argued, is a human dimension. The ecosystem overflows with APIs and abstract concepts, but beneath it all are people building and using these tools. Making Web3 more “human”—more intuitive, more tangible, more immediately useful—isn’t a feature request. It’s the fundamental work that transforms blockchain from a specialized technology into infrastructure that shapes daily life.