AI Solutions Strategist
super{set} · San Francisco Bay Area · 3 wk ago
SalesFull-time
We need to produce HTML fragment with sections: headings for section headings like About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule. Use
for section headings like About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule. Use - for any list of duties/requirements/benefits, and
for prose. Do NOT repeat the job title as a heading (the page already shows it) and do NOT put Job ID / requisition numbers as headings — fold minor metadata into a short
or drop it. Preserve ALL substantive information; do NOT invent or summarize away detail. Remove cookie/navigation/legal/EEO/equal-opportunity/scam-warning boilerplate, duplicated lines, and application instructions. IMPORTANT: include a section ONLY when the posting has real, specific content for it — never emit a heading followed by filler/placeholder text (e.g. "commensurate with experience", "not specified", "N/A", "varies", "TBD") and never create Pay/Schedule/Benefits sections unless the posting actually states them. Prefer a few substantive sections over many thin ones. Output ONLY the HTML fragment — no /, no markdown code fences.
We need to parse the posting.
First line: "Location: San Francisco Bay Area or New York City, with frequent travel as needed. Format: In-office 4 days a week with flexibility for the occasional remote days". This is location and format. Not a heading. Could be a short paragraph.
Then "Fricative Mission Businesses make consequential decisions..." This is about the mission. Could be "About the role" or "About the company". The instruction says use
for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). So we can have "About the role" heading for mission description.
Then "The Role" heading: we can treat as "Responsibilities" maybe. The content after "The Role" describes responsibilities. So we can have Responsibilities
and then list bullet points.
Then "What You’ll Own" maybe also responsibilities or "What You'll Own". Could be part of responsibilities. Could be separate "What You'll Own" but not in list of allowed headings. We can combine into Responsibilities.
Then "What Success Looks Like" maybe "Qualifications" or "Skills"? Actually success looks like outcomes; could be "Qualifications". But we have "What You Bring" which is qualifications/requirements. So we can have Requirements
for "What You Bring". Then "Nice to Have" could be "Preferred Qualifications" but not in allowed headings; maybe we can include under Requirements as a sublist? But we should not create extra headings not listed unless needed. However we can still include content under Requirements heading, with bullet points for Must Have and Nice to Have.
Then "The Opportunity" maybe "Benefits"? Not exactly. Could be "Benefits" but not explicit benefits like health etc. It's more about opportunity. Could be omitted if not substantive benefits. The instruction: never create Benefits section unless posting actually states them. The posting does not list benefits like health insurance, 401k, etc. So we should not create Benefits.
Pay and Schedule: location includes schedule: In-office 4 days a week with flexibility for occasional remote days. That's schedule info. So we can create a Schedule
with that info. Pay: not mentioned, so we should not create Pay section.
Thus sections: About the role (mission), Responsibilities (The Role + What You'll Own), Requirements (What You Bring + Nice to Have), Schedule (location/format). Possibly also "Qualifications" but we used Requirements.
We need to preserve all substantive information. Let's extract.
Mission paragraph: "Fricative Mission Businesses make consequential decisions with an incomplete view of the world. What to invest in. Which customers to pursue. Where a market is moving. What risk to take. What to do next. Their own information is scattered across systems, spreadsheets, conversations, and people’s heads. Meanwhile, public filings, market activity, company announcements, and other outside signals may reveal that something important has changed. People spend enormous amounts of time piecing this together, but the reasoning behind the eventual decision often remains invisible. Fricative is building toward a Decision Management System: a way to bring those signals together and help a team answer a practical question: What should we do, why, and why now? The answers have to be more than persuasive. People should be able to see where each claim came from, how the evidence fits together, what remains uncertain, and what would change the recommendation. We’re developing this with real clients and real decisions because this is a category that doesn’t have a playbook yet. Fricative is a portfolio company of super{set}, a venture studio that conceives, funds and builds AI-native companies from formation through scale. We work alongside founders as operators, helping shape companies from day one."
That's substantive.
Responsibilities: from "The Role" paragraph through "What You’ll Own". Let's capture.
"The Role There isn't an established AI Solutions playbook to follow. You'll help write it while doing the work. The best way to build this system is to stay close to the decisions our customers are actually trying to make. You'll get close to a client's business, learn which decisions matter, how they make them today, and what they can't currently see. You'll draw out what different people know, notice where their accounts conflict, and earn enough trust to get past the polished version of how things work. You'll investigate relevant public sources, find signals worth paying attention to, and connect them with what the client knows internally. You'll use AI to gather, test, and synthesize evidence at a scale that would be difficult to manage manually. You'll turn the work into something a system can actually do. That means breaking a messy problem into the right building blocks, deciding what each skill should and should not do, and stitching those skills into a workflow that produces a useful answer. You'll test the workflow against real examples, find where skills fail, overlap or contradict each other, and tighten the system until it works reliably. When something requires an integration or capability the system doesn't have, you'll know enough to surface the gap and work with engineers to close it. Then you'll turn that work into something useful: a clear, sourced account of what is happening, a defensible recommendation, and a way for the team to act at the right time. You'll explain the reasoning to the people who will make, challenge, and carry out the decision. You'll test whether they understand and trust it, learn where the story or the system breaks down, and improve both. Some days you'll be learning a new industry. Others, you'll be chasing a surprising signal back to its source. Another day, you may be building a prototype or sitting with a client to understand why a recommendation didn't lead to action. You are the person who can figure out what the room should be building and not the one who writes the most code in the room."
Then "What You’ll Own You'll help turn real customer problems into solutions and, ultimately, into a new kind of Decision Management System: Understand the decision. Get close to the customer, learn how they make the decision today, what they know, what they're missing, and what constraints shape the choice.Investigate and frame the problem. Find and assess relevant internal and external information. Distinguish signal from noise and fact from inference, and make the alternatives, uncertainties, and implications clear.Design and build the workflow. Break the problem into the right skills and building blocks. Decide what each skill does, what it should never touch, what needs to happen before it runs, and how skills should feed into one another. Run samples, find failures and edge cases, and improve the system until the pieces work together reliably. Flag missing integrations or capabilities for engineers to build.Put working ideas in front of users, explain the reasoning, and learn whether they understand, trust, and act on them.Turn what works into a repeatable product and method for the next decision."
We can combine these as responsibilities bullet list.
Now Requirements: "What You Bring This is an unusual combination of strengths. The center of gravity isn't any one discipline. A strong GTM person knows how to listen to a customer.A strong engineer knows how to turn an idea into a working system.A strong researcher knows how to interrogate evidence.A strong strategist knows how to frame a difficult problem. We need someone who can connect those modes of thinking: moving between customer, evidence, technology, and action while keeping sight of the decision. Someone who can explore divergently, then impose useful structure. Must Have Experience taking an unclear business or customer problem, asking the right questions, and figuring out what actually needs to be solved.Ability to investigate across multiple sources, assess source quality, distinguish fact from inference, identify conflicting evidence, and explain what would change your conclusion.Experience working directly with customers or users to understand how they work, uncover needs that aren't obvious from the initial request, and turn those insights into action.Ability to think clearly and communicate clearly: separate what you know from what you believe, recognize uncertainty, challenge assumptions, change your view when the evidence changes, and explain complex work to different audiences.Enough technical understanding to work effectively with engineers and get hands-on with tools, data, APIs, automation, or AI without needing to be an engineer by training.Demonstrated use of AI tools to investigate, analyze, synthesize, prototype, automate, or solve a real problem. We care about what you've done with AI, not whether you've listed AI as a skill.Experience turning an idea, hypothesis, or insight into something tangible, testing it with real users, and learning from what happens."
Then "Nice to Have A non-linear background that doesn't fit neatly into one discipline. Maybe you've worked in consulting, research, journalism, analytics, operations, product, or a technical customer-facing role. Maybe you've built something on your own. What matters more than the label is the pattern: you found a problem, investigated it, formed a view, built or tested something, changed your mind when the evidence changed, and made the result useful to someone else. You've probably experienced one or more of these: Work in financial institutions or other information-intensive enterprises.Complex or high-stakes business decisions.Working across internal data and external or public information sources.Using AI to change a research, analysis, or customer workflow.Working with APIs, data, software systems, automation, or technical products.Translating customer problems into product or technical requirements.Working in an early-stage company or another environment without an established playbook.Building something that moved from a one-off solution to a repeatable product, workflow, or method. We want to see examples where you: Found the real problem. Investigated it. Formed a view. Built or recommended something. Tested it. Changed your opinion. Made the result useful to someone else."
We can put Must Have as bullet list under Requirements, and Nice to Have as another bullet list maybe under same heading or separate subheading? Since only allowed headings are those, we can keep under Requirements heading with two sub-lists maybe using with - and inside maybe Must Have etc. That's okay.
Now Schedule: location and format: "Location: San Francisco Bay Area or New York City, with frequent travel as needed. Format: In-office 4 days a week with flexibility for the occasional remote days". We'll put that as a paragraph under Schedule heading.
Now we need to ensure we don't include boilerplate like cookie/navigation/legal/EEO etc. There's none.
We must not repeat job title as heading. There's no explicit job title in text; maybe "The Role" but we treat as heading.
We must not put Job ID/requisition numbers as headings; none.
We must not create Pay/Benefits sections unless stated. Not present.
We must not create sections with filler text. All sections have content.
Now produce HTML fragment:
About the role
...mission paragraph...
Responsibilities
for prose. Do NOT repeat the job title as a heading (the page already shows it) and do NOT put Job ID / requisition numbers as headings — fold minor metadata into a short
or drop it. Preserve ALL substantive information; do NOT invent or summarize away detail. Remove cookie/navigation/legal/EEO/equal-opportunity/scam-warning boilerplate, duplicated lines, and application instructions. IMPORTANT: include a section ONLY when the posting has real, specific content for it — never emit a heading followed by filler/placeholder text (e.g. "commensurate with experience", "not specified", "N/A", "varies", "TBD") and never create Pay/Schedule/Benefits sections unless the posting actually states them. Prefer a few substantive sections over many thin ones. Output ONLY the HTML fragment — no /, no markdown code fences. We need to parse the posting. First line: "Location: San Francisco Bay Area or New York City, with frequent travel as needed. Format: In-office 4 days a week with flexibility for the occasional remote days". This is location and format. Not a heading. Could be a short paragraph. Then "Fricative Mission Businesses make consequential decisions..." This is about the mission. Could be "About the role" or "About the company". The instruction says use
for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). So we can have "About the role" heading for mission description.
Then "The Role" heading: we can treat as "Responsibilities" maybe. The content after "The Role" describes responsibilities. So we can have Responsibilities
and then list bullet points.
Then "What You’ll Own" maybe also responsibilities or "What You'll Own". Could be part of responsibilities. Could be separate "What You'll Own" but not in list of allowed headings. We can combine into Responsibilities.
Then "What Success Looks Like" maybe "Qualifications" or "Skills"? Actually success looks like outcomes; could be "Qualifications". But we have "What You Bring" which is qualifications/requirements. So we can have Requirements
for "What You Bring". Then "Nice to Have" could be "Preferred Qualifications" but not in allowed headings; maybe we can include under Requirements as a sublist? But we should not create extra headings not listed unless needed. However we can still include content under Requirements heading, with bullet points for Must Have and Nice to Have.
Then "The Opportunity" maybe "Benefits"? Not exactly. Could be "Benefits" but not explicit benefits like health etc. It's more about opportunity. Could be omitted if not substantive benefits. The instruction: never create Benefits section unless posting actually states them. The posting does not list benefits like health insurance, 401k, etc. So we should not create Benefits.
Pay and Schedule: location includes schedule: In-office 4 days a week with flexibility for occasional remote days. That's schedule info. So we can create a Schedule
with that info. Pay: not mentioned, so we should not create Pay section.
Thus sections: About the role (mission), Responsibilities (The Role + What You'll Own), Requirements (What You Bring + Nice to Have), Schedule (location/format). Possibly also "Qualifications" but we used Requirements.
We need to preserve all substantive information. Let's extract.
Mission paragraph: "Fricative Mission Businesses make consequential decisions with an incomplete view of the world. What to invest in. Which customers to pursue. Where a market is moving. What risk to take. What to do next. Their own information is scattered across systems, spreadsheets, conversations, and people’s heads. Meanwhile, public filings, market activity, company announcements, and other outside signals may reveal that something important has changed. People spend enormous amounts of time piecing this together, but the reasoning behind the eventual decision often remains invisible. Fricative is building toward a Decision Management System: a way to bring those signals together and help a team answer a practical question: What should we do, why, and why now? The answers have to be more than persuasive. People should be able to see where each claim came from, how the evidence fits together, what remains uncertain, and what would change the recommendation. We’re developing this with real clients and real decisions because this is a category that doesn’t have a playbook yet. Fricative is a portfolio company of super{set}, a venture studio that conceives, funds and builds AI-native companies from formation through scale. We work alongside founders as operators, helping shape companies from day one."
That's substantive.
Responsibilities: from "The Role" paragraph through "What You’ll Own". Let's capture.
"The Role There isn't an established AI Solutions playbook to follow. You'll help write it while doing the work. The best way to build this system is to stay close to the decisions our customers are actually trying to make. You'll get close to a client's business, learn which decisions matter, how they make them today, and what they can't currently see. You'll draw out what different people know, notice where their accounts conflict, and earn enough trust to get past the polished version of how things work. You'll investigate relevant public sources, find signals worth paying attention to, and connect them with what the client knows internally. You'll use AI to gather, test, and synthesize evidence at a scale that would be difficult to manage manually. You'll turn the work into something a system can actually do. That means breaking a messy problem into the right building blocks, deciding what each skill should and should not do, and stitching those skills into a workflow that produces a useful answer. You'll test the workflow against real examples, find where skills fail, overlap or contradict each other, and tighten the system until it works reliably. When something requires an integration or capability the system doesn't have, you'll know enough to surface the gap and work with engineers to close it. Then you'll turn that work into something useful: a clear, sourced account of what is happening, a defensible recommendation, and a way for the team to act at the right time. You'll explain the reasoning to the people who will make, challenge, and carry out the decision. You'll test whether they understand and trust it, learn where the story or the system breaks down, and improve both. Some days you'll be learning a new industry. Others, you'll be chasing a surprising signal back to its source. Another day, you may be building a prototype or sitting with a client to understand why a recommendation didn't lead to action. You are the person who can figure out what the room should be building and not the one who writes the most code in the room."
Then "What You’ll Own You'll help turn real customer problems into solutions and, ultimately, into a new kind of Decision Management System: Understand the decision. Get close to the customer, learn how they make the decision today, what they know, what they're missing, and what constraints shape the choice.Investigate and frame the problem. Find and assess relevant internal and external information. Distinguish signal from noise and fact from inference, and make the alternatives, uncertainties, and implications clear.Design and build the workflow. Break the problem into the right skills and building blocks. Decide what each skill does, what it should never touch, what needs to happen before it runs, and how skills should feed into one another. Run samples, find failures and edge cases, and improve the system until the pieces work together reliably. Flag missing integrations or capabilities for engineers to build.Put working ideas in front of users, explain the reasoning, and learn whether they understand, trust, and act on them.Turn what works into a repeatable product and method for the next decision."
We can combine these as responsibilities bullet list.
Now Requirements: "What You Bring This is an unusual combination of strengths. The center of gravity isn't any one discipline. A strong GTM person knows how to listen to a customer.A strong engineer knows how to turn an idea into a working system.A strong researcher knows how to interrogate evidence.A strong strategist knows how to frame a difficult problem. We need someone who can connect those modes of thinking: moving between customer, evidence, technology, and action while keeping sight of the decision. Someone who can explore divergently, then impose useful structure. Must Have Experience taking an unclear business or customer problem, asking the right questions, and figuring out what actually needs to be solved.Ability to investigate across multiple sources, assess source quality, distinguish fact from inference, identify conflicting evidence, and explain what would change your conclusion.Experience working directly with customers or users to understand how they work, uncover needs that aren't obvious from the initial request, and turn those insights into action.Ability to think clearly and communicate clearly: separate what you know from what you believe, recognize uncertainty, challenge assumptions, change your view when the evidence changes, and explain complex work to different audiences.Enough technical understanding to work effectively with engineers and get hands-on with tools, data, APIs, automation, or AI without needing to be an engineer by training.Demonstrated use of AI tools to investigate, analyze, synthesize, prototype, automate, or solve a real problem. We care about what you've done with AI, not whether you've listed AI as a skill.Experience turning an idea, hypothesis, or insight into something tangible, testing it with real users, and learning from what happens."
Then "Nice to Have A non-linear background that doesn't fit neatly into one discipline. Maybe you've worked in consulting, research, journalism, analytics, operations, product, or a technical customer-facing role. Maybe you've built something on your own. What matters more than the label is the pattern: you found a problem, investigated it, formed a view, built or tested something, changed your mind when the evidence changed, and made the result useful to someone else. You've probably experienced one or more of these: Work in financial institutions or other information-intensive enterprises.Complex or high-stakes business decisions.Working across internal data and external or public information sources.Using AI to change a research, analysis, or customer workflow.Working with APIs, data, software systems, automation, or technical products.Translating customer problems into product or technical requirements.Working in an early-stage company or another environment without an established playbook.Building something that moved from a one-off solution to a repeatable product, workflow, or method. We want to see examples where you: Found the real problem. Investigated it. Formed a view. Built or recommended something. Tested it. Changed your opinion. Made the result useful to someone else."
We can put Must Have as bullet list under Requirements, and Nice to Have as another bullet list maybe under same heading or separate subheading? Since only allowed headings are those, we can keep under Requirements heading with two sub-lists maybe using with - and inside maybe Must Have etc. That's okay.
Now Schedule: location and format: "Location: San Francisco Bay Area or New York City, with frequent travel as needed. Format: In-office 4 days a week with flexibility for the occasional remote days". We'll put that as a paragraph under Schedule heading.
Now we need to ensure we don't include boilerplate like cookie/navigation/legal/EEO etc. There's none.
We must not repeat job title as heading. There's no explicit job title in text; maybe "The Role" but we treat as heading.
We must not put Job ID/requisition numbers as headings; none.
We must not create Pay/Benefits sections unless stated. Not present.
We must not create sections with filler text. All sections have content.
Now produce HTML fragment:
About the role
...mission paragraph...
Responsibilities
About the role
...mission paragraph...