Product, business & communication
Translate business requirements into an AI solution design
Discovery, BRD/FRD, process mapping, solution architecture diagrams and success criteria.
~15 focused hours·intermediate
Tools: Miro/Lucidchart (process & architecture diagrams), Notion/Confluence (BRD/FRD), draw.io, Excel (as-is/to-be mapping)
Market relevance — share of job ads asking for this
What employers mean
You should be able to…
- Run discovery with a business stakeholder and produce a BRD/FRD they'd sign off on
- Map the current-state process before proposing a to-be automated/AI-assisted version
- Draw a solution architecture diagram that an engineer could actually build from
- Define success criteria that tie back to the original business requirement
- Translate ambiguous requirements ('make support faster') into measurable scope
- Identify integration points (APIs, data sources, systems of record) needed for the solution
- Flag domain-specific constraints (compliance, data residency) early in the design
Needs first: Explain how LLMs work and where they fail
Learn — free, link-checked
The few resources that matter
Read · beginner · 15 min · atlassian.com
DACI decision-making framework
A ready-to-use framework for making who-decides-what explicit when engineers and execs disagree on AI trade-offs. — Atlassian
Read · beginner · 20 min · asana.com
Process Mapping: How to Map a Process
Clear walkthrough of documenting a current-state process before you propose what to automate. — Asana
Read · beginner · 25 min · atlassian.com
Product requirements: how to write a great PRD
A concrete, widely-used PRD template and structure you can adapt for an AI feature's success metrics. — Atlassian
Read · intermediate · 40 min · docs.aws.amazon.com
AWS Prescriptive Guidance: patterns
Real solution-architecture patterns and decision guides you can mirror when writing a solution design doc. — AWS
Read · intermediate · 45 min · cloud.google.com
Google Cloud Architecture Framework
A vendor's own checklist (reliability, security, cost) for turning requirements into a defensible architecture. — Google Cloud
Practice
BRD/FRD + solution design for automating NBFC loan-document verification
Role-play discovery with an NBFC ops lead who manually checks salary slips, bank statements and ID proofs for loan applications. Produce a BRD capturing the business requirement, an FRD detailing functional behavior (what gets extracted, validated, flagged), and a solution architecture diagram showing document ingestion, an AI extraction/validation step, a human-review queue for low-confidence cases, and the system of record it writes back to.
Done when
- BRD and FRD are separate documents with distinct audiences (business vs implementation)
- Solution architecture diagram shows at least 4 components and the data flow between them
- Success criteria are measurable (e.g. '80% of documents auto-verified without human review')
- At least one compliance/data-handling constraint is explicitly addressed in the design
Prove it
Evidence a recruiter can check
- Public BRD and FRD documents
- Solution architecture diagram (Miro/Lucidchart export or image) in the repo/portfolio
- A short note on the compliance constraint considered and how the design addresses it
Interview
Questions you'll get asked
- Walk me through how you'd turn 'automate our loan document review' into a solution design.
- What's the difference between a BRD and an FRD, and when do you need both?
- How do you map a current-state process before proposing automation?
- Tell me about a requirement that turned out to be ambiguous — how did you resolve it?
- What goes into a solution architecture diagram that a PRD alone doesn't capture?
- How do you account for compliance constraints (e.g. data residency) when designing an AI solution?