Bringing a 15-year-old product back to the front of its market

Context: why this project existed

Work is increasingly complex. The moving parts to bring a product to market are larger and more intricate than they were a decade ago. Knowledge must move fluidly between teams, beyond the organization, and across geographies. Collaboration today is not what it was, and the approaches of the past will not carry the future.

GoToMeeting had been a category leader for over a decade, built on a static, organizer-centric set of principles. Those principles needed updating to serve the dynamic, distributed work patterns of today and tomorrow.

Three forces converged:

• A new generation of knowledge workers entered the workplace with fresh expectations: video as default, async-text-first, porous boundaries between work and personal tools.
• Competitors disrupted the status quo. Zoom in particular challenged the assumption that reliability was the only thing that mattered.
• The aging underlying software, however reliable, needed rebuilding to support future growth and new feature surfaces.

The market had changed. We were not going to win the next decade by polishing the last one.

---

My role

I’d been hired to lead the design of GoToMeeting’s next-generation product. The role asked for three kinds of work in roughly equal measure.

Product UX vision and direction

• Defined the UX vision with my team and aligned it with company strategy; then carried it into every quarterly planning cycle until it was operating doctrine, not slide doctrine.
• Set the design team’s priorities in partnership with Product leadership; owned the trade-off conversations when the Engineering or Product roadmaps pulled in conflicting directions.
• Guided and evaluated design work across the GoToMeeting surface area through critiques, structured reviews, 1:1s, and design-leadership workshops.

Cross-functional partnership

• Partnered with Product, Engineering, and Research at the leadership level, not as a service function, as a peer. Roadmaps were co-authored, not handed over.
• Championed Accessibility as a first-class concern within the business unit, which led to the creation of the first Accessibility Lead role on the design team.
• Worked closely with UX Research to raise the synergy between research and design, treating research as a strategic partner whose questions shaped the product vision, not a supplier of usability findings.

Team, growth, and operations

• Scaled the design team from 4 to 8, hiring across two continents and across the level range. Created and ran the onboarding course for new UX hires.
• Promoted designers under direct mentorship; Anna Mészáros’s LinkedIn recommendation speaks to that work in her own words.
• Owned design ops for the business unit: process design, tooling decisions, and the rituals (crit cadence, 1:1 templates, calibration windows) that kept the work shippable while we grew.
• Made the first UX Engineer hire on the GoTo design team during the Chameleon emergence.

---

Discovery: designing the right things

The first job was to understand the problem space honestly.

I partnered with our Research lead on four parallel missions. My role was to bring up questions and integrate findings into the product vision; the studies themselves were led by Research.

1. Benchmarking the existing product: task-based, in-person evaluations measuring satisfaction, task speed, and success rate. This established a baseline we couldn’t fall below during the rebuild.
2. Competitive analysis: close reads of incumbents (Cisco, Microsoft, Google, BlueJeans) alongside the emerging challengers (Zoom in particular), looking not just at feature parity but at the philosophical posture of each product.
3. Generative research with Generation Z: qualitative interviews with the next cohort of knowledge workers, surfacing expectations the older personas didn’t capture: video as default, the centrality of asynchronous text, the porousness between work and personal communication tools.
4. Internal stakeholder mapping: interviews with Product, Sales, CS, and Support leadership to understand what the company had previously failed to ship, and why.

The synthesis from those four streams became the foundation for the next-gen vision.

---

Designing things right: the vision and how we shipped it

The product vision drove an operating-model innovation I’m still proud of: a parallel discovery track.

The traditional product-development model has Product, Engineering, and Design moving in lockstep through delivery sprints. That worked for incremental work, but it couldn’t carry vision-stage exploration. The design questions for the next-gen product were too open for a delivery sprint to answer, and too important to defer.

With our Product and Engineering partners we created a parallel track, run by Design (with our Research lead), that operated alongside delivery. It was design-and-research-driven, ran on its own cadence, and fed into Product and Engineering with structured handoffs once a direction was high-confidence. The track was where the riskiest design work happened: early prototypes, customer co-design sessions, A/B testing on isolated surfaces, iterative testing with a recruited beta cohort.

