When Your Users Are Also Your Clients
Building a job search tool while coaching job seekers means the same friction shows up in two windows at once. Here's what happens when it does.
Something strange happens when you coach someone through a job search while also building a tool designed to automate it.
You sit across from someone (usually virtually, usually someone who’s been searching for four months and starting to lose confidence in the process) and they describe exactly the friction your product is trying to solve. You’re taking notes in two directions at once.
That’s what the last several months have looked like, with coaching clients describing their job search friction in one window and RoleNavigator users describing the same friction in another. Career coaching clients on one side. Users on the other. The intersection is where things get interesting.
What coaching teaches you that building doesn’t
When you’re writing code or designing a workflow, you work from hypotheses. You think you know which part of the job search is the most broken and why.
Then someone who’s been applying for 12 weeks tells you exactly what they’re doing, and it doesn’t match your model.
They’re not applying to too many roles. They’re applying to the wrong ones, and they know it, and they keep doing it anyway because the right ones feel like a reach. That’s not a workflow problem. That’s a confidence problem embedded in a targeting problem, and those two things need different solutions.
The tool addresses the targeting. The coaching works on what sits underneath it.
What building teaches you that advising doesn’t
Eleven years in SaaS, and I spent most of it inside teams that were buying tools rather than building them. I understood what good GTM software should do from the buyer’s seat.
Building RoleNavigator is the first time I’ve been on the other side of that equation. The gap between what a user says they want and what actually changes their behavior is real in a way that’s hard to fully understand until you’re watching what people do with the thing you built, and comparing it against what they told you they needed.
The feature someone requests isn’t always the problem they actually have. Usually there’s something simpler underneath it, and finding it requires being close enough to the friction to notice it.
What it means in practice
Right now, the coaching and the building inform each other in ways I didn’t plan for when I started either of them. When a coaching client describes a specific sticking point, that conversation often ends up shaping a product decision. When something in RoleNavigator breaks in an unexpected way, it usually reveals an assumption I was making about how people actually run a search.
Neither track works as well alone.
I don’t think I’d have built what I’m building if I hadn’t also spent the last year sitting with people who are living the problem. The coaching runs the same direction: I coach differently now because I tried to automate the advice first and learned what the advice was actually missing.
That feedback loop is the part nobody tells you about when they describe what building in public means.
The tool is at rolenavigator.com if you want to see where it is right now. The coaching is available if you need someone who’s built the thing you’re navigating.
