Home

Simplifying workspace setup to accelerate customer onboarding.

I led the design of Stage Customization at DevRev, an AI-native platform that unifies customer support, product management, and software development into a single workspace. This key feature streamlined workspace setup and significantly improved onboarding efficiency for new customers.

The old setup gave every team the same fixed stages, whether or not that matched how they actually worked. We replaced it with stages teams could fully customize. So when companies moved over from tools like Jira, they could set up their workflow to look exactly like it did before, right from day one.

Role Product Designer
Collaborators 2 Frontend Engineers, 3 Backend Engineers
Year 2025 · DevRev
Product screenshot Product screenshot Product screenshot Product screenshot Product screenshot Product screenshot Product screenshot Product screenshot
Product screenshot Product screenshot Product screenshot Product screenshot Product screenshot Product screenshot Product screenshot Product screenshot

What's the problem?

A "stage" is simply a step in a team's workflow: the checkpoint an issue or ticket moves through as work gets done. For example, an engineering team's workflow might have stages like "Code Review" and then "Ready for Deploy."

Every company names and orders these steps differently based on how their team actually works (some copied their exact setup from tools like Jira). So each new customer had to set up their own stages to match their process. DevRev couldn't use one fixed set for everyone, or the tool wouldn't reflect how the customer's team actually operated.

Issue stage list
Ticket stage list
Opportunity stage list

DevRev comes with a set of default stages, designed to cover the core objects: Issues, Tickets, and Opportunities.

Why it mattered?

Yes, and the clearest proof wasn't support tickets. It was stalled deals.

One enterprise account, mid-migration from Jira, had automations wired to stage names like "Code Review" and "Ready for Deploy" that didn't exist in our defaults. Their engineering team couldn't verify those automations would survive the move, so their VP put the deal on hold. That pattern repeated: teams weren't churning because a feature was missing. They were stalling because they couldn't de-risk the switch before committing.

What they needed wasn't more defaults. It was customization: the freedom to shape stages, names, and transitions around the process they already had, instead of conforming to ours.

Is this a real problem

Migrating from Jira or Linear broke automations built around stages that didn't carry over.

Challenges & how I solved them

  1. No to little PM support. Operating without a dedicated PM, I stepped up to lead discovery and ideation. I drove active cross-functional collaboration with engineering and engaged directly with the leadership team to align on strategy, navigate trade-offs, and lock in key decisions for the MVP.
  2. Speed was non-negotiable. We shipped an initial "Unblocking" release to a smaller customer group within a single two-week sprint, using it to validate the feature's viability and gather real feedback before committing to the full build.
  3. Legacy navigation constraints. The existing system's navigation patterns couldn't be disrupted, which meant designing within existing structural limitations, not around them.

What did we ship?

Working within those constraints, we landed on a solution that didn't require a system overhaul: instead of building a separate interface for stage management, we folded stage customization directly into object configuration, giving users one clear mental model instead of two disconnected ones.

Inline stage creation, smart defaults, and simplified rules meant teams could shape the tool around their existing process without waiting on engineering, and without us touching the navigation structure the rest of the product depended on.

Re-architected object customization into a more flexible framework for future features.

Smart defaults that minimized steps and made adding stages effortless.

Brought the stage map into context, letting users rearrange stages within their workflow.

Impact

  1. Faster configuration, fewer dependencies. Configuring an object and its stages used to mean three separate screens. Now it's one inline action.
  2. Less manual intervention, more self-serve. Support tickets tied to stage workflows dropped 43%, the same signal that first flagged this as a real problem.
  3. Deals that were stalled, now moving. ~$2M in revenue unblocked from deals that had stalled specifically over stage customization.
Durga Vitankar To know more, drop an email:
Next case study

Designing clarity for enterprise identity and access