A working hypothesis from someone who has been building this function from scratch, embedded in a revenue org, without a playbook, for eighteen months.
Figma is building something I have been building from scratch inside League for a year and a half. The difference: I was doing it inside an existing org with no mandate, no dedicated budget, and a full quota to carry. Twelve production workflows. Thirty-plus reusable Claude skills. Five departments using tools they did not ask for and now cannot work without.
The founding role framing in this JD is exactly the context I have been operating in. I was not the founding engineer. I was a BDR who built the function anyway. That is a more useful proof of concept than a job title.
The JD calls for building AI-enabled workflows from prototype to production, measuring adoption and impact, and creating reusable patterns that enable distributed adoption rather than central dependency. That sentence describes what I have been doing since early 2025.
What this role produces in 90 days depends entirely on what I find in the first 30. The sequence below is the pattern I have run at League. The specific outputs will shift once I see the actual friction points inside Figma's GTM org.
Watch reps in Salesforce and Slack, not how they are supposed to work, but how they actually work. Find the gap between the official workflow and the real one.
Identify three high-friction points. Pick one. Get alignment from SalesOps and Enablement before writing a line of code. The diagnosis is the work.
Account research automation: rep gets a pre-call brief without opening a browser. CRM hygiene automation: fields stay clean without rep input.
Both ship with adoption metrics built in from day one. Adoption below 70% at week three means the build was wrong. Fix it before moving forward.
Document the patterns. Write reusable templates and connectors so the broader GTM org can build without coming back to me. That is the exit condition for every workflow.
Define the governance model with SalesOps. Every tool I ship should make the next one easier for someone else to build.
One example from League, because one concrete example is worth more than a list of capabilities.
VP of Sales Ops at League spent four hours every Monday pulling stale pipeline by hand. I built a pipeline intelligence tool that automated the pull, tiered accounts by risk, and surfaced $13.3M in stalled deals.
She reached self-serve by session two. Building independently by sessions three and four. Research time across the BDR team dropped from roughly 3 hours per account to 15 minutes.
She did not need me in the room after week two. That was the goal from session one.
Figma's spec calls for "reusable patterns that enable distributed adoption rather than central dependency." The Marissa story is proof of that pattern. She owns the tool now. I am not a bottleneck for it.
That is the standard I would hold every build to here: not "did I ship it" but "can the team run it without me." Adoption and independence are the actual metrics.
Figma also named Anthropic's Claude directly in the requirements. Not a tool I would need to learn. A tool I have run in production for eighteen months.
Consultants diagnose and recommend. Builders diagnose and ship.
I carry a quota and build simultaneously because the tools I build are the tools I use. That is the only way to know if they actually work. Everything in this document was tested under real conditions, not in a sandbox.
"This is a thinking artifact, not a finished plan. I haven't worked with a Figma sales rep, sat in a pipeline review, or seen what the actual GTM backlog looks like from the inside, and this document makes no claim that it does. It was built after applying, as a way to show how I approach a problem when all I have is a job description and an outside view. The real plan starts after a real conversation."Dallas Andrews · andrewsdallas3@gmail.com