Wildland Firefighting

Developing an autonomous response system for wildland firefighting

The Challenge

The company behind a successful open-source AI and machine-learning orchestration tool was expanding into the enterprise market, building a commercial platform based on the open-source technology, with added infrastructure, support, security, governance, and scalability for organizations running production AI systems.

The open-source product had established technical credibility and an active developer community, but launching an enterprise offering introduced a different set of questions. The company needed to determine which organizations represented the strongest opportunity, how the needs of individual developers differed from those of enterprise buyers, and what would motivate teams to move from open-source adoption to a paid platform.

Internal teams were not yet aligned on the ideal customer profile, the distinction between users and buyers, the problems the enterprise product should prioritize, or how the open-source, self-serve, and enterprise offerings should relate to one another. These uncertainties affected the product roadmap, packaging, positioning, website strategy, and sales process. The company needed an ongoing source of customer evidence to help turn a successful developer tool into a credible enterprise product and business.

My Role

Research program leadership · Technical B2B research · GTM strategy

I joined the GTM team to build the research capability supporting the company’s expansion into the enterprise market. In September 2024, I established the UX GTM Research workstream and led it through August 2026. I owned the research process end to end, from identifying high-risk questions and setting the research agenda to recruiting participants, conducting studies, synthesizing evidence, and translating findings into product and go-to-market recommendations for the business and leadership.

The Approach

Rather than treating each request as an isolated study, I built a connected research program in which each round addressed a new layer of uncertainty and built upon the evidence that came before it.

1. Establishing a shared understanding of the market

I began with foundational discovery across ML engineers and ML leaders. The research tested internal assumptions about their workflows, purchasing behavior, and greatest obstacles to building and operating production AI systems. The initial study included technical practitioners and leaders across companies of different sizes and industries. It identified recurring problems around compute costs, manual processes, fragmented tooling, infrastructure limitations, deployment, and debugging.

The findings also challenged several internal assumptions that had received less support from customers, which helped the company distinguish persistent customer problems from individual feature requests and emerging ideas. A key organizational insight was that the person using or advocating for a technical product was not always the person purchasing it. Engineers evaluated whether a tool worked within their environment and delivered desired results, while leaders considered cost, security, organizational risk, and time to market. This distinction became foundational to the research that followed.

2. Testing the platform direction

The next phase examined desirability around a unified platform or preferred specialized point solutions. Participants responded positively to reducing fragmentation, but they were skeptical of products claiming to solve every part of the ML lifecycle. They wanted technical depth in core capabilities, compatibility with their existing infrastructure, and the flexibility to adopt a platform incrementally without becoming locked into a single vendor.

This reframed the opportunity. A unified platform could be compelling, but only if it integrated with existing systems, demonstrated clear technical value, and allowed teams to begin without committing to a disruptive migration.

The research also clarified the different expectations of startups and enterprises. Smaller teams prioritized speed, ease of adoption, and affordability. Larger organizations required stronger evidence around security, compliance, scalability, and operational risk.

3. Translating evidence into an adoption strategy

As the product direction became clearer, I expanded the research into positioning, value propositions, product packaging, website information architecture, and conversion.

I tested how technical practitioners and leaders responded to different messages, product claims, CTAs, and click-paths through the website. I combined open-ended interviews with structured scoring, comparative rankings, pain-frequency counts, and preference measures to understand both participants’ reasoning and the strength of recurring patterns.

The research showed that technical buyers were fatigued by broad AI claims and wanted concrete proof of how a product worked. Engineers preferred to evaluate the platform independently before talking with sales or recommending it within their organization. Leadership audiences responded more strongly to cost visibility, business value, and evidence that the platform could reduce risk. These findings led to two distinct adoption paths: an independent product experience for technical evaluators and more targeted materials for leaders and budget holders.

The Impact

The research workstream gave the company an ongoing, evidence-based understanding of its users, buyers, and market. It helped move internal conversations away from disconnected assumptions and toward a more consistent view of who the platform served and what those customers needed.

The research contributed to:

• Reprioritizing the product roadmap around validated customer problems

• Making cost visibility a prominent feature in website and go-to-market materials

• Developing distinct messaging and materials for technical implementers and leadership buyers

• Introducing a free sandbox where engineers could evaluate the platform independently before making a larger commitment

• Clarifying the roles of open-source, self-serve, and enterprise adoption paths

• Redesigning the company website, including its information architecture, value propositions, content hierarchy, CTAs, and click paths

• Creating stronger internal alignment around the ideal customer profile and the differences between users, advocates, buyers, and enterprise gatekeepers

Following the website redesign, the marketing team reported increased CTA engagement and more booked meetings. The product roadmap was restructured and reprioritized to focus on the highest priority customer and business needs.

Beyond the individual decisions it influenced, the work established research as an ongoing strategic function within the company. Leadership and cross-functional teams gained a repeatable way to identify uncertain assumptions, hear directly from the market, and use customer evidence to guide product and growth decisions.

The Takeaway

This work reinforced that go-to-market research should not begin after a product strategy has already been decided. In a complex and rapidly changing market, questions about the product, customer, buyer, message, and adoption experience are deeply connected. By treating GTM research as a continuous program rather than a sequence of isolated studies, I was able to help the company build a shared understanding of its market, revisit assumptions as the technology evolved, and make decisions with greater clarity and confidence.