What this role actually is

You sit between raw insight and shipped product. That means two things that most people treat as separate jobs:

- Conception. You generate and sharpen ideas, not just receive them. You use AI — aggressively — to prototype concepts, stress-test assumptions, explore edge cases, and pressure‑check requests before they become roadmap. When someone says "we should do something about X", you come back with three structured options and a recommendation, not a question about requirements.
- Definition. You turn the approved direction into specifications that are precise enough to build from and specific enough to test. Ambiguity in a spec is a defect. Engineers should not be asking clarifying questions mid‑build — because you anticipated them.

What you will own

- Idea sharpening. A rough signal from a client call, a sales conversation, or a competitor move — you pick it up, run it through structured analysis, and return a framed proposal: the problem, the options, the tradeoffs, a recommendation.
- Functional definition. Acceptance criteria that are actually testable. Edge cases that are actually covered. A spec that reads like it was written by someone who has thought about every state the feature can be in.
- Deep application knowledge. You will know our product and the advisor workflow it serves better than almost anyone — well enough to spot when a request is really a symptom of a different problem.
- Route to market. A feature isn't done when it ships. You write the release notes, the enablement material, and the explanation the client‑facing team needs on day one.
- Unblocking. When something has been sitting in the roadmap for two months, finding out why is your job.

What we are looking for

Must have

- You use AI tools every day — not occasionally. Cursor, Claude, ChatGPT, whatever gives you leverage. You have opinions about what works and what doesn't.




- You have real working knowledge of wealth management, financial advisory, and financial planning — not as background reading, but as the lens through which you evaluate every product decision.
- You have owned a product area on a complex, data-heavy B2B product — from concept to shipped.
- You write with precision. You treat a vague requirement as a problem to solve, not a starting point to accept.
- You can sit with a user and watch them work, then translate what you saw rather than what they said.
- Fluent English and Spanish: our team works in both, our users work in one.
- You have used AI to generate prototypes, wireframe concepts, or structure functional designs — not just drafts.
- Financial services, wealth management, or another regulated domain.
- Experience writing enablement and release material, not just specifications.
- To be an engineer. You need to be precise enough that an engineer can build from what you write.
- To wait for permission to have an opinion on what the product should do next.

Boundaries, stated plainly

- Client Success owns adoption of what exists. You own definition of what doesn't exist yet.
- You write acceptance criteria; QA verifies them. Defining and verifying should not be the same person.
- Engineering decides how to build it. You decide, precisely, what it needs to do.

What success looks like at 6 months

- You're generating product ideas that make it to the roadmap — not just processing requests from others.
- Engineers stop asking clarifying questions mid-build, because the spec anticipated them.
- Releases arrive with their enablement material already written.
- Features move from roadmap to shipped at a visibly higher rate.

How we hire

- A conversation about a product area you've owned and how you drove it from idea to shipped.
- A practical exercise: we give you a real half-formed observation from our own product — you come back with a structured proposal and a spec.
- A working session with product and engineering.

#J-18808-Ljbffr

📌 Product Builder - Santander
🏢 Sherpas
📍 Santander