Problem
Pier needed someone to translate between market reality, product direction, engineering execution, stakeholder trust, and the external story.
Product management proof
Sole Product Ownership In A Founder Role
I owned the product-management function around Pier inside a small founder team: discovery, roadmap, prototypes, QA, rituals, demos, and engineering-priority translation.
What I owned
I owned the PM layer between a technical founder and a media-founder profile, turning customer signal into product direction and visible operating cadence.
Result
The team had one person accountable for keeping discovery, roadmap, QA, demos, and stakeholder communication tied to product truth.
Ownership language refers to operating responsibility around Pier, not a public claim about finalized legal equity.
The situation
The first thing to understand about my product role at Pier is that it did not come from a neat org chart. It came from the shape of the team.
Pier’s team had two other founder profiles with very different strengths. One co-founder was a career software engineer. The other was a former media founder and award-winning documentary filmmaker.
I came in between those strengths and owned the product-management function. That meant the team needed me to translate between the market, the product, the engineering work, and the external story.
The approach
I treated the role as a full PM ownership layer, not a narrow business development lane. I ran market testing and customer discovery, conducted user interviews, used early prototypes to support those conversations, translated feedback into features and roadmap priorities, managed daily rituals, QA’d what we shipped, and kept investors and strategic advisors aligned with product truth.
What I built
- customer discovery and user-interview loops
- early prototype surfaces for discovery
- roadmap and feature translation from customer signal
- daily standups, mid-days, end-of-day reviews, and planning rituals
- product-side QA and demo readiness
- stakeholder communication tied to product reality
Why it matters
The work was specific because the team needed translation. Customer feedback had to become product direction. Product direction had to become engineering priorities. Technical progress had to become demos, stakeholder updates, and decisions about what to build next.
That is the simplest way to read the rest of these case studies. I was not adjacent to product management. I was doing the product-management job in the middle of a founder team.
Result
The result was a product-management role with real ownership: discovery, roadmap shaping, prototyping, QA, agile cadence, stakeholder communication, and translation between user signal and engineering work.
What I learned
Product ownership in a small founder team means being accountable for the loop, not only one artifact inside it. The job is to keep market signal, product truth, technical progress, and external trust in contact with each other.