Most companies skip message testing. It looks like an extra step, and most small companies don't have the resourcing for it. I got to see how much it matters while building go-to-market for Command by Asana, an agentic software development lifecycle tool that helps do release planning and development in one interface.
Where We Started
We started with two exercises to shape the initial messaging. Messaging V0 mapped state of the world, pain point, and value prop by persona. Messaging V1 sharpened that into a why change, why now, why Asana framework. Condensed versions of both:
Messaging V0
| Senior / Staff Engineer | Engineering Manager / Tech Lead | VP of Engineering / Head of Engineering | |
|---|---|---|---|
| State of the World | Developers love flow, hate context switching | EMs code themselves while managing both engineers and agents | Orgs spending on AI code gen with no visibility into whether they're shipping a better product, faster |
| Pain Point | Ticket creation runs a half day to a full day per initiative | Capacity planning still done in spreadsheets, about an hour per project per week | Cross-team visibility is critical, but discovery only happens at 6-month offsites |
| How Command Solves It | Tickets and specs write themselves from existing context | Sprint plans built from actual capacity, kept current as scope shifts | Initiative tracker answers plain-language questions about what's on track and what's burning tokens |
| Differentiator | Linear has no cross-tool context graph or capacity-aware planning | Command replaces the swivel-chair between GitHub and spreadsheets | No other tool lets leaders query and understand what's happening across the org |
Top 3 Value Props
Introducing Command by Asana: the context-architecture for agent-orchestrated software development.
- Automate spec and ticket drafting grounded in complete context. Every ticket pulls from your codebase, specs, meetings, and notes, organized in a structured work graph, so higher quality, complete tickets are generated that your humans and agents can act on.
- Predict release dates based on development velocity and scope shifts. Auto-plan sprints from actual capacity and velocity data, model configurations before committing, and keep release dates current as scope shifts and forecasts recalculate automatically.
- Return engineering time to high leverage work. With ticket drafting, sprint planning, and scope tracking handled automatically, engineers redirect their cycles to product experience, architecture debates, and stress-testing assumptions before they reach the sprint.
Messaging V1
| Persona | Why Change | Why Now | Why Asana |
|---|---|---|---|
| Senior / Staff Engineer | Engineers lose time decoding underspecified work | Scope drift scales with agent speed | Stop scope drift with ambient specs |
| Engineering Manager / Tech Lead | Managers lose hours reconciling capacity, velocity, and sequencing | AI speeds up individuals, not organizations | Stop firefighting slipping dates with agent-led remediation |
| VP Engineering / Head of Engineering | Leaders can't answer where work stands or show AI's impact | The gap between AI usage and delivery outcomes is widening | Replace status decks and spreadsheets with live delivery answers |
Value Props by Persona
- Senior / Staff Engineer — Stop scope drift with ambient specs. Specs write themselves from ambient work signals, capturing intent, decisions, acceptance criteria, and edge cases by default. Agents pick up cleaner, better-scoped tickets, and context compounds in the Work Graph so future tickets inherit the same guardrails.
- Engineering Manager / Tech Lead — Stop firefighting slipping dates with agent-led remediation. Plans stay live against real velocity and capacity, so teams see slippage as it forms instead of at standup. Command runs the what-if analysis and proposes full change sets that managers approve, staying focused on the calls only they can make.
- VP of Engineering / Head of Engineering — Replace status decks and spreadsheets with live delivery answers. Command keeps agentic work anchored to product intent, surfaces cross-team dependencies without the offsite, and turns natural language questions into live delivery insights instead of dashboards to configure.
Between the two, we landed on a set of taglines and value props to test.
Taglines:
- From spec to shipped with humans and agents in sync
- The planning and product development system for builders
Value props:
- Cleaner tickets, higher quality output on repeat
- Hit release dates every time with agentic support
- Always on visibility into risk, drift and dependencies
From there, three groups tested what we'd written, and each one changed something.
What Quantifiable Market Research Told Us
We have a team inside product marketing built specifically to test messaging with our ICP. They took our value props and pulled value props from two competitor websites, then had our ICP stack rank all of them. Our ICP ranked Linear's value props the lowest and Jira's higher. Leadership had pointed us toward Linear as the comparison to beat, since they're the popular name in the space. The research told a different story: people love Linear for its functionality and UI, but its marketing doesn't land with our ICP. That was the signal to stop treating Linear as the standard. The highest-ranked value prop in the whole test was one we wrote ourselves: "always on visibility into risk, drift and dependencies." That one stayed.
QMR also taught me how much a single word changes how a value prop reads. We moved from V1 to V2 based on what this research surfaced, and the edits are smaller than you'd expect. Every one of them mattered.
| V1 Value Props | V2 Value Props | |
|---|---|---|
| Tagline | The planning and product development system for builders | The planning and product development system for agent + human teams |
| Faster vs. High quality | Cleaner tickets, faster agent output, on repeat | Cleaner tickets, higher quality output, on repeat |
| Support vs. Oversight | Hit release dates with agentic oversight. | Hit release dates every time with agentic support. |
| Specificity | Engineers get back to building. | Engineers get back to building and spend less time in meetings and standups. |
"Faster" became "higher quality." "Oversight" became "support," with "agents" named as the subject doing the catching instead of staying implied. "Engineers get back to building" got a second half naming exactly what they get back from. None of these read as a rewrite. Each one is a word doing more work than the word it replaced.
What an Outside Analyst Caught That We Missed
Our headline and one of our value props leaned hard on writing a spec first and generating tickets from it. Our analyst at RedMonk, a developer-focused research firm, flagged something we hadn't considered: developers today often start with a prototype instead of a spec, especially with AI coding tools available, and "spec" is a loaded word inside developer communities caught up in the spec-first versus prototype-first debate. Many teams have tried going spec-first and failed. Leading with that word risked turning off the audience we were trying to reach, and risked making Command look like another vibe coding tool.
His strategic framing reset how we thought about the category. AI-assisted software development is a team sport, not a solo act, and the real bar isn't AI code that gets written, it's AI code that actually makes it to production. That's speed paired with governance, not speed alone. He also pushed us toward a different angle: hitting release dates as a team sport, not an individual speed boost. Other tools make individual developers faster. Command makes the team faster, which matters most when AI adoption varies across the team.
Key Takeaways
His summary came down to four takeaways: bring in the team collaboration angle over individual code output, sell speed with governance rather than speed on its own, position hitting release dates ahead of predicting them, and keep the word "spec" out of the headline. That conversation moved our headline from "From spec to shipped with humans and agents in sync" to "The planning and product development system for builders." It also added two new value props to the set:
- Return engineering time to high leverage work. With ticket drafting, sprint planning, and scope tracking handled automatically, engineers get back to building and spend less time in meetings and standups.
- Go from individual velocity to org-wide output. Connect code generation to the planning, review, coordination, and sign-offs that ship production-ready software.
What Design Partners Told Us That No Internal Exercise Could
This was the most important input of the three. Our customers named specific problems they wanted Command to solve. They wanted to quantify and flag risk without standups or extra meetings. They didn't want a new tool bolted onto their workflow; they wanted Command to fit into what they already used. Their leaders wanted a direct view into releases without asking for one.
- Automatic: Compress cycle time. Generate docs automatically from past tickets, PRs, meetings, and notes so engineers spend less time wrangling context and more time shipping.
- Proactive: Always-on risk detection. Catch resourcing, pacing, and sequencing problems before they derail a release, and let agents fix them automatically so your team stays on track without a standup.
- Effortless: Stay in flow. Propagate requirement changes automatically across reassignments, timelines, and acceptance criteria without any context switching.
Three Tests, Three Different Problems Caught
Three different tests surfaced three different problems with messaging that looked finished before we tested it. QMR told us which value props actually resonated and which assumption about the competitive set was wrong. Analyst relations told us a word we'd built a headline around was quietly working against us. Design partners gave us language grounded in what customers were actually trying to solve, which none of our internal exercises had produced on their own.
These were the final value props after the full exercise:
- Stay in flow. Command automatically catalogs the decisions, context, and next steps agents need to stay efficient and keep moving. Engineers spend less time unblocking agents and more time on what's next.
- Releases de-risk themselves. Command monitors scope, dependencies, pacing, and risks in real time, surfacing blockers and adjusting plans before they cascade into delays.
- Always know the status, no meetings required. Command gives leaders a custom, queryable view of the strategic work that's important to them, so they know what is truly at risk and why without waiting for a status update.
Writing good messaging is a starting point. Testing it against real audiences is what tells you whether it's actually good.