About

I learn quickly by getting close to the market, the work, and the decision.

I talk to people, study the systems around them, model the business questions underneath the surface, and turn what I find into clearer decisions, sharper arguments, or useful tools. At Pier, that product-management work shows up as roadmap, discovery, QA, workflow mapping, customer learning, and product surfaces.

I am drawn to the point where a team knows something matters, but does not yet know what decision the evidence supports. That might mean interviewing customers, mapping a workflow, modeling and testing a market assumption, building a prototype, or writing the argument that makes a decision easier to see.

I am most useful when the work cuts across customers, product, money, and execution. The useful questions are usually practical: what is actually happening, what would prove it, and what should we do before we spend more time or money?

In Pier's three-person founder team, the technical cofounder owns core-product engineering. I own the product-management function: customer discovery, workflow and roadmap decisions, onboarding UX, QA, external testing, and the use of customer feedback in engineering and product-positioning work.

I bring customer evidence, product scope, and release questions into the same decision as core-product engineering. I also designed and built the customer- intelligence learning loop that turned transcripts into source-grounded product and positioning inputs before the team changed its source of truth.

I also develop and ship Pier's marketing website and partner guide in production. Working directly in Codex, Git, and GitHub keeps me close to the point where product decisions become something a user can navigate. The same founder role has included investor narrative, financial analysis, cap-table work, and close support around the company's fundraising.

That fit is especially clear in customer-facing AI workflows: understanding the customer's operating reality, turning it into a workflow the team can execute, handling stakeholder communication, and protecting trusted live use when requirements keep moving.

I tend to own the result that requires multiple pieces to come together: the operating model, the evidence standard, the workflow, the commercial logic, and the document that lets a team decide what to build, pitch, test, or stop doing.

In a flat three-person co-founding team, that also meant doing the financial and fundraising work directly: market and competitive research, financial projections, accretion and dilution analysis, cap table management, and the investor explanation work behind the pitch. I built and delivered fundraising pitches that helped bring in VC money and investor re-ups.

Writing is part of that work for me. Not as a separate brand exercise, but as a way to test whether I understand something well enough to explain it. Good writing exposes weak thinking quickly. It also forces a decision to become legible to someone who was not in the room. That is why I care about it.

What I keep returning to

  • What are people actually doing, not just saying?
  • What do we know, and what are we repeating because it sounds plausible?
  • What would make this worth more time, money, or trust?
  • What did the customer actually ask for, object to, or misunderstand?
  • Where would a prototype, model, or workflow make the decision easier?
  • What has to be true before we ask someone else to believe this?

Connect

For professional conversations, email kjohnblunch@gmail.com or connect with me on LinkedIn. You can also review my resume.