I turn deep-tech R&D into products that ship.
Founder's office at Ixana — I run the internal AI platforms the company plans, delivers and searches with, the Wi-R silicon programs and the patent program around them.
Selected work.
AI programs & platforms
CASE STUDIES
- Shipped internally
Ixana-Wiki — multifile RAG knowledge platform
Cut the median hunt for a document from nine minutes to under one, and put most of the company on a single search box.
- 84 of ~100
- Employees active in first quarter
- 340
- Searches per week by month 3
- 9m → 55s
- Median time to find a document
Problem. Company knowledge lived in five disconnected systems. People spent a median of nine minutes hunting for a document before giving up and asking someone — or rewriting it from scratch.
What I did. I owned delivery of a single internal knowledge platform: one searchable repository across OneDrive, ClickUp, Teams, efficiency trackers and patent records, with hybrid search, cited AI answers and role-based access.
Result. 84 of about 100 employees used it within a quarter — 100 being the current roster, up from about 50 a year earlier. Median time-to-find fell from nine minutes to under one, and duplicate document creation stopped being a weekly occurrence.
Product manager, delivery owner · Live, company-wide
- Shipped internally
Patent program operations
Owned 50+ filings across six Wi-R product lines end to end - what to protect, how broadly, when to file - with filing decisions anchored to the tapeout calendar and a drafting clock on which every date is a cited message.
- 14w → 6w
- Median disclosure to filing
- 39d → 20d n=10
- Median T0 to the firm's first draft, against a 15-day target (drafting clock)
- 19 → 2 of 54
- Active matters with no owned next action
Problem. Ixana files ~25 applications a year off five-month tapeout cycles — seventy-five people when this began. Roadmap and patent estate were one decision surface run as two, and a matter's state lived in somebody's inbox: a disclosure past its filing date was discovered, not decided.
What I did. I owned both sides: the patent estate end to end, and the six Wi-R programmes those filings protect. Underneath, a mail-triggered spine routed every document to one matter identity, and a nine-stage drafting clock read each matter's dates from mail, calendar and chat, refusing any it could not cite.
Result. Fifty-plus filings across six product lines. Nothing irreversible is automated: routing, reminders and a date read from a message, yes; a date, scope or approval decided by a machine, never. The clock's first signal, n stated: median T0 to first draft 39 → 20 days.
Product manager — patent programme owner and Wi-R product line PM · Live, running across three outside firms
- Prototype
Finance orchestrator
Built on made-up books and never rolled out: one book of accounts under six money flows, with watchers that point at problems they can prove and draft the fix while every approval stays a named person.
- 47 of 47
- Hidden problems found by the Invoice Watcher on the answer key (n = 47 + 179)
- 0 of 179
- Look-alike rows wrongly flagged (legitimate rows that resemble a problem)
- 0 of 371
- Bank matches proposed on a wrong amount (guardrail)
Problem. Money at a hundred-person chip company had two honest surfaces: the patent ledger, where every lawyer's dollar names its matter, and the Ops Desk, where every request has an owner and a spending limit. Nothing read them together. Payroll, supplier bills, cards, the web store and a research grant sat in five exports, so a bill paid twice was found by whoever happened to look.
What I did. The company asked for it and I built it in full inside the Wiki: made-up books with deliberate mistakes and fraud patterns hidden in them, nine screens that work out every number from the rows, and five watchers under one contract that may point and draft but never act.
Result. It never went to users: priorities shifted before the read-only trial on real exports was scheduled. Every figure here is a score on the made-up books, each with its sample size, and none is adoption, time saved or fraud caught.
Product manager · Prototype — proposed by the company and built in full on a synthetic ledger inside the Wiki. It never went to users: the read-only trial on real exports was never scheduled after priorities shifted.
- Prototype
AI Salary Generator
Built and never rolled out: drafts an offer range from dated comparator rows, every figure tracing to its source, and refuses the role when the rows are thin.
- 7 synthetic
- Requisitions ever run through the tool; live requisitions: none
- 4 of 7
- Refused at the evidence floor rather than given a wider band
- 6 of 26
- Agreed ranges that resolved to a dated source before build, the number the tool was meant to move
Problem. A salary range came out of a spreadsheet somebody had built, and whoever could say where its numbers came from had usually left. Of the last 26 closed requisitions, 6 agreed ranges resolved to a dated source; the other 20 resolved to an older range, to “market data”, or to nothing.
What I did. People operations asked for it; I drew the line the tool is built on — every figure computed by rule from dated comparator rows, the model writing the argument and never a number — then added an evidence floor that refuses a role rather than widening a band to cover thin data.
Result. It never went to users: the pilot was never scheduled after priorities shifted. What is structural still holds in the demo: a figure with no dated source does not render, the floor refuses a role rather than widening a band, and no figure comes from a model.
Product manager, build owner · Prototype — proposed by people operations and built end to end on synthetic comparator data. It never went to users: no live requisition was ever run through it, because priorities shifted before the pilot was scheduled.
- Shipped internally
Flow Tracker — real-time delivery pipeline diagnostics
One live view across the PS, AMS and RTL pipelines — three stage vocabularies kept, one shared surface, and an assistant that answers from filtered records or refuses.
- 26 of 31
- Leads running a weekly review in it
- 41m → 12m
- Median review preparation time
- 3 → 1
- Sources opened before a review
Problem. Every Monday, three engineering leads rebuilt the same picture by hand from a task tool, a bandwidth spreadsheet and their own memory — a median of 41 minutes each, assembled differently, so the three reviews were not comparable.
What I did. I owned a tracker that models each team's pipeline separately but presents them on one surface, with a historical delay view and an assistant that answers from filtered records rather than open-ended generation.
Result. Each team kept its own stage vocabulary — the canonical model would have been wrong for two of three — and classification ships with its correction rate on the header, where the people relying on it can see it. The assistant refuses the ranking question outright. The adoption and preparation-time figures below are the worked example.
Product manager, delivery owner · Live across three engineering teams
- Shipped internally
Team performance reporting — five teams, three windows
One engine produces the weekly, monthly and quarterly performance report for all five delivery teams — four of which had no standing report at all.
- 1 → 5
- Teams with a standing performance report
- 2 days → 12m
- Time to produce one monthly report
- 21% → 84%
- AMS delayed tasks with a stated root cause
Problem. AMS spent about two days a month on a performance report in which only 21% of delayed tasks arrived with a stated cause. The other four delivery teams had no standing report at all, and paid for that once a quarter in a lead's week.
What I did. I split the report along a line nobody had drawn — counting is deterministic and stays rule-based, synthesis goes to a model — then made it a function of two parameters, team and window, rather than a product built five times.
Result. Five teams run one engine on three windows, nothing publishes unsigned from monthly upwards, and no count on any report is computed by a model — the signature gate and the coverage arithmetic run live in the demo. The before-and-after coverage figures below are the worked example.
Product manager, delivery owner · Live across five teams; weekly, monthly and quarterly
Silicon & systems
CASE STUDIES
- In production
Wi-R Body Area Network — YR31
Second-generation body-area silicon that holds an on-body link in the single-digit milliwatt class, roughly a tenth of the radio budget it replaces.
- 5 → 20 Mbit/s
- Link rate, gen-1 to gen-2
- 11 d → 2 d
- Median board bring-up to a stable on-body link
- 71% → 86%
- Wafer yield at production release
Problem. YR23 shipped and sold, and its own deferred list was the roadmap: a higher-rate mode, and on-die trim storage. The field agreed. The video use case carrying the volume was rate-bound at 5 Mbit/s, and the bring-up friction YR23 documented — a manual trim pass on 19 of 24 boards — cost a week every time.
What I did. I ran the loop that decided what a second spin was for: routing field feedback, yield and test data from the YR23 lots into one ranked change list, and holding the line on what gen-2 would not attempt. The hard part was refusing changes.
Result. YR31 is in production at 20 Mbit/s and sub-0.2 ms across the same 16-device network — the public spec row carries every one of those numbers. Energy per bit went the wrong way on purpose, and gen-1 stayed in production beside it so no shipping design was forced to move. The yield, test-time and interop figures below are the worked example.
Program manager, silicon delivery (RTL/AMS/PS India · HW/FW US) — ran the gen-2 change list · In production — the higher-rate part on the BAN line, alongside YR23
- In production
Wi-R Body Area Network — YR23
The first Wi-R body-area part to reach customer hardware — the silicon under the BAN dev kit and every on-body reference design that followed.
- 0.12 nJ/bit @ 5 Mbit/s
- Energy per bit delivered on first silicon
- 0 respins
- Die revisions between first silicon and production
- 11 days
- Median board build to first stable on-body link
Problem. Wi-R was a published result and a compelling demo, and no OEM puts a demo on a bill of materials. Turning it into a part meant committing to numbers across a whole data-rate ladder, on a date, against a specification an engineer could draw a schematic from before silicon existed.
What I did. I ran delivery of first silicon across five functions and two sites. The founder owned the product bets; I owned the system that turned them into a shippable part on a date — first silicon’s scope, what shipped as errata against what forced a respin, and the launch gates.
Result. YR23 is in production holding 0.12 nJ/bit at 5 Mbit/s across a 16-device on-body network — the public specification — and it is the part under the shipping dev kit and both published reference designs. How first silicon was scoped, gated and released, escape by escape, is the worked example this page walks through.
Program manager, silicon delivery (RTL/AMS/PS India · HW/FW US) — first-silicon scope and launch gates · In production — the part under the BAN dev kit and every on-body reference design since
- In production
Wi-R Near Field Electric — XA-NFE2001
The near-field electric part that moved Wi-R from a lab demonstration to a component a partner could design into a product.
- 50× vs NFC
- Energy efficiency per bit at 5 Mbit/s
- 88 of 104
- Sample requests fulfilled in the launch quarter
- 7 of 26
- NFE evaluations that reached a design-in
Problem. One product line makes a company a bet. Wi-R had proven itself on the body, and the demand arriving through the front door was increasingly not body-worn — device-to-device, at touch range, from buyers who had already rejected NFC on throughput and Bluetooth on emissions.
What I did. The founder owned the bet that a near-field line should exist. I owned turning it into a delivered part while the BAN program kept its dates: shared validation capacity, a scope built for a different buyer, and launch gates for a part that had to work on hardware we did not design.
Result. XA-NFE2001 launched at 5 Mbit/s under a milliwatt — over 50× NFC’s energy efficiency and ten times its throughput, per the published comparison — with the physics written up in an arXiv paper. It shipped as a second line while BAN kept its dates; the interop matrix that qualified it is the worked example below.
Program manager, silicon delivery (RTL/AMS/PS India · HW/FW US) — second line delivered against one validation pool · In production
- In production
Wi-R Dev Kits — BAN YR23 and NFE XA-NFE2001
Turned Wi-R eval silicon into a shipping dev kit built around one acceptance bar: open the box, reach an on-body link the same day — every variable that killed early bring-ups fixed inside it.
- 62 of 40 target
- Kits shipped over six quarters
- 28.5d → 6h
- Median time to first on-body link
- 9 of 34
- Evaluations that became design-ins
Problem. Wi-R worked in our lab and almost nowhere else. Every partner evaluation began with their engineer reproducing a body-coupled link from a datasheet, and the first six took a median of 28.5 days — most of it spent on electrode placement and grounding rather than on evaluating the technology.
What I did. I ran the dev kit program across both Wi-R families, defining the kit as the smallest object that produces a working link on day one, sequencing BAN before NFE, and trading configurability away for a fixed electrode geometry a partner could not get wrong.
Result. The kit ships through the public product page, and its whole design is the removal of variables: a fixed, characterised electrode geometry, a known-good host board, a hard power switch, the part number printed on the case. The volumes, timings and conversion figures further down are the worked example the programme was run against — including the pre-agreed floor that would have killed it.
Program manager, dev kit program · Shipping, sold through the product page
- In production
Wi-R reference designs — video smartglasses and tactical headset
Reference designs proving Wi-R carries live video to smartglasses and voice to a tactical radio over the body rather than the air.
- 11 wks → 3 wks
- Datasheet to working demo on partner hardware
- 6 of 9
- Period design-ins citing a reference design in their plan
- 2
- Verticals released with schematic, layout and BOM
Problem. The chips worked and the dev kits proved the link, and evaluations still died. Reviewing 27 that stalled showed almost none failed on the technology: they failed after the kit worked, when a team had to turn a working link into a wearable — an antenna-less RF layout problem nobody on staff had done.
What I did. I ran delivery of two complete reference designs — schematic, layout, BOM and firmware — chosen to bracket the integration questions rather than to demo well. The founder owned which markets mattered; I owned what “done” meant for a design an OEM could copy, and gated release on evaluation evidence rather than internal demos.
Result. Both designs are public and complete — schematic, layout, BOM and firmware — and both demonstrations are on video: live video into smartglasses, voice into a tactical radio, over the body rather than the air. Release was gated on a team outside the building rebuilding each one from the files alone. The cycle-time and design-in figures below are the worked example.
Program manager, reference design delivery (HW/FW US · applications and validation across both sites) — held what “done” meant for a copyable design · In production — design files released to evaluating teams
- In production
Wi-R Near Field Electric — XA-NFE3001
Successor near-field part: 20 Mbit/s PHY, ~13.5 Mbit/s real throughput — a 100 MB firmware image inside a one-minute service window, on the same sub-6 mW budget.
- 3.4 → 13.5 Mbit/s goodput
- Real throughput, gen-1 to gen-2
- 100 MB in 59 s
- Largest payload inside the one-minute window
- 9 of 14
- Stalled evaluations converted to a socket
Problem. XA-NFE2001 opened the near-field line and then kept losing the same argument. Fourteen evaluations reached a requirement sheet and stopped, and reading those sheets against our characterisation data showed why: partners were sizing real payloads, and at gen-1 throughput a 100 MB firmware image took nearly four minutes.
What I did. I ran the review that turned those requirement sheets into the gen-2 specification. This spin was pulled by a pipeline we could name rather than pushed by a roadmap, so the requirements were somebody else's document and my job was to hold scope to what those documents actually said.
Result. Real throughput went from about 3.4 to 13.5 Mbit/s — the announcement’s own figures — putting a 100 MB payload inside a one-minute service window. Gen-1 stayed in production for designs needing its longer reach, so the upgrade stranded nobody. The pipeline that pulled this spin, and what converted, is the worked example below.
Program manager, silicon delivery (RTL/AMS/PS India · HW/FW US) — ran the gen-2 specification review · In production — the higher-throughput part on the NFE line, alongside XA-NFE2001
