When I joined Frontline Education, my responsibility quickly expanded beyond leading Design. The larger opportunity was helping transform how the organization understood customers, validated ideas, and made product decisions.

Over the following years, I helped establish discovery as an organizational capability by introducing new operating models, building a product design organization, implementing Design Sprints, expanding research capabilities, modernizing product tooling, and enabling AI-first product exploration.

The transformation wasn't about introducing new processes for UX. It was about helping Product, Design, and Engineering make better decisions together.

Frontline Education serves millions of K–12 professionals across hundreds of school districts, responsible for some of the most critical operational, instructional, and student support workflows in K–12 education.

When I joined the organization, Product teams had very limited opportunities to learn directly from customers. Research was inconsistent, largely dependent on convincing a Product Owner to make time for discovery, and customer knowledge rarely became organizational knowledge.

The consequences extended beyond UX. Customer retention had become a growing concern, and many districts felt the company no longer understood how they actually worked—Product teams were often responding to feature requests instead of understanding the underlying workflows and problems customers were trying to solve.

The feedback came directly from customers: “Frontline didn't listen to them.”

Without a repeatable discovery capability, Product, Design, and Engineering were making important decisions with incomplete information.

This wasn't simply a UX problem. It was an organizational capability problem.

Before introducing new processes or tools, I wanted to understand how product decisions were being made and where opportunities existed to improve the organization's ability to learn from customers. Over time, several consistent patterns emerged.

Discovery was largely absent from the product development process. Customer research occurred sporadically and often depended on individual initiative rather than an established practice. Teams were generally working from product requests, customer escalations, or assumptions instead of developing a deeper understanding of customer workflows and unmet needs.

Customer knowledge was also fragmented. Valuable insights lived in meeting notes, emails, individual conversations, and tribal knowledge, making it difficult for Product, Design, and Engineering to build on what had already been learned. The organization wasn't short on customer feedback—it lacked a repeatable way to capture, synthesize, and share it.

I also observed that Design was frequently engaged after priorities had already been established. This limited the team's ability to influence product strategy or help reduce uncertainty before development began. Instead of participating in problem definition, Design was often asked to refine predetermined solutions.

Perhaps the most important realization was that these weren't independent issues—they were symptoms of a broader organizational challenge. The company didn't need another research project or another design process. It needed a shared operating model that enabled Product, Design, and Engineering to learn together, make decisions together, and remain connected to the people they were building for.

That assessment became the foundation for everything that followed.

One of the first conclusions I reached was that process alone wouldn't change the organization. Before introducing new operating models, discovery practices, or tools, Frontline needed a shared vision of who we were building for and why the work mattered.

That vision took shape as Jayden's Compass — a fictional student used to connect Frontline's broad portfolio to a single human outcome, and the strategic framework built around his journey to show how signals, decisions, people, and services connected over time. It began with a simple idea: one name on a roster. Behind that name was an entire district ecosystem—teachers, administrators, specialists, operations, data, funding, staffing, interventions, and services—that Jayden's journey made visible.

The purpose wasn't to explain every product in detail. It was to give the organization a common narrative that cut across product lines, functions, and leadership teams—asking everyone to see the portfolio not as isolated applications or separate roadmaps, but as a connected system capable of helping a district recognize a student's needs, coordinate support, and act at the right time.

The framework demonstrated that no single product solved Jayden's problem. The value came from the connections:

• Data helped the district recognize the need.
• Educators and specialists coordinated the response.
• Planning and financial systems supported the investment.
• Human Capital systems helped bring in the right person.
• Special Programs supported service delivery and progress.
• Leadership gained visibility into outcomes instead of isolated activity.

This was the meaning of Better Together. Jayden's Compass also gave the organization a framework for evaluating future opportunities. Teams could ask:

• Where does information break down across this journey?
• Where are educators repeating work?
• Where should products share context?
• Where could AI identify risk, synthesize information, or reduce administrative effort?
• Where does a product decision strengthen the complete journey rather than only one application?

The final idea was simple: Jayden never saw the system, but the system saw him.

Jayden's Compass gave Frontline both a shared vision and a strategic model: proof that the portfolio's greatest value wouldn't come from any single product, but from how it worked together behind the scenes to help educators see students more clearly and act sooner.

With a shared vision beginning to take shape through Jayden's Compass, the next challenge was helping the organization rethink how product decisions were made. When I joined Frontline, discovery was largely reactive—customer conversations focused on requested features or immediate needs, with limited emphasis on the underlying workflows and motivations behind those requests. Research existed, but it wasn't yet a shared organizational capability.

A significant part of my role became socializing discovery across the organization—educating Product, Design, Engineering, and leadership on the value of ethnographic research, contextual inquiry, synthesis, and rapid user testing. Rather than asking customers what they wanted us to build, teams learned to observe work as it actually happened and identify the problems worth solving. I also challenged my own team to embrace emerging AI as a practical force multiplier, adopting structured Markdown documentation to capture research in a format that could be searched, reused, and expanded over time.

