Multi-product GTM breaks when you standardize the motion instead of the diagnostic behind it. I learned that running three go-to-market motions at once at Asana.
My scope nearly tripled the day I moved from Kustomer to Asana. At Kustomer I owned one product with a handful of add-ons. At Asana I owned three brand new products going to market at once, each with its own GM, its own buyer, and its own pricing model. That meant building three different theories of how software gets bought, all under one PMM function at the same time.
Here's what I was bringing to market:
- Asana Service Management, sold to heads of IT, running a sales-led motion, priced as an add-on
- Asana Client Management, sold to agency leaders, running a hybrid of sales-led and product-led, positioned as a replacement for how they were already using Asana
- Command by Asana, sold to engineering managers, starting sales-led with a deliberate plan to transition to product-led, priced as an add-on
Three personas. Three pricing models. Three points on the sales-led to product-led spectrum. This is where a portfolio has to develop its own operating model, because none of the individual product playbooks were built to run in parallel.
The default mistake: standardizing for consistency
When you're bringing multiple new products to market at once, the first instinct is to find the common playbook. Pick one motion, one pricing philosophy, one launch cadence, and apply it everywhere. Consistency is easier to manage and easier to explain upward.
It's also the wrong call. A GTM motion is a bet on how a specific buyer already evaluates and purchases software. Standardizing the motion across three different buyers means winning that bet for one of them and losing it for the other two.
The job is diagnosing what I'd call motion-market fit for each buyer, then building an operating model that can run three different fits at once without three different PMM functions.
Three products, three buyer realities
The procurement buyer: Asana Service Management
Heads of IT evaluate software through procurement processes, security review, and budget cycles tied to broader IT transformation goals. They're not going to self-serve their way into an enterprise service management tool. That buyer needs a sales-led motion because that's how they buy everything else in their stack. They're also actively looking to consolidate: legacy ITSM tools get stretched to cover departments they were never built for, and that stretch is what kills adoption. The pitch centered on stopping the tax they were already paying for a tool failing outside its lane.
The buyer already in the room: Asana Client Management
Agency leaders are a different animal. They were already inside Asana running client work, duplicating projects to build customer-facing versions with the sensitive fields stripped out. The buying decision was whether to stop the manual workaround they'd already built for themselves, a lower-friction call than adopting a new vendor. That's why Client Management could run sales-led and product-led at the same time. A dedicated portal with AI teammates and client health dashboards gave some agencies a conversation worth having with sales. Others just needed to discover the feature and turn it on.
The buyer who doesn't trust you yet: Command by Asana
Engineering managers were the hardest case, and the most interesting one to build a motion for. Developer tools win through hands-on evaluation, and Asana had zero brand equity with this audience. Command started sales-led out of necessity, since the product needed direct GM and account relationships to get initial traction. The plan from the start was a transition: get developers using it alongside tools like Cursor and Copilot, let them pull it in themselves, and let product-led growth take over once trust existed to make that possible.
Pricing follows the buyer's budget logic
Service Management and Command were both add-ons, but for different reasons. Service Management sat on top of an existing IT budget line, so add-on pricing matched how procurement already thought about the spend. Command was priced as an add-on because it needed to ride on Asana's existing enterprise relationships to get in the door at all, even though the long-term bet was that individual developers would be the ones pulling it into their workflow.
Client Management priced separately from the add-on model because it replaced a workaround agencies had already built for themselves, a distinct problem that called for its own price rather than a line item on an existing purchase.
Every pricing decision started with who controls the budget, what they're used to paying for, and what problem they think they're solving.
One install base, three different plays
With 200,000 existing customers, all three products started from the same premise: go after the install base before chasing new logos. Past that starting point, the marketing plans had almost nothing in common.
Service Management ran full sales-led infrastructure: a 101 training deck, an FCD, a product datasheet, an internal FAQ, a demo script. A website update built around a "contact sales" CTA, with value props, a sizzle video, and use cases broken out by persona. Amplification through a customer story with an IT leader, an internal dogfooding story showing our own ROI, and an analyst quote. Then list marketing layered on top: the high-propensity list going to sales for outbounding, the waitlist going to BDRs, the top 1,000 accounts getting lifecycle emails for launch and admin onboarding, with ABM added for key accounts three months in.
Client Management ran that same SLG infrastructure on the sales-led side, but the PLG side needed something different. Since agencies were already inside the product, the plan leaned hard into trial and onboarding lifecycle emails, getting them invested in the portal, the AI teammates, and the dashboards before a rep ever entered the picture.
The real Command problem: earning the right to be heard
Command's marketing plan barely resembled either one. The motion was sales-led, but the actual job was awareness. If nothing on your website speaks to engineering buyers, they have no reason to trust you, and no sales conversation fixes that on its own.
So most of the plan was about earning the right to be in the room. Distinct branding, separate from Asana's. A dedicated /command sub-folder rather than a standalone domain, chosen to protect SEO, with its own homepage, docs, pricing, blog, and customer pages. Thirty-plus thought leadership articles written specifically for engineering audiences. An intro video modeled on "hello world." Sales enablement material paired with content built to introduce our engineering leader alongside the product. A speaking slot at AWS re:Invent. A dev evangelist hired specifically to carry this forward. Partner marketing investment with coding agent companies and major LLM labs, plus hackathons and event presence, all aimed at getting Command into conversations Asana had never been part of.
The category announcement staked out agentic orchestration as a layer software development needed. The "infinite flexibility" message ran alongside it to protect the thing developers actually cared about: that Command worked with Cursor and Copilot instead of trying to replace them. Asana had been showing up in Jira-versus-Linear conversations as the unplanned third option for years. Command by Asana was the decision to build the product that third-option conversation had already been asking for, and to market it like a new entrant with something to prove.
The framework: motion-market fit over motion consistency
Every product had its own motion, its own persona, its own pricing model, its own marketing plan. What carried across all three was a single diagnostic: how does this buyer already evaluate and purchase software, what do they already trust us to be good at, and what does our motion and marketing need to look like to meet them where that trust currently sits.
Running three go-to-market motions under one roof means running that diagnostic separately for each buyer before committing to a plan, then building an operating model flexible enough to hold three different answers without asking any of the three to compromise.