Target User Validation Playbook

This playbook turns the post-public validation items in Open Source Readiness into a repeatable operating process. It is not evidence by itself. Mark the readiness items complete only after real users complete the activities and the evidence is recorded.

Goals

Use this process to answer three questions:

Do target users understand the kruntimes value quickly?
Do they have an urgent execution problem around Pod startup latency, burst throughput, or infrastructure ownership?
Is the first wedge, AI agent tools and trusted internal code-execution sandboxes, strong enough to guide near-term product work?

Target Segments

Recruit 5-8 users across these segments:

Segment	What to Look For	Strong Signal
AI agent infrastructure	Teams running trusted tools, code execution, or sandbox-like tasks for agents.	They already keep warm workers or are blocked by per-task Pod startup.
Platform engineering	Internal developer platforms that expose execution APIs to other teams.	They want Kubernetes-native ownership, RBAC, status, and runtime pool control.
CI infrastructure	Teams running many short trusted CI steps.	Cold starts or queue drain time are visible to developers.
Automation platforms	Teams running short internal scripts or operational tasks.	They need fast dispatch and clear Run status without building a full worker platform.

Avoid over-weighting feedback from users whose primary need is hostile-code isolation, mature workflow UI, event-driven serving, or cluster-level batch policy. Those users can still provide useful objections, but they should not define the first wedge.

Outreach Message

Use short, problem-focused outreach:

I'm validating kruntimes, a Kubernetes-native execution engine for running
trusted short tasks on pre-warmed Runtime Pods.

I'm looking for teams that run AI agent tools, internal code execution, CI
micro-steps, or automation tasks on Kubernetes and feel Pod startup latency,
burst queue drain, or runtime ownership pain.

Would you be open to a 30-minute conversation or trying a small demo workload?
I'm mainly trying to learn whether this solves a real problem, not to sell a
finished platform.

Interview Script

Keep the first conversation focused on current behavior, not desired features.

What kinds of short-lived execution workloads do you run today?
How are they scheduled: one Pod per task, warm workers, a queue consumer, or another system?
Where does startup latency show up for users or pipelines?
During bursts, what determines queue drain time?
Who owns the runtime image, security policy, ServiceAccount, and resource limits?
What logs, artifacts, status, cancellation, and retry semantics do users need?
What would make a Kubernetes-native warm execution pool unacceptable?
After hearing the description, how would you explain kruntimes back in your own words?
Would you try it on a real non-production workload? If not, what is missing?

Record exact wording when a user explains the project value or rejects it. Those phrases are better evidence than maintainer summaries.

Trial Task

Ask each qualified user to try one small workload:

Install kruntimes on a local or development Kubernetes cluster.
Run the Quick Start .
Run at least one end-to-end demo , preferably the workload closest to their segment.
Inspect Run status, compact outputs, and logs.
Replace the demo command with one real internal command, script, or toy version of their workload.
Record setup time, blockers, missing permissions, confusing docs, and the point where they would or would not continue.

Do not count a trial as a design-partner success unless the user runs a real or representative workload, not only a maintainer-led demo.

Evidence Template

Use one row per conversation or trial. Keep private company and person names out of public docs unless the user explicitly approves attribution.

Date	User Label	Segment	Workload	Signal	Evidence	Follow-up
YYYY-MM-DD	design-partner-a	AI infra / Platform / CI / Automation	Short description	Comprehension / Trial / Quick start / Rejection	Link to issue, Discussion, notes, or anonymized quote	Next action

Wedge Decision Rules

Evaluate the AI agent tools and trusted internal code-execution wedge with these rules:

Validate when at least two target users in the wedge run representative workloads and say the warm Runtime pool model addresses a current problem.
Keep exploring when users understand the value but have not tried real workloads yet.
Refocus positioning when users cannot explain the value in two minutes.
Shift wedge when another segment shows stronger urgency and willingness to trial, while AI/tooling users mostly identify non-goals such as hostile-code isolation or mature workflow UI.
Prioritize blockers when multiple trials hit the same missing capability, even if that capability was not on the original roadmap.

Repository metrics, stars, and downloads are context. They do not validate the wedge without user conversations and workload trials.

Weekly Review

During the first public validation period, review evidence weekly:

Count conversations, real workload trials, independent quick starts, and non-maintainer issues or PRs.
Identify repeated blockers and confusing documentation.
Decide whether the next week should focus on more interviews, demo quality, installation fixes, or product changes.
Update Adoption Signals and the roadmap only when the evidence changes the project direction.