At Ediphi, we move fast. That’s one of the things I love about being here; the velocity is real, and you can feel it. 

But speed creates a specific kind of risk that I’ve been thinking about for a while: the faster we ship, the easier it is for the people closest to the customers to end up at the bottom of the funnel instead of the top.

And when the Support team is the last to know, everyone pays for it. 

Customers reach out confused. We scramble to learn a feature in real time. The team that’s supposed to be the experts ends up improvising. 

That’s not the experience we want to deliver, and frankly, it’s not who we want to be.

So we decided to do something about it.

Support belongs at the top of the funnel, not the bottom

Last year, I started embedding myself directly with one of our product feature teams during the full development cycle of our Milestones and Cost Trendline features. I sa tin on weekly refinement meetings, I provided feedback that I heard from users, and I led the first pass once the feature hit our staging environment.

It changed how I thought about the role of Support entirely.

By the time those features launched, I already knew every workflow, every permission edge case, every UX decision that was made and why it was made that way. Writing the support documentation was faster, the Help Center articles were more thorough, and when customers reached out, we could actually explain the why behind what they were seeing, not just the what.

The model worked. So we started scaling it.

Being the voice of the customer, before launch

One of the most valuable things Support can do during a feature build isn’t writing articles; it’s asking questions.

What happens if a Member with Read-only permissions tries to access this? What does this look like on a Project that’s mid-flight? What’s the edge case nobody’s thinking about?

Those are all questions customers will ask and, when Support is the one asking them preemptively, there’s still time to do something about it —  before a customer ever submits a ticket.

This is what I mean when I say we want to be the voice of the customer at the top of the funnel.

Our Product, Design, and Engineering teams are already building with the customer in mind; what Support brings is a different kind of proximity. We’re in the inbox. We’re on the calls. We hear the edge cases and the “wait, how does this work?” moments firsthand.

By being in the room alongside those teams early, we can layer that day-to-day customer context into a process that’s already strong, and help make sure that when something ships, it lands exactly the way it was intended. 

What does it look like in practice?

We’ve formalized this into a four-phase process that runs alongside the product development lifecycle:

1. Refinement: We join the key meetings early. We ask everything. We’re trying to understand the why and the how before a single line of code is written.

“Refinement” is essentially a recurring team meeting where we review and prepare upcoming work items before they're scheduled for development. The goal is to clarify requirements, break down large items, estimate effort, and ensure tickets are ready to be picked up in a future sprint.‍

2. Development: We stay looped in with biweekly syncs with the Product Manager and Engineering Lead. We take notes, track what’s changing, and make sure our understanding stays current.‍

3. Bug Bash: Before the company-wide bash, we go in first. We veer off the happy path. We test every permission level. We click on the things we’re not supposed to click on. That’s the job.

A “Bug Bash” is a time-boxed event where the entire team (engineers, designers, PMs, QA, sometimes even stakeholders) drops their normal work and collectively tries to find as many bugs as possible in a product or feature, usually before a major release. It's a focused, all-hands testing blitz.

4. Launch: Support docs are live, the team has been trained in a learning session, and we’re ready.

Why this matters for you

Our customers are preconstruction professionals. They’re working under real pressure, on real projects, with real deadlines. When they reach out to us, they deserve answers from people who actually understand what they’re working with.

The way we build features now makes this possible. Because by the time something reaches a customer, we’re already lived with it. We’ve tested it, questioned it, broken it intentionally, and helped shape it. That’s what gives us the depth to support them well.

It also means fewer surprises at launch. Fewer “we didn’t think about that” moments or “we need to roll back”. Fewer tickets exist simply because something confusing was shipped before anyone from Support had a chance to ask, “wait, what does this mean for the customer?”

What we’re building toward

This is still a work in progress. We’re figuring out the right cadences, the right level of involvement per feature, and how to balance this with everything else the team carries. Not everything goes according to plan, and I’ve been honest with my team about that from the start.

But we’re setting an entirely new tone: Support shouldn’t find out about new features the same time our customers do.

At Ediphi, we’re building the kind of support experience that makes customers feel like they have a team in their corner; one that actually understands what they’re working with, because we were in the room when it was made.