VitalStaf has only a small number of clinicians for now, so a stalled onboarding step is not a percentage on a chart for Shahin Katebi. It points to one person, and the team contacts them to find out what went wrong.
The short answer: When users are not from the tech world, domain expertise decides what to build, and product data has one narrow job: locating where a user got stuck.
What Shahin Katebi trusts, and for what
| Evidence | Trusted for | Not trusted for |
|---|---|---|
| A co-founder with fifteen years in the field | What to build next | Where users actually stall |
| Session recordings and product analytics | The exact point of friction | What to do about it |
| A/B tests on a small user base | A sense of direction | A statistically sound verdict |
| Human checkpoints in agent workflows | Decisions an experienced operator should make | Nothing: they are placed on purpose |
Users who cannot write the roadmap
At VitalStaf, Shahin builds for travel nurses and staffing agencies. They are not product people and do not arrive with feature requests, so he does not ask them for any. The next feature comes from a co-founder who has spent fifteen years in the field, not from a user vote or a dashboard reading.
One trusted job for the data
Session recordings and product analytics show him exactly where a user stalled. They do not tell him what to change. At this size, the data's real value is that it starts a human conversation: the chart points at a person, and someone calls them to find out what happened.
He uses A/B tests honestly. The user base is too small for statistical authority, so a test is a directional check, held at the weight it has earned.
The same rule for software
One of his Yeka Studio products is an AI-assisted development workflow, and its design principle mirrors the rest of the interview: know exactly where an experienced operator must review. The agents work through the tools people already use, including Jira, Confluence, GitHub and n8n, so the human review happens where the team already looks.
Model choice follows the same logic. He mixes models by task, keeps each within a set cost, and does not train his own yet because he does not have enough data.
What to do with this
For a small user base, set the goal of your tracking as finding the person, not the percentage. Every onboarding step should leave enough of a trail that you can say who stalled and where, and then ask them.
For seven checks drawn from across the series, see the questions to ask before trusting a number.
Frameworks this interview tests
- Aha moment and time to value: The aha moment is the action after which users become far more likely to stay. A borrowed number misleads; your own needs a validated event and a fixed time window.
- Jobs to be done (JTBD): Clayton Christensen's jobs to be done says customers hire a product to make progress. The job decides which events matter, so interviews come before the tracking plan.
Read next in The Question
Source and disclosure
Read Issue 8 on A Founder's Friend. The full interview is for subscribers. This page paraphrases it and quotes nothing that sits behind the paywall.
Skene sponsored this research and commissioned it on a single question. A Founder's Friend ran the interviews, wrote them up and published them, and the series states that Skene paid for the research and did not direct the questions, the analysis or the conclusions. Each of the thirteen interviews was reviewed and signed off by the person in it, named or anonymous by their choice. Appearing in the series is not an endorsement of Skene, and nobody here is presented as a Skene customer.