Author: Beau Wheeler

What was the North Star and Why?

I joined Impel to manage the digital imaging platform for automotive ecommerce, including all tools used to capture vehicle assets: video, images, and data. The scope included the native mobile app, which 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 and business strategy 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, and it was not built to support them. North Star: Make the native mobile app stable and sustainable for enterprise customers, and use that stability to answer the larger strategic questions: are we a camera or a workflow tool, and should we rebuild with enterprise use cases in mind? Three features were required before we could pursue that shift: App Redesign → Butterfly 360 → Damage Tagging Redesign.

Overall Problem and Scope

The app was built for SMBs, meaning one-person operations. Enterprise customers ran assembly-line operations across large facilities with multiple users collecting assets concurrently. The app used a linear workflow that did not support that. Features had been built one-off for individual accounts and could not scale. A custom-built camera created an ongoing maintenance burden as OS updates introduced compatibility issues. Significant product and tech debt had accumulated, with little institutional knowledge still available. Trust was low. Customers had not seen a substantial product update in over a year. One-off requests from sales and leadership were constantly pulling engineers in multiple directions. The in-flight redesign was no longer viable as originally scoped. It had been designed for SMB workflows that no longer matched our growing customer base. My first priority was to audit everything in progress, work across the team to determine what was salvageable, and cut the scope by half. What remained was the portion still useful to enterprise customers. That became the foundation on which the other two features were built.

Dependencies and Challenges

Almost every mobile feature required parallel work across two teams: a six-person mobile engineering team and a shared platform team supporting multiple verticals, including the digital imaging platform. The platform team had to build new pipeline support for every capability we shipped. Butterfly 360 required them to process and deliver two distinct $360^{\circ}$ spin types per vehicle. Damage Tagging required an updated data taxonomy for new damage locations and tags. The platform team’s capacity was constantly reprioritized against broader company needs, meaning sequencing and dependency management were as critical as the work itself. I worked with the Mobile Engineering Manager to adopt fixed 6-week cycles with a locked scope. The team needed a structure that protected their focus while giving the business committed timelines to earn back trust. The longer cycles gave us lead time to slot mobile work into the platform team’s roadmap. I ran daily stand-ups with the mobile team and weekly scoping sessions to descope where needed, but never added to the original scope. The overall idea was that if we couldn’t meet the 6 -week deadline, I would decide what to remove from the scope. The defining moment came mid-cycle. Butterfly had been referenced as a contractual commitment, but no hard deadline had been confirmed internally. I raised it repeatedly with the CPO and the international sales lead. I joined the platform team’s standups and flagged

Butterfly as an upcoming priority so their team could plan accordingly. I made the call to stop Damage Tagging, which was actively in flight, and redirect all of the mobile team’s engineering resources to Butterfly. I framed the trade-off for the CPO, a multi-million-dollar contract versus an in-flight feature, and got alignment to pause and resume after delivery. Because I had been pre-loading the platform team for weeks, they turned around their pipeline work over a weekend. Butterfly shipped on time.

Trade-offs and Deciding Non-Goals

I shipped the redesign two weeks before Butterfly and chose not to bundle the work, even though both targeted the end of Q2. The redesign needed time to stabilize before the lesstested Butterfly release. Within 48 hours of the Butterfly rollout, a customer surfaced a critical bug. The platform’s upload logic was replacing all existing vehicle spins instead of appending to them, wiping out all previously uploaded content. We paused the staggered rollout immediately, emailed customers, and had account managers call key accounts to hold off upgrading. The two-week separation meant we could instantly isolate the issue to the Butterfly feature. Non-goals were explicit. No feature was built unless it was valuable to all customers. I sunsetted non-scalable features with executive buy-in on an ‘all or none’ policy; if a feature couldn’t be enabled for every customer, it didn’t survive. Many existing features were technically only usable by one or two accounts and could never scale beyond them. I introduced one-pagers for each initiative covering the problem, solution, timeline, development cost, and out-of-scope items. Weekly product updates to the entire business during each cycle rebuilt trust in delivery.

Ownership and Hand-off

I took ownership of delivery, product operations, and product management across the mobile platform: auditing every feature flag, pulling usage data, and working with sales, account managers, and engineering to sunset what needed to go. The Mobile Engineering Manager owned the day-to-day technical execution. I owned the strategic layer: what we were building, in what order, and why. I conducted on-site field research at a Vroom auction facility to observe the assembly-line workflow firsthand, which drove the Damage Tagging redesign. I sent the junior UX designer to independently validate those findings. After we delivered the three features and stabilized the product, I presented the case to the CTO and CPO, with the Mobile Engineering Manager, explaining why we should rebuild based on the tech and product debt I had documented throughout the process and the new enterprise use cases. Once that path was established, I hired a Senior Product Manager to own native mobile going forward so I could focus on the broader platform.

Reflection

We delivered all three features over four quarters. The redesign, originally scoped for four quarters, shipped in two after I audited and cut the scope by half to focus on what enterprise customers needed. Damage Tagging false records decreased steadily post-release, and Butterfly met its contractual Q2 deadline. The majority of the success measurement was qualitative. Late in the process, I discovered that Mixpanel was partially integrated into the mobile app, a fact lost to institutional memory. If I had found it earlier, I could have set baselines before shipping and measured the impact of each feature quantitatively, showing how workflows, error rates, and user behavior changed before and after each release. I also would have pushed to hire a Senior PM earlier. I carried the full load solo for most of the work, and by the time I hired, the hardest parts were done. An earlier hire would have let me stay on strategy and focus on other areas of the imaging platform, rather than running delivery, ops, and stakeholder communication simultaneously.