At Builder, we’re transforming our workflows with Fusion, enabling product management, design, support, and go-to-market team members to tackle complex projects that previously would have required engineering resources or been deprioritized in the backlog.
Through interviews with our own Fusion power users, we've gathered insights on how different departments are leveraging Fusion, its impact on their work, and tips for other organizations considering adoption.
45
PRs successfully merged to the production web app from two product managers in three months*
17
PRs successfully merged to the production web app from two product designers in three months*
80%
acceptance rate for PRs authored by product managers and designers
* For context, the average full-time developer ships between 0.5 - 5 PRs per week
Link copied to clipboard!
For PMs, Fusion means fewer specs and more working prototypes. Ideas move faster when you can build instead of just write tickets. The Product Management team at Builder uses Fusion to rapidly prototype features, test concepts, collaborate with designers, and ship pull requests to our web app without requiring engineering resources upfront. This enables faster iteration cycles and more informed decision-making.
Builder product manager prototype features in Fusion, with full context of the web app, that designers can review and iterate on. For example, when customers were hitting credit limits without warning, Lead Product Manager, Adam Murray, created a working credit warning banner prototype instead of writing detailed specifications. He tagged a Product Designer for feedback: "Sajal, can you review this for placement and design?" Sajal provided Figma mockups with proper design system components, which Adam implemented in Fusion and submitted as a pull request to the engineering team.
Product managers can investigate and fix customer-reported problems on their own. When a Builder enterprise customer reported a longstanding full-screen mode bug during a product feedback call, Adam used Fusion to reproduce the issue, identify the root cause, and implement the fix. "I was able to go into Fusion, open up a content entry, make it full screen, reproduce that issue, and then tell Fusion what I wanted it to do." The fix was quickly reviewed by an engineer and deployed and the customer was thrilled with the swift outcome.
Product Managers can easily instrument their own events and quickly understand what events fire and why they fire. For example, Product Manager Saee Abhyankar uses Fusion extensively to add Amplitude tracking events without waiting for engineering sprints. "I know exactly what clicks and views I want to add events on," she explains. Fusion looks at existing events, mimics their nomenclature, and creates new tracking events. "I'm essentially just creating my ticket in the Fusion chat box, but the work is also getting done."
Beyond adding events, Saee uses Fusion to answer data questions from other teams. "A lot of times, teams from across the organization will end up asking me about certain product data. Earlier, I would have had to either talk to an engineer or go through the code base myself. Now I just ask Fusion, 'When does XYZ event fire? Show me where the tracking is implemented,' and it'll just give me a list of whatever I need."
Product teams often have hypotheses about user behavior but can face long waits to test them. At Builder, our product managers and designers ship and measure experiments completely independently. For example, Saee noticed that many users with existing repositories weren't easily finding the "Connect Repo" button on the projects page. She hypothesized that the button was placed too low. Testing this theory would typically require engineering resources for implementation, feature flag setup, and tracking instrumentation. Instead, she asked our product designer to make the iteration in Fusion and implemented a complete A/B test on her own; including Launch Darkly flags, Amplitude tracking, and proper user segmentation. Another example, Adam experimented with credit limit warnings, testing different placement options and messaging approaches by implementing working versions rather than creating static mockups.
Ideas can move from concept to working prototype to design feedback in hours instead of weeks.
Designers can see and interact with actual functionality rather than interpreting written specifications, leading to better outcomes.
Product managers can resolve customer issues immediately rather than waiting for engineering availability, improving customer experience and product adoption.
Working prototypes provide better insight into technical feasibility and user experience implications than static designs.
Build working versions of features to test concepts before creating detailed specifications. This reveals implementation challenges and opportunities earlier in the process.
Use Fusion prototypes as conversation starters with designers rather than final implementations. The goal is alignment and refinement, not perfection.
Start with simple UI fixes to understand how the tool works, build confidence, and learn best practices before tackling more complex features.
Start shipping fixes + experiments directly
Want to see how your PMs can move from roadmap to working prototypes in hours, not weeks?