Beyond the Roadmap
How Builder PMs scale the projects that don't have a home
You are taking the first steps to builder PM activities:
Mocked up a UI change to show what customers are asking for
Quickly analyzed last month’s orders by segment
A set of amazing sales meetings with a solution package
Updated leadership on recent decisions
All AI-assisted and faster than you’ve ever done before. Accomplishments every day.
But each success fizzles out before adding real value to the product. Why?
Builder PM moves fall in the void between features and programs.
These aren’t roadmap features.
They aren’t formal programs either.
They sit in between, which means no team quite knows how to pick them up.
One example of this is solution packaging. Where you bring together your product, services, and workflows into something customers can actually use. It works in practice. But getting it adopted across teams is where things stall.
This article is for product managers who want to move their work forward as part of the system.
When your work doesn’t have a place
When product work reaches this point, your instinct is to keep improving the solution. Refine the package, add more data and strengthen the case.
That rarely changes the outcome.
What’s missing is a way for the rest of the team to engage with the work. Your usual ways for team evaluation, connections and building together don’t apply here. The steps that got you here bypassed the usual way work gets started.
This is exactly where solution packaging often stalls.
You’ve defined something that works with a repeatable way to solve a customer problem.
But it doesn’t fit neatly into feature delivery or existing programs.
So it gets debated instead of adopted.
You need a way for shared progress to happen. That doesn’t come from pushing harder on your own.
You don’t need a new team or org structure.
What forms instead is a temporary working group… with the people already closest to the problem.
Just a way to make progress together.
Builder PMs involve the temporary working group by:
Pulling them into the solution
Giving visual proof
Making it easy to adopt
Inserting it into the workflow
After your initial builder PM progress, you shift to shared understanding with the product team.
This is where most work either stalls or starts to move.
Moving from Permission to “Gravity”
You don’t need to wait for a mandate to take your builder PM progress further. Instead of asking people to approve your idea, you create situations where they experience its value directly.
Builder PMs get plenty of feedback and engagement as they experiment. It’s so new that no one holds back on what they think.
You can use your requirements review tactics to pull your product team in:
The Trojan Horse: Frame the builder PM idea as a “fix” for a stakeholder’s pain point. (for example, sales leadership wants quicker quotes and your solution package already defines what a ‘standard deal’ should look like)
Informal resources: using relationships to connect to shared goals (for example, a sales engineer starts using the solution package in real customer conversations to explain how everything fits together)
Case Study of One: follow one “Lighthouse Customer” using the solution package end-to-end.
A strong solution package creates gravity.
It gives teams something concrete to react to, use, and build around without needing full agreement upfront.
Once people are pulled in, they need to understand why it matters.
Show the Value Visually
Mockups work beyond engineering for builder PMs. For new approaches, visuals often work better than words to bring builder PM initiatives into development systems.
Some visual tactics builder PMs use:
Before and after: the customer’s perspective after the solution is mainstream
Operational ROI: shift away from “how much does it cost?” to “how does this make the customer’s life easier?”
Using screenshots and AI-assisted visuals, show what it’s like to live with the change.
Seeing value isn’t enough. People also need a way to act on it.
Making It Easy to Adopt
Builder PMs have an uncanny sense of resistance across the product team. Taking those skills lets you get creative in heading off concerns.
Finding the path of least resistance is acceptable at the beginning of adoption. Builder PM tactics:
Reuse, reuse and more reuse: Builder PMs repurpose what is on hand to respond to early customer interest
Throw yourself at the obstacle: Fast-moving builder PMs can’t anticipate most issues, respond when/if early blockers surface
Have a backup plan: prepare lifelines (relationships) through frequent updates
Easy to adopt is about getting to the next step. You don’t need to handle everything for broad customer usage.
And for it to stick, it has to fit into how work already happens.
Inserting into the Workflow
One of the biggest blocks for builder PMs is newness. Multiple teams having to absorb a change at the same time is usually more than many organizations can absorb.
Builder PMs use their process knowledge to insert into the usual workflow. And the workflow insertion is a pilot…not a launch.
By finding the smallest workflow changes, builder PMs make the pilot easy for the affected teams.
Shared Understanding Drives Momentum
Builder PMs own the friction from start to finish. It’s about overcoming resistance one step at a time.
Experiment and take that success through the limbo of connecting to broader strategies by:
Creating gravity that compels a look
Showing the benefits visually
Removing barriers to adoption
Inserting into the current workflow
Conclusion: Turning stalled work into shared momentum
The difference is whether the work can pull others into it and give them a way to move it forward.
Builder PM work scales when others can use it, adapt it, and build on top of it.
By creating gravity, showing value clearly, and fitting into how work already happens, you turn isolated progress into shared momentum.
Each solution package gives the organization something real to align around.
If you want to go deeper on what makes a strong solution package, I wrote about that here.
Q&A
Q1: What if there is no strategy to connect to?
That’s more common than it sounds.
In that case, your work becomes the starting point.
Not by declaring it strategic but by making it usable, repeatable, and visible.
Strategy often forms around things that already work.
Q2: Shouldn’t I just get leadership buy-in first?
Buy-in helps but early buy-in is usually abstract.
What changes decisions is when people can see and use something real.
Progress creates better conversations than proposals.
Q3: Isn’t this just more work for the product manager?
It is a different kind of work.
But without it, the work you’ve already done doesn’t compound.
This is the step that turns effort into impact.
Q4: When does this approach not work?
When:
the problem isn’t real (no one engages even after exposure)
there’s no cross-team dependency
or leadership has already made a firm directional call
Otherwise, this is often the missing step.
Q5: How do I know if it’s working?
Signals:
others start referencing your work
your artifacts get reused
conversations shift from “should we?” to “how do we?”
Looking for more practical tips to develop your product management skills?
Product Manager Resources from Product Management IRL
Product Management FAQ Answers to frequently asked product management questions
Premium Product Manager Resources (paid only) 4 learning paths, 6 product management templates and 7 quick starts. New items monthly!
Drippie Digest featured Product Management IRL articles. This newsletter has handpicked product management articles every day, summarized to give you the big picture of product management and tech.
TLDR Product featured Product Management IRL articles recently! This biweekly email provides a consolidated list of recent product management articles.
Connect with Amy on LinkedIn, Threads, Instagram, and Bluesky for product management insights daily.
Amy, this is a good way to describe where this kind of work gets stuck.
One thing I’ve seen though - even when you get that working group and some pull, it still slows down if the underlying systems can’t take it in.
A lot of these solution packages look usable on the surface, but once they hit real workflows (catalog, pricing, legacy stuff), the friction shows up again.
so it’s not just getting people to engage, but also whether the system underneath is ready for it.