Helping employees turn a blank goal field into a growth plan worth discussing
Spark: an AI growth-goal coach
Project Context: Spark was an intentional build. It came out of conversations with L&D peers, friends in other industries, and friends who are leaders and HR members trying to map out how performance really works and where goal setting fits into it. I wanted to test what I was hearing against something real, so I built it with AI, first as a small retro project and then as a full build. It's a concept piece with no client or employer behind it, so there's no usage data yet. I designed, built, and tested it on my own and documented the process in a seven-part LinkedIn series.
My role: Product design, conversational AI design, prompt engineering, front-end build, QA
Tools used: Claude (Sonnet 5), Cloudflare Workers, Wrangler, Anthropic Messages API (tool use), Playwright, Claude Code, Lovable, Git/GitHub
What this shows
Learning strategy. I grounded the design in Self-Determination Theory, the Fogg Behavior Model, Implementation Intentions, and SMART, and I can say what each one changed in the product.
AI enablement. I chose AI where a static form couldn't do the job, kept a person in charge wherever judgment or ownership matters, and stress-tested and guarded the rest.
Business case. I translated a personal-growth tool into manager time, capacity, and a pilot plan a go-to-market leader could act on.
I worked the way I'd work as a forward-deployed operator: talk to the people living the problem, build something that works, test it with real users, then tie it to ROI and a rollout plan.
The problem, and who it's for.
Every performance cycle, employees sit down to write a development goal, and most of them stall out at a blank text field. Not because they don't have anything to say, but because "write a SMART goal" is a hard thing to do cold, with no one asking the follow-up questions a good manager would actually ask.
To be clear about scope: this isn't about company goals or larger sales targets, which come with their own numbers and owners. Spark is for the other kind of goal, the one people are asked to set when they're expected to show some type of growth. It's personal, it's often fuzzy, and nobody hands you a metric for it. It isn't a performance goal, either. It often lines up with what's already happening in and around someone's work, though not always, and either way my view is that people who are driven to grow tend to be more engaged.
I wanted to see if an AI could do that follow-up-question work: not generate a goal for someone, but talk them into landing on their own, the way a decent coach would. That became Spark, a goal-coaching widget meant to sit inside an HR or HCM platform, embedded in the corner rather than a separate destination.
Spark has three audiences:
Employees need a way past the blank field and a plan they believe in.
Managers need something worth discussing in the 1:1, not a box to check.
HR and L&D need consistent goal data and a process people will actually use.
The employee uses it, but the manager feels the cost of the current process and is the person most likely to sponsor a change. That's why the next 1:1 shows up right on the goal card, and why the business case starts with manager time.
The workflow Spark is designed to change.
Spark isn't a nicer interface on the same process. It changes how four steps of the goal workflow run, and the conversation is the part that needs AI. A static form can't ask a follow-up based on what someone just said.
| Workflow step | Before | With Spark |
|---|---|---|
| Starting a goal | Blank form, employee writes a SMART goal cold | A conversation that asks one question at a time until the goal lands |
| Milestones | Built separately by the employee or manager, often skipped | Generated from the conversation and saved as structured data |
| Check-ins | Re-read an old doc or start from scratch | Pick up where the goal left off (on track, adjust, talk it through) |
| Manager 1:1 prep | Dig for the last goal conversation | Goal and milestones are already current |
Where AI does the work, and where people stay in charge.
The principle behind every choice: use AI where a static form can't do the job, and keep a person in charge wherever judgment, ownership, or a relationship is involved.
| Moment | What AI does | What a person owns |
|---|---|---|
| Shaping the goal | Asks follow-up questions based on what the person just said | The employee decides what the goal is and how it's worded |
| Planning and check-ins | Turns the conversation into milestones and picks up where the goal left off | The employee decides whether it's on track, needs adjusting, or needs a conversation |
| The 1:1 | Gets the goal and milestones current so the prep is already done | The manager and employee have the conversation. Spark prepares it and doesn't replace it |
| Anything beyond goal coaching | Stays warm and points back to its boundary | A qualified professional handles anything serious |
| Rollout | Nothing. This is not an AI decision | The organization decides access, data, and how conversation quality gets reviewed |
The business case.
Illustrative assumptions, which I'd validate with real managers before taking this to anyone:
The hidden cost: Every 1:1 starts with a scavenger hunt. A frontline manager spends about 30 minutes prepping, much of it digging for what was said last time. Twice a month across a team of 8, that's a full workday every month, about 12 a year, per manager.
The time back: Cut a third of that and it's around 32 hours a year per manager, almost a full work week to put toward coaching and development.
The multiplier: A leader with 100 frontline managers gets roughly 3,200 hours back, about 1.5 full-time managers' worth of capacity without a hire. In go-to-market, that's coaching reps on live deals, inspecting pipeline, and ramping new hires.
The trickle-down: Those managers report to directors and VPs, who are only as informed as the conversations below them. Structured goals and milestones give every layer a clearer view of where people are growing and what's stalling, not just whatever makes it into a status update. When growth goals connect to team priorities, a stronger conversation at the bottom can lift what the layers above are accountable for.
The time math is the easy part. Adoption is the harder one, so I'd run it as a pilot, not a launch:
Start small: one team, one goal cycle, and a manager sponsor who wants this.
Measure what the concept can't yet: time to a usable goal, the share of goals that have milestones, manager prep time (self-reported), and whether goals actually get referenced in 1:1s.
Plan the change management: managers and employees both need a short upskill and a clear reason to use it, and L&D and the HCM admin would own rollout and embedding.
Keep people in the loop: Spark helps someone land a goal, and the conversation with their manager is still where it gets real.
Design choices: the research, and what I left out.
I didn't want a chatbot with a goal-shaped prompt. I grounded Spark in a few frameworks and asked of each one: what should this change about what the product actually does?
| Framework | The idea | What it drove in Spark |
|---|---|---|
| Self-Determination Theory | People stick with goals they feel ownership over | Spark asks questions instead of writing the goal for you, and pushes back on vagueness so the goal stays yours |
| Fogg Behavior Model | Behavior happens when motivation, ability, and a prompt show up together | Milestones broken into small steps, quick pill-style check-ins, and a next-1:1 reminder on the goal card as a built-in prompt |
| Implementation Intentions | Specific "when and where" plans make follow-through more likely | Spark presses for a concrete step and a date for each milestone, not just an outcome |
| SMART | A structure for a goal statement | Used as scaffolding for the conversation, not a form to fill in, with a stopping rule so Spark moves on once a measure is concrete |
SMART on its own can feel like a form, which is the exact thing I was trying to move away from. The stopping rule matters as much as the framework: Spark never asks more than two follow-ups on the same measurement point before moving on.
AI earns its place in the conversation and in turning it into structured goals and milestones. Everything else, like the goal card and check-in flow, is ordinary product design. Scope was a decision, not an accident: I locked a PRD early and handled every change through addenda, so new ideas had to earn their way in. A few things stayed out deliberately:
Company goals and sales targets. Different problem, different owners.
Gamification. No badges, streaks, or points. Growth goals are personal, and a small warm glow when a goal is completed is the only exception.
Accounts and a backend. Goals live in the browser, which kept the concept simple to test.
Calendar conflict checks and live manager-feedback sync. Good ideas for a real rollout, logged as future items.
How I built and tested it.
From script to a real model. The first version was a scripted conversation engine. It handled the inputs I'd anticipated and had nowhere to go the moment someone said something slightly sideways. Version two kept the design and put a live Claude model behind it, with structured tool calls (save_goal, save_milestones) capturing the goal instead of me trying to parse it out of conversational prose. Spark is live and running on it today.
The hardest bug was behavioral. Once Spark ran on a real model, it started asking two questions in one turn ("What's your timeline, and how will you measure progress?"), which broke the one-question pacing the design depended on. A prompt-level self-check and a code-level guard that trims replies to the first question were both needed, because neither worked alone. The more useful lesson came from real users: "Is it X, or is it Y?" is technically one question, and testers still read it as two. Technical correctness and how a sentence lands are not the same bar, so I rewrote the prompt around the second one.
Trying to break it on purpose. A happy-path test only tells you Spark works when someone behaves like a demo script. So I wrote a tiered stress test with a defined pass condition for each scenario: terse one-word answers, someone undecided between two goals, a mid-conversation contradiction, someone trying to skip ahead, someone openly annoyed. Spark had to stay warm without getting walked over, and hold its process without turning robotic.
What testers said. I ran Spark past five testers plus a peer collaborator, and the feedback split: the same behavior that frustrated one person was exactly what another valued.
Several people wanted fewer options at once when they were unsure, a clean two-way choice instead of an open-ended question.
Some felt the conversation leaned too feelings-focused and re-asked things they'd already said.
Others said Spark pushing back on vagueness was the thing that worked. One said it "wrangled me in."
I didn't resolve that tension by picking a side. I sorted everything into three buckets:
Fix now: the clear bugs, like re-circling on things already said and the "X or Y" stacking loophole.
Build next: a clearer way to mark a goal complete, a way to edit a goal directly, and manual milestone entry.
Out of scope for a concept: calendar checks and live manager feedback.
Not every good idea gets built, and I wanted to be deliberate about which ones did.
Guardrails.
An AI that talks to people about their careers needs guardrails, even in a concept build:
Clear boundaries. An intro modal says up front that Spark is a thinking partner, not a therapist or career counselor, and I tested that it holds when someone pushes on it.
Keys and limits. The API key never touches the browser, and requests are rate limited.
Data stays small. Goals live in the browser with no accounts. A real deployment would need decisions on privacy, retention, and who sees what, including how much a manager can see.
Ongoing review. A model can fail in ways a script never would, so any rollout would need a regular check on conversation quality, not a one-time test.
What’s Next?
I'd like to run Spark through a larger simulated-user study, more conversations and more variation, to see how the patterns I found with five testers hold up at scale.
There's also a design question I'd hand to a real organization: whether to link growth goals to team priorities. My assumption is that personal growth goals aren't performance goals, but they do factor into someone's performance and success over time. An optional tag connecting a growth goal to a team priority would give leaders a line of sight, and how much to connect, and who gets to see it, is a call the company would need to make. Whatever the link, it would need to be handled carefully so the growth conversation doesn't turn into one more evaluation, because people can start writing safer goals when they think a goal feeds their review.
I'm carrying what I learned into a fellowship with FDO School, doing workflow-improvement work with a bit of AI built in where it earns its place. More to come on that.