Problem
Pier was preparing to launch its MVP, but we still needed to confirm its small-business positioning, candidate value, website promise, and feature set.
Product management proof
Roadmap Shaping Through Product Evidence
I used customer research to plan Pier's January 2026 launch, including small-business positioning, candidate value, website copy, and MVP scope.
What I owned
I updated the product value map, published small-business copy, ran targeted research, and gave interview findings to the technical cofounder for MVP decisions.
Result
We used research we could review before asking external users and partners to rely on the product.
Certain ticket names and internal source records have been summarized to preserve confidentiality.
The situation
In January 2026, Pier was preparing for an external MVP launch while the small-business hiring thesis was still being tested.
That created a real roadmap problem. We did not only need to finish features. We needed to know whether SMB owners understood the problem, whether candidate-side assumptions held up, whether the website promise matched what the product could support, and what customer learning should affect the next build priorities.
The operating question was concrete: what evidence did we need before external users touched the product?
That changed how I saw the roadmap. The work was not only sequencing features. It was deciding which artifact would make the launch decision more honest.
The approach
I treated the roadmap as a sequence of evidence requests. The sprint plan tied launch readiness to specific signals: exercise persona assumptions, identify possible launch-pipeline prospects, update the product value map, put SMB-focused homepage copy live as a testing surface, run targeted outreach to SMB owners, validate the candidate side in parallel, and deliver user-interview insights back into technical development.
The order mattered. The product value map had to change before downstream website copy, because the public product promise needed to reflect the current user, ICP, and launch feature set.
Website copy was not just marketing polish in that sequence. It was one of the places where product truth either held together or started to drift.
What I owned
- translating uncertainty into product evidence requests
- keeping website copy tied to the product value map
- using live copy as a qualitative testing surface
- turning interview learning into inputs Brandon could use for MVP feature finalization
- protecting the link between product readiness, customer signal, and launch communication
Why it matters
This is roadmap shaping under ambiguity. The roadmap question was not what the team felt like building next. It was which evidence would change the launch decision, product promise, ICP, or technical priority.
For a PM evaluator, the proof is the operating move: customer learning, website copy, product value maps, and technical handoffs stayed in one loop.
Result
We had a clearer way to connect product readiness, customer evidence, user understanding, and product communication before committing more deeply to the launch path.
What I learned
A roadmap is not just a ranked task list when the market is still uncertain. It is a model of what we need to learn, which artifact will produce that learning, and which decision should change when the evidence arrives.