Kai John-Blunch

Product management proof

Turning Cold Leads Into a Smarter Job-Application Platform

I turned cold leads into pilot partners before we had a demo, then helped develop a smarter job-application platform from v0 voice-interview mockups into a tested v1 product based on the questions and feedback we got from customers.

Read the narrative Inspect the summary
  • Product definition
  • Customer learning
  • Partner onboarding
  • Metrics design

Problem

Pilot partners had committed to the vision before there was a product demo, so the team needed a concrete user path, scope, and success signal they could actually test.

What I owned

I helped define the product flow, onboarding path, success criteria, partner communication, customer-feedback loop, and v1 scope.

Result

The team delivered a tested v1 product with pilot partners and a clearer way to learn from customer questions and feedback.

Certain identifying details and artifacts have been omitted or generalized to preserve confidentiality.

The situation

I turned cold leads into pilot partners before we had a product demo. The first pitch was a vision for a voice-interview product, supported by a small deck of v0 voice-interview mockups rather than a working product.

That early commitment was valuable, but it also created the next risk: partners could not evaluate a concept forever. They needed something concrete enough to try, react to, and judge.

The challenge was not only defining the product. It was creating a credible path for external partners to use it, evaluate it, and generate useful feedback.

The operating context mattered too. Product readiness had to shape what we asked partners to trust, what we promised about near-term delivery, and how we translated questions and feedback we got from customers into partner communication.

I owned the layer between a promising conversation and a product test partners could actually judge. That meant the work had to become concrete enough for users, partners, and the internal team to see what was being tested.

The approach

I led the product-definition and go-to-market layer for the experiment. I translated the concept into requirements, validation rules, user flows, email confirmations, success criteria, outreach workflow, partner onboarding materials, fallback tests, communication plans, and feedback loops.

The important translation was between what partners had agreed to consider, what users could actually try, and what the team could credibly learn from the first product path.

The product also changed as we learned. What started as a voice-interview concept became a smarter job-application platform for v1. That was not a retreat from the original idea. It was a scope decision based on customer questions, user interviews, and partner feedback about what would be useful first.

I owned the operating layer that made the experiment real for the team: what partners would see, what candidates would experience, what evidence would count, and how feedback would return to product decisions.

The operating question was not “can we describe the idea?” It was whether we could create enough structure for partners to try it and for the team to learn from the attempt.

SmartApply employer screen for creating an opportunity in the live product experiment.
The experiment needed a partner-facing surface concrete enough for partners to try, not just a written product concept.

What I built

  • a requirements and validation specification for the live experiment
  • v0 voice-interview mockups that made the initial pitch concrete before a product demo existed
  • candidate and partner-facing user journeys
  • success criteria and business metrics
  • onboarding and enablement materials for external partners
  • partner communication materials tied to current product readiness
  • outreach workflows, email confirmations, and fallback tests
  • a structured feedback loop for product and go-to-market iteration
SmartApply sharing modal for sending an opportunity to candidates.
The sharing flow made the partner path practical: create the opportunity, share it with candidates, and start collecting real usage signal.
SmartApply candidate fit report showing the kind of output partners could evaluate.
The fit report was the evidence object partners could judge. It turned the product test into a reviewable output, not only a workflow demo.

Why it matters

The work translated an ambiguous opportunity into a live, measurable product experiment with an external learning loop. It demonstrates how I connect product definition with the operating details required to test a concept in the market.

That connection is where the ownership lived: requirements, onboarding, metrics, and follow-up were all part of the same question of whether the opportunity deserved more commitment.

The result was a test that gave the team a way to learn from real partner behavior instead of relying on enthusiasm from discovery conversations alone.

Result

We launched the product with pilot partners and delivered the operating experience to external organizations. The work gave the team a more concrete way to evaluate partner behavior, product readiness, and which commitments the product could credibly support next.

What I learned

A product experiment becomes much more valuable when the learning loop is designed alongside the user experience. Requirements, onboarding, metrics, and fallback behavior are not secondary details; they determine whether the test produces useful evidence.