I’d appreciate some advice on approaching OC3 from the technical side.
I’ve applied twice under Exceptional Talent. I met the Mandatory Criterion and OC2 both times and now have even stronger evidence for them. OC3 has been my main challenge.
My previous product-led company experience is now outside the five-year window, while my current company is consulting-based.
In my last application, I used my Developer Advocate work at a product-led company. The feedback was that much of it appeared to be part of my normal role and aligned more with OC2 than a significant technical/commercial contribution.
So I want to spend the next 6–12 months building two strong, verifiable pieces of technical OC3 evidence.
I’m considering:
Building my own AI product/company — although many AI products feel similar, while the infrastructure/platform ideas I’m interested in may take years to gain significant traction.
Building or substantially contributing to an open-source product — with evidence such as architecture, GitHub contributions, documentation, adoption, releases and measurable impact.
Contributing technically to an early-stage product-led startup—taking ownership of substantial engineering/product work where my personal contribution and impact can be clearly demonstrated.
Becoming a technical advisor to a product-led startup—although I’m unsure what level of advisory contribution or evidence would be considered significant for OC3.
For evidence, I’m thinking about GitHub contributions, architecture, technical documentation, product adoption/analytics, Product Hunt, independent publications/coverage, and founder/CTO letters validating my personal contribution and impact.
My main question is: Do I need substantial commercial traction for technical OC3, or can a technically substantial product/open-source project with smaller but independently verifiable adoption and impact be enough?
I’d especially appreciate hearing from anyone who has successfully used founder, open-source, engineering or technical advisory work for OC3.
The 2026 Guide frames OC3 around significant technical, commercial or entrepreneurial contribution in a product-led digital technology company. It sets no fixed revenue or user-count threshold, but asks for demonstrated impact. Modest adoption can help when you show who relied on the work, why it mattered, and your personal contribution. For open source, peer recognition that a project advances the field is a relevant example; code volume alone may leave impact unclear.
Choose a product or project where you can own identifiable technical work and track outcomes. Pair GitHub history and architecture/design documentation with independent evidence of use or influence, such as adoption data, releases or integrations, user/maintainer feedback, credible coverage, or peer recognition. Explain your role and connect each artefact to a concrete result. A founder or CTO letter can corroborate your contribution, alongside documentary evidence. Product Hunt can document a launch; sustained use or other impact evidence strengthens the picture.
Technical advisory work could support OC3 when you can document substantive product work and outcomes. Agree on specific deliverables, access to records, and measurable results early. The Guide’s examples include leading development of high-impact products, recognized field-advancing open source, and key engineering contributions to a startup’s core product linked to its success. Treat these as evidence directions, not guarantees, and build a coherent record of your own contribution and its impact.
Short answer to your main question: you don’t need large commercial traction, but you do need independently verifiable evidence that the product has real users or customers and that your contribution moved the needle. “Technically impressive but unused” is the thing to avoid. Please check all of this against the current endorsing-body guidance, as I’m going from the published criteria and common assessor feedback, not from a successful OC3 case of my own.
Why you were pushed back to OC2. Your last feedback (“part of your normal role, more OC2”) points to two separate tests:
Is it a product-led company? OC3 is about contributions to a digital technology product company. Consulting work generally doesn’t count, so your current role is unlikely to help.
Is it beyond your job description? Assessors want specific decisions you owned and outcomes they caused, not “I did my role well.”
Developer advocacy is usually read as community and outreach (OC2 territory) even when it’s technical. Open-source contribution on its own tends to get read the same way, for the same reason.
Ranking your options for OC3:
3. Founding or early engineer at a product-led startup: strongest. The company is clearly product-led, you can own a defined system, and traction is naturally evidenced (customers, revenue, users). Aim for a formal role (employee, contractor with a defined scope, or co-founder/CTO) and for ownership of something substantial like an architecture or a core feature. Get letters from the founder and customers or users, not just internal colleagues.
1. Your own product or company: strong if it gets real users. The bar isn’t unicorn traction. Paying customers, signed pilots, meaningful active usage or funding relative to stage can be enough, as long as they are verifiable (invoices or payment dashboards, customer letters, analytics with context). A product with zero external users won’t pass, however good the architecture. Incorporate the company so your role is documented.
2. Open source: works best as supporting evidence, or as the core of a company. Stars and commits alone are weak. What counts is production use by named external organisations, downloads and dependents, external contributors, releases, and case studies. If the project has a company or commercial offering around it (open-core or hosted), it fits OC3 much better than a standalone repo does.
4. Technical advisor: weakest. Advisory roles are hard to distinguish from your normal expertise, rarely show significant personal contribution, and are easy to read as OC2. It only helps if it’s formalised (contract, defined deliverables, equity) and you can show specific technical decisions with measurable results. I wouldn’t build the strategy on it.
Practical suggestion. Combine 3 with 2: take a substantial engineering ownership role at an early-stage product company and, if possible, an open-source component with real external adoption. Pick the one where independent third parties can confirm impact.
What makes the evidence persuasive:
A before-and-after for each contribution: the problem, what you decided or built, and the outcome with numbers.
Third-party confirmation (customers, users, press, platform data) over self-reported analytics. Screenshots need context and dates.
Letters that name specific work and results, not general praise.
Dates inside the five-year window. Check whether any part of your earlier product-company work falls inside it.
Two other points. Six to twelve months is tight for building traction from scratch. It’s worth checking in parallel whether OC1 (innovation, e.g. patents or awards) or OC4 (publications, peer review) is more reachable than OC3 for you, since neither requires a product company.