Kai John-Blunch

Product management proof

Prototyping For Demos And Feature Prioritization

I used prototypes, website surfaces, and demo paths to make Pier's product direction concrete enough for customers, partners, and engineers to evaluate.

Read the narrative Inspect the summary
  • Prototyping
  • Demo readiness
  • Product surface testing
  • Prioritization

Problem

The team needed shared product surfaces before committing more deeply to a product direction or asking partners to trust what was still being built.

What I owned

I built early V0 prototypes, treated the product value map and website as testing surfaces, and connected SmartApply demos to pilot communication and feature priorities.

Result

The team could test product promises, buyer comprehension, and partner readiness before overbuilding or overclaiming.

Prototype and partner details have been summarized or generalized for public use.

The situation

Before the engineered product existed, Pier still needed something concrete enough for people to react to. A product idea is easy to agree with in the abstract. It becomes more useful when a customer, partner, founder, or engineer can inspect the proposed surface.

That was true in early user interviews and again before the January 2026 MVP launch.

A prototype gave customers and engineers the same proposed experience to inspect and challenge.

The approach

I made V0 prototypes so early interview participants could react to the AI interviewer direction before Brandon’s engineering work turned the direction into the product itself.

Later, I treated the product value map and website as product surfaces. The product value map had to move first because it defined the current buyer, use case, and launch promise. Then the SMB owner copy could go live as a consistency anchor for outreach and interviews.

I kept the product value map, website, customer conversations, and engineering work consistent so we could test the same product promise.

SmartApply employer screen for creating an opportunity in the live product experiment.
The product surface made the experiment concrete: partners could inspect the opportunity flow instead of evaluating only a written product promise.

What I built

  • early V0 prototypes for discovery
  • value-map-to-website product communication flow
  • SMB owner copy used as a qualitative testing surface
  • demo framing tied to current product readiness
  • SmartApply pilot communication that connected product surfaces to partner learning and feature prioritization

Why it matters

A useful prototype reduces argument. It shows what is clear, what is still vague, and what should be made real next.

Result

The team had shared objects for customer conversations, partner demos, and feature prioritization. Product direction became easier to test because people could react to a surface, not only a description.

What I learned

Prototypes helped us compare what we intended to build with what customers understood and needed, then choose which features deserved priority.