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?
I used the roadmap to plan the research and artifacts we needed to decide whether we were ready to launch.
The approach
I treated the roadmap as a sequence of evidence requests. The sprint plan tied launch readiness to specific signals: test 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.
I checked website copy against what the product could support.
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.
I used the same customer findings to update website copy, the product value map, and engineering handoffs.
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.