Problem
Pier was preparing for an external MVP launch while the team still needed evidence that the SMB owner positioning, candidate-side value, website promise, and launch feature set belonged together.
Product management proof
Roadmap Shaping Through Product Evidence
I shaped roadmap direction by turning Pier's January 2026 launch uncertainty into evidence requests around SMB positioning, candidate value, website copy, and MVP readiness.
What I owned
I turned the uncertainty into roadmap work: update the value map, put SMB-focused copy live, run targeted validation, and deliver interview insights back to Brandon for MVP feature finalization.
Result
The roadmap moved around evidence the team could inspect before asking external users and partners to trust 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. The team 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 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 value map had to move 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 source-of-truth 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
The team had a clearer way to connect product readiness, customer evidence, user understanding, and source-of-truth 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 the team needs to learn, which artifact will produce that learning, and which decision should change when the evidence arrives.