I Thought We Were Just Implementing Asana.

A few months ago, our Creative Shared Services team made what felt like a straightforward technology decision.

Our Project Management Office had already adopted Asana, and since we'd outgrown Airtable, it made sense to evaluate whether we could leverage the company's investment rather than introduce another platform. It seemed like a practical decision with a predictable outcome: migrate our projects, configure some workflows and move on.

That's not what happened.

What started as a software implementation slowly turned into something much bigger. Somewhere between becoming Asana certified, joining the Asana Ambassador community and filling my whiteboard with workflow diagrams, I realized we weren't just choosing a new project management tool.

We were defining how marketing should work.

Software has a funny way of exposing everything you've never documented.

Every decision we made inside Asana forced us to answer a bigger question: How many different types of work do we actually do? When should a project require a creative brief? Who owns prioritization? How should requests move through the organization? Who approves what? How should we measure quality?

These weren't Asana questions.

They were organizational questions we'd simply never had to answer before because our existing processes had evolved organically over time. Some lived in documentation. Many lived in people's heads.

Every answer uncovered another unanswered question.

Then I hit a wall.

I led a successful implementation of Wrike at Visa. Naturally, I approached this project with a vision for how our new system should work. I knew what had worked before, and I assumed we'd build something similar.

Then I realized Asana wasn't Wrike. Not even close.

I distinctly remember taking my lunch break feeling frustrated enough to question whether we'd made the right decision. I had spent weeks trying to make Asana behave like the platform I already knew.

When I came back that afternoon, I realized the problem wasn't Asana. It was me.

I had been asking, "How do I recreate what I built before?" The better question was, "Why was Asana designed this way?"

That shift changed everything. Instead of fighting the platform, I started learning from it.

The implementation became a design exercise.

As our team learned more about Asana's capabilities through certification, an excellent Boost implementation with Asana's consulting team, and joining the Asana Ambassador community, our conversations shifted away from configuration and toward operating models.

One thing I appreciated about working with the Asana team was that they consistently encouraged us to think beyond the software. Rather than simply teaching us which buttons to click, they challenged us to define how we wanted work to flow, where decisions belonged and what success should look like. The platform was important, but the operating model came first.

Then our marketing organization went through a major reorganization.

Suddenly, this wasn't just a Creative Shared Services implementation anymore.

We were participating in a broader marketing transformation, and our little software project became an opportunity to rethink how work moved across the organization.

Every workshop generated new questions. Every decision uncovered another dependency. Every dependency deserved documentation.

Before long, we had created more than 35 documents covering everything from intake and project taxonomy to governance, reporting, creative briefs, quality measurement, AI, dashboards and workflow standards.

Looking back, I realized something important. We weren't documenting the current state.

We were designing the future state.

AI became part of the design team.

This is probably the part people expect to be about replacing work.

It wasn't.

I didn't ask AI to invent our operating model.

The expertise still came from years of experience implementing platforms, leading creative teams and projects and collaborating with my incredibly smart colleague, Erika.

What AI gave me was something different. It became a thinking partner.

I used ChatGPT to brainstorm frameworks, pressure-test ideas and explore different approaches. I leaned on Gemini when I needed help thinking through configuration options or solving specific implementation questions. Once our documentation reached critical mass, I turned to Claude to synthesize more than 35 documents into a comprehensive business requirements document that I now use as the blueprint for implementation, testing and future enhancements.

At the same time, I regularly leaned on the Asana Ambassador community to validate ideas with practitioners who had already solved many of the challenges we were encountering.

Each brought something different to the table.

None replaced expertise.

Together, they accelerated learning.

We're intentionally launching Version 1.

One of the biggest lessons from this project is that the goal isn't to build the perfect operating system before anyone uses it.

It's to build a thoughtful, flexible framework that gives people a better way to work while creating the feedback loops needed to keep improving.

We'll launch our first version.

We'll listen.

We'll study adoption.

We'll measure what works and what doesn't.

We'll refine the experience based on user feedback and the data the platform captures.

In other words, we'll treat our operating model the same way great product teams treat their products: as something that continuously evolves.

Five lessons I'll carry into every future implementation

After months of learning, documenting and redesigning, here are the lessons that stand out.

1. Software doesn't solve operational problems. It exposes them.

If your workflows, governance and decision-making aren't well defined, a new platform won't magically fix them. It will simply make the gaps impossible to ignore.

2. Don't force a new tool to behave like the old one.

Every platform has a philosophy. The breakthrough came when I stopped trying to recreate Wrike and started understanding why Asana worked differently.

3. Design the operating model before you configure the software.

The best workflows aren't built inside the platform. They're built through conversations about how your organization wants to work.

4. AI works best as a collaborator, not a replacement.

The value wasn't asking AI for answers. It was using AI to challenge assumptions, organize complexity, synthesize documentation and accelerate learning while keeping experienced humans firmly in the loop. It was actually ChatGPT who "sat me down" and said that I was fighting the spirit of Asana and I needed to change, not the tool.

5. Launch is the beginning, not the finish line.

A great operating model isn't something you perfect in a conference room. It's something you build, test, measure and continuously improve alongside the people who use it every day.

As I look back, it's funny to think that we started by trying to replace a project management tool.

Months later, we have something much more valuable: A shared vision for how marketing can work.

The software matters. AI matters. Great implementation partners and communities matter.

But none of those were the real transformation.

The real transformation happened when we stopped asking, "How do we configure Asana?" and started asking, "How do we want marketing to work?"

That's a question worth spending months answering.