I walked in, audited what was in flight, cut the scope in half, and shipped three features over four quarters. Then made the case to rebuild the whole thing.
I joined Impel to manage the digital imaging platform, which included the native mobile app that was in the middle of a redesign that had been stalled for over a year with no PM ownership. During that time, the customer base had shifted from SMB to enterprise. Impel signed three new enterprise customers in two quarters; one alone was uploading 1,700+ vehicles per day. The mobile app was the primary tool those customers used at scale. It was not built to support them.
The app was built for SMB: one person, one record, one linear flow. Enterprise customers ran assembly-line facilities where different specialists captured vehicle assets, images, video, and condition data, on different sections of the same vehicle, working concurrently or sequentially, sometimes in completely different areas of the building or even different buildings. The app supported neither model.
There was also a bigger question the company hadn't answered yet: were we a camera app or a workflow tool? We'd invested years building camera functionality into the app, but on-device cameras had already outpaced anything we could build. The features that actually mattered to enterprise customers were the workflows around the camera, not the camera itself. But we couldn't have that conversation until the platform was stable and delivering for the customers we already had.
"The app blocked users from moving forward unless sections were completed in order. So they did what anyone would: invented entries or marked fields complete to get past the block and back to their actual job. The record looked complete, but the data was wrong. Some of that data flowed into consumer-facing listings and wholesale condition reports, where fabricated information meant returns, disputes, and out-of-pocket costs on $20,000+ vehicles."
Field observation, Vroom auction facilityTrust was low. Customers hadn't seen a substantial product update in over a year, and one-off requests from sales and leadership were pulling engineering in every direction. The redesign already in progress had been scoped for SMB workflows that no longer matched the customer base. I audited everything, worked across the team to determine what was salvageable, and cut the scope by half. What remained was the portion still useful to enterprise customers, and that became the foundation the next two features were built on.
Three features had to land before we could pursue the bigger question of whether to rebuild: App Redesign → Butterfly 360 → Damage Tagging.
Audit the in-flight work, cut scope by half, ship the enterprise-relevant subset to stabilize the platform.
Two distinct 360° spin types per vehicle. Contractual Q2 commitment. Required parallel pipeline work from the platform team.
Full rebuild. Concurrent multi-user workflows, parallel sections, simplified taxonomy, no invented entries.
I worked with the Mobile Engineering Manager to adopt fixed 6-week cycles with a locked scope. The team needed structure that protected their focus while giving the business committed timelines to earn back trust. I ran daily stand-ups and weekly scoping sessions to descope where needed, but never to add scope. If we couldn't meet the deadline, I cut. I worked with sales, account managers, and engineering to sunset every one-off that couldn't scale, and introduced one-pagers for each initiative covering the problem, solution, timeline, development cost, and what was explicitly out of scope.
"If it can't be enabled for every customer, it doesn't survive."
Butterfly had been referenced as a contractual commitment to Cars24, but no hard deadline had been confirmed internally. I treated it as real and started preparing. I flagged it with the CPO and the international sales lead, and joined the platform team's standups so they could plan accordingly.
I chose to ship the redesign two weeks before Butterfly rather than bundling them together. The redesign had been fully tested and I wanted it stable in production before the less-tested Butterfly release went out.
Before the deadline was even confirmed, I made the call to stop Damage Tagging mid-flight and redirect the mobile team to Butterfly. By the time the deadline solidified, the mobile team's work was already done. The only blocker was the platform team's pipeline work. Because I'd been keeping them in the loop for weeks, they turned around their work over a weekend. Butterfly shipped on time.
That two-week separation paid off almost immediately. Within 48 hours of Butterfly going live, a customer surfaced a bug in the upload logic. Because the releases were separated, we isolated it to Butterfly within minutes instead of debugging across both releases at once.
Damage Tagging required a full rebuild. The existing architecture could not be extended to support concurrent multi-user workflows because it lacked any concept of independent sections. The entire flow, navigation, and state model assumed linear progression.
I conducted on-site field research at a Vroom auction facility to observe the assembly-line workflow firsthand, then pushed for budget to send the UX designer to independently validate what I'd seen. What we observed drove the redesign: sections workable in any order, soft-locking per inspector to prevent conflicts without blocking the rest of the team, and a simplified damage taxonomy that surfaces the most-used types first and guides inspectors to the right entry rather than the nearest one.
Getting this right was not just a one-off product fix. Accurate, validated damage data captured at scale was the prerequisite for future in-app condition reports and AI-powered damage detection, neither of which can be built on fabricated entries and bad data. It was also the clearest proof point that our value was in the workflow, not the camera.
After four quarters of shipping and stabilizing, the app was finally in a place of stability. I presented the case for a full rebuild to the CTO and CPO alongside the Mobile Engineering Manager, who had been waiting to rebuild this thing since before I arrived. The app was a technical nightmare, we'd backed ourselves into a corner, and the evidence we'd documented throughout the process made that clear. Now that it was stable, this was the window to invest in rebuilding it for enterprise from the ground up.
All three features shipped over four quarters. Here's what I'd do differently next time.
Late in the process, I discovered Mixpanel was partially integrated into the mobile app, a fact lost to institutional memory. If I'd found it earlier, I could have set baselines before shipping and measured each feature quantitatively: workflows, error rates, user behavior, before and after.
I carried the full load solo for most of the work. By the time I hired, the hardest parts were done. An earlier hire would have let me stay on strategy and focus on other parts of the imaging platform, instead of running delivery, ops, and stakeholder communication simultaneously.