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 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.

The useful thing about a prototype is not that it looks finished. It is that it gives people the same object to argue with.

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 value map and website as product surfaces. The 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.

That made prototyping a product-management problem, not a presentation problem. My job was to connect the source of truth, the website surface, the customer conversations, and the build work so they were testing 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 are decision surfaces. They should help the team learn whether the buyer understands the problem, whether the promise matches readiness, and what feature work deserves priority.