This was not standard practice in the organization. It is now.

A few specific moves inside the track that mattered:

• Co-design with enterprise customers. We brought a curated cohort of customers into early-stage prototype sessions. They critiqued, they suggested, they were credited. Customer-led design isn’t always the right answer. But for a product whose installed base had to migrate, having those buyers feel ownership of the new direction was strategic.
• Iterative prototyping over big-bang reveals. We tested, broke, and rebuilt continuously rather than presenting finished designs and asking for approval. This compressed the feedback loop with both customers and internal stakeholders.
• A non-disruptive update model. We rebuilt the surfaces and delivered them in increments that made sense. The transition followed the users’ expectations and felt like a natural and desired evolution they more easily accepted, and it preserved the trust GoToMeeting had earned over a decade.

---

A purpose-built mobile experience for the on-the-go segment

Alongside the desktop rebuild, we consolidated GoToMeeting’s mobile experience. The legacy apps had drifted out of alignment with the desktop product over years of incremental updates: different interaction patterns, inconsistent terminology, separate roadmaps. We retired all of them.

In their place, we shipped a single new mobile app, purpose-built for the on-the-go segment of GoToMeeting users, the cohort that joins meetings from airports, between client visits, or while moving between rooms. That cohort has materially different needs from the desktop user: speed of join, one-handed control, audio-first defaults, intermittent-connectivity resilience. The new app was designed around those needs from the first sketch, not retrofitted from the desktop product, and it was a step-change improvement over the legacy apps it replaced.

The consolidation also reduced ongoing maintenance load (one app instead of several) and tightened the interaction-pattern and brand coherence across the GoToMeeting experience.

---

Founding initiatives that outlived the project

Two organizational outputs of this work outlasted the next-gen ship itself.

The Chameleon design system. I initiated the design-system project during the next-gen rebuild and built the case to leadership for staffing it as a dedicated, independent team. Chameleon now operates across the full GoTo product portfolio, owned by a team I helped found but no longer manage. Spinning a design system out of a product team and into an independent function is one of the harder org-design moves at this stage, and the right one when the system needs to serve more than one product.

The parallel discovery track. What started as a one-team operating choice became the design organization’s default for vision-stage work. The broader pattern (Product/Engineering/Design moving in lockstep on delivery, but Design leading parallel exploration on vision) outlived my tenure on GoToMeeting.

---

Outcomes

• Returned to Gartner’s Magic Quadrant Leaders Group for Meeting Solutions in 2019: the team’s explicit goal at the start of the project. The placement validated the strategic bet: we could rebuild without ceding ground to challengers.
• Maintained CSAT through migration. Most rebuild projects accept a temporary satisfaction dip as the price of progress. We held the line: the non-disruptive approach was designed for exactly this outcome.
• Zero forced upgrades. Existing customers chose when to move. This was a deliberate design and migration decision; it cost us speed and earned us trust.
• Chameleon design system spun out as an independent team, now serving the full GoTo portfolio.
• Parallel discovery track adopted as the design organization’s default working pattern for vision-stage work.

---

What I’d do differently

Two things, both about pacing.

The parallel discovery track was the right innovation, but I underestimated two kinds of resistance. The operating-model adoption (a design organization absorbing a new working pattern) needs time; I’d run the track openly with one team, then with two, before treating it as the default. The harder resistance was internal belief: the assumptions a 15-year-old market leader builds about why it leads don’t shift just because research and testing point a different direction. I’d build the change-management plan for both layers from day one (with leadership air cover and a clearer internal storytelling layer) rather than discovering I needed both after the resistance had surfaced.

We also could have over-communicated outcomes to non-design stakeholders. The Gartner Leaders Quadrant return was visible internally because it was a named goal, but the underlying user-research story (what we’d learned about Generation Z, why we built the parallel track, what customer co-design had taught us) was harder to tell at the exec table than it should have been. Director-level design work is partly the work of making the design organization legible to leadership above and beside it. I’d have invested more in that storytelling layer earlier.