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?

That is the kind of responsibility I am trying to earn: work where someone needs a clear read, a practical next step, and enough judgment to know when a sharper question matters more than a louder answer.

My recent work has mostly sat around early-stage companies and practical uses of AI. I have owned business development work, turned customer questions and objections into product specs, prototypes, roadmaps, scope decisions, and iteration priorities, built outreach and research workflows, and worked through where AI is actually useful in a workflow instead of merely impressive in a demo.

The product-management fit is the through-line: roadmap, discovery, QA, workflow mapping, customer learning, and product surfaces all had to connect to the same operating question of what the team should build, test, or stop doing next.

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.