To validate whether we were focused on the right problems to solve.

To support this effort, I developed the Frontline Intelligence Engine (FIE)—an internal platform that centralized discovery findings and made customer insights visible across the organization. At a time when no shared discovery repository existed, FIE demonstrated how structured knowledge combined with AI could make research more accessible and actionable.

The shift showed up in how teams worked: instead of requesting another research presentation, Product Managers could ask directly, “What are the top problems to solve in Medicaid specific to Texas?”—discovery became organizational knowledge rather than something confined to individual projects. The technology would later evolve through commercial platforms like Dovetail, Figma, Lovable, and eventually MCP-enabled workflows, but the objective stayed the same: reduce the operational burden of managing customer knowledge so teams could spend more time understanding users and solving meaningful problems. By making discovery visible, repeatable, and accessible, the organization was ready to adopt a product operating model where Product, Design, and Engineering could truly share ownership of outcomes.

With a shared vision and strategic direction established through Jayden's Compass, the next challenge was organizational.

The question was no longer what we wanted to build. It was how we were going to build it.

As I evaluated how product teams operated, it became clear we needed a more collaborative model. Rather than inventing a new approach, I looked to the product operating principles championed by Marty Cagan and the Silicon Valley Product Group—at the center of that philosophy is the Three-Legged Stool, an operating model built on equal partnership between Product, Design, and Engineering. While the concept itself wasn't new, implementing it represented a significant cultural shift: historically, work moved sequentially between disciplines—Product defined requirements, Design created solutions, Engineering implemented them—and even with talented people doing good work, that process encouraged handoffs instead of shared ownership.

The Three-Legged Stool challenged that way of working. Instead of operating independently, Product, Design, and Engineering became equal partners responsible for understanding customer problems, exploring opportunities, evaluating trade-offs, and delivering outcomes together—each discipline bringing a unique perspective:

• Product provided business context, market understanding, and product strategy.
• Design brought customer empathy, research, systems thinking, and experience design.
• Engineering contributed technical expertise, architectural thinking, and implementation strategy.

The value wasn't simply having these disciplines represented—it was bringing them together early enough that each perspective could influence the problem before solutions were defined. That required more than reorganizing teams: it meant coaching leaders, redefining expectations, and helping teams understand what genuine partnership looked like. Product Managers were expected to engage in discovery alongside Design. Designers became strategic partners rather than downstream service providers. Engineers participated earlier in conversations, contributing technical insight before implementation rather than reacting to completed designs.

The result was a shift away from functional ownership toward shared accountability: success was no longer measured by how well one discipline completed its work before handing it to the next, but by how effectively Product, Design, and Engineering learned together, made decisions together, and delivered value together. Establishing the Three-Legged Stool created the organizational foundation for everything that followed.

With discovery becoming a shared capability and Product, Design, and Engineering aligned through a common operating model, the next step was accelerating how ideas moved from insight to validation.

To accomplish this, I introduced the Google Ventures Design Sprint methodology as a repeatable framework for solving complex product challenges—rather than spending months debating requirements or building features based on assumptions, cross-functional teams could move from problem definition to validated customer feedback in a matter of days. Each sprint brought together Product Managers, Designers, Engineers, researchers, subject matter experts, and customers around a clearly defined problem, emphasizing rapid learning over perfect execution so teams could quickly determine whether an idea addressed a meaningful need before significant engineering investment.

The five-day sprint structure provided a common rhythm for discovery:

• Understand the problem and align on goals.
• Review research and synthesize customer insights.
• Generate and evaluate solution concepts.
• Build a realistic prototype.
• Validate the concept through customer testing.

The value extended beyond the prototype itself—Design Sprints became a way to align stakeholders, reduce uncertainty, and create shared ownership across Product, Design, and Engineering, with decisions increasingly grounded in customer evidence rather than opinion. One example was an AI-first exploration of the IEP experience, where the team reimagined how AI could reduce administrative burden for diagnosticians while keeping educators firmly in control of critical decisions—rather than automating professional judgment, the concept focused on eliminating repetitive work so specialists could spend more time supporting students.

By institutionalizing Design Sprints, discovery became an operational practice rather than an occasional activity, enabling teams to learn faster, reduce delivery risk, and focus engineering effort on solutions that had already been validated with customers.

Transforming how teams worked also required modernizing the tools that supported them. When I joined Frontline, discovery artifacts, design files, customer feedback, and product decisions were often scattered across presentations, documents, spreadsheets, and individual team repositories—valuable customer knowledge was difficult to find, difficult to reuse, and rarely scaled beyond the team that created it.

As our discovery practice matured, I helped guide the evolution of the product ecosystem to better support a product-enabled organization. This included introducing and scaling tools that strengthened collaboration across Product, Design, and Engineering: we implemented Dovetail to centralize research and synthesis, expanded the organization's adoption of Figma as the primary collaboration platform for design and development, and introduced modern prototyping workflows that enabled teams to move from ideas to validated concepts more rapidly.

These tools were never the transformation itself—they existed to reinforce the operating model and discovery practices we had established, making customer research easier to share, design decisions more transparent, and collaboration increasingly asynchronous across distributed teams. Their evolution also reflected a broader industry shift: many of the concepts we had been exploring through the Frontline Intelligence Engine—structured knowledge, searchable discovery, and AI-assisted workflows—were becoming commercially available through modern product platforms. Rather than replacing our thinking, these tools accelerated it.

As AI capabilities continued to mature, workflows expanded beyond documentation and collaboration into intelligent synthesis, rapid prototyping, and assisted product development. Near the end of my time at Frontline, we began connecting Model Context Protocol (MCP) integrations to the Frontline Intelligence Engine prototype—early work pointing toward how AI could further reduce the operational overhead of discovery while increasing the speed at which teams could move from insight to validated solutions.

The objective remained consistent throughout the transformation: build an ecosystem that reduced administrative friction, increased organizational learning, and allowed Product, Design, and Engineering to spend more time solving customer problems rather than managing information.

As the organization matured in discovery and collaboration, we began asking a different question: what if we didn't simply add AI to existing products, but redesigned the experience around AI from the very beginning?

Rather than viewing artificial intelligence as another feature, we explored how it could fundamentally change the way educators worked. The goal was never to replace professional judgment—it was to reduce the repetitive, administrative work that prevented educators from focusing on students.

One of our most ambitious explorations centered on the Individualized Education Program (IEP) process. Through a five-day Design Sprint, our cross-functional team challenged long-standing assumptions about these complex workflows—research revealed that diagnosticians and educators spent significant time gathering information from multiple systems and performing repetitive administrative tasks before they could apply their expertise, time that could be better spent supporting students.

The concept we explored reimagined the workflow as an AI-assisted experience. Rather than asking users to manually assemble information from multiple sources, AI would surface relevant student data, identify patterns, prepare documentation, and guide users through the process while keeping educators in complete control of every critical decision.

The objective was not autonomous decision-making. It was intelligent assistance.

To validate the concept, our team developed a working interactive prototype that demonstrated the end-to-end experience. Rather than manually searching multiple systems, educators could see attendance and academic trends automatically surfaced, identify students requiring intervention, review supporting context, and initiate an AI-assisted workflow that guided the creation of an IEP while preserving human decision-making throughout the process.

Although the initiative was not ultimately shipped, the prototype demonstrated how an AI-first approach could fundamentally simplify one of education's most complex workflows. It also illustrated how agentic experiences could shift enterprise software away from navigating screens and forms toward completing meaningful work through intelligent assistance.

More importantly, the project reinforced a principle that has continued to shape my thinking:

AI creates the greatest value when it removes routine work so people can focus on the work only humans can do.

While many individual initiatives delivered measurable product improvements, the most significant outcome was the transformation of how the organization built products.

Over the course of this transformation:

These organizational capabilities created the foundation for more evidence-based product decisions, stronger cross-functional collaboration, and faster learning throughout the product development lifecycle.

The work also produced measurable improvements within individual products. Across initiatives, usability testing consistently demonstrated higher customer satisfaction, improved task completion, and stronger confidence in proposed solutions before development began.

Perhaps the most meaningful outcome, however, was cultural. Discovery became an expected part of product development rather than an optional activity—teams became more comfortable asking questions before proposing solutions, validating ideas before committing engineering resources, and solving customer problems together rather than optimizing for functional handoffs.

While not every initiative ultimately reached production, the capabilities established through this transformation continue to represent the achievement I am most proud of—not because they changed a single product, but because they changed how an organization learned, collaborated, and built products.

Looking back, the most important lesson wasn't tied to a single initiative. Discovery, UX Research, the Three-Legged Stool, Design Sprints, Figma, Dovetail, the Frontline Intelligence Engine, AI exploration, and Pendo each solved a different problem. Their real value wasn't in what they accomplished independently—it was in how they worked together to create a better product organization.

Together, they formed a continuous system for learning:

One of the most rewarding realizations came from what this system made possible. A UX organization of eight designers and one researcher supported more than 200 developers and over 30 products. That wasn't enough capacity to solve every problem, so success depended on building capabilities that scaled knowledge, improved decision-making, and helped teams focus on the problems that mattered most. The operating model ultimately became more valuable than additional headcount because it enabled the entire organization to make better decisions together.

That experience fundamentally changed how I think about product leadership. I no longer judge success by the quality of a framework, the sophistication of a technology, or the number of features delivered. I judge it by whether those investments create better outcomes for customers, for the business, and for the teams building the product.

Outcomes are everything. Everything else—people, processes, frameworks, tools, methodologies, and technology—is simply a means to achieve them.