Reliability Protocol (Asana implementation framework) Stage #1: Discovering problems worth solving

Part 1 of the Reliability Protocol series. All 15 stages: series index.

The Asana implementations that still hold a year later, where teams still work by the rules they designed, all started the same way.

Not with a demo. With a written answer to one question: what’s actually broken?

That answer decides the rest. Which processes are worth moving into Asana. Which ones need fixing first, because a broken process moved into a new tool is still broken, just better organised. And now a third question: in each process, which steps stay with a person, and which can an AI Teammate run?

In consulting, this conversation usually hides inside the sales process as the “free discovery call”.

The usual path, and ours

Most rollouts take the shallow path. It’s how buying software usually works, so nobody picks it on purpose. We take the deep one. Both start the same way: someone in leadership feels the chaos, projects slip, and the weekly status meeting eats an hour.

On the shallow path, the problem gets named as a vague tool gap: “we need a platform for this”. Demos, a contract, and the team is told to use it. Six months later half the team works in Asana and the other half is back on email and spreadsheets. The chaos just moved.

On the deep path, it gets named as a specific collaboration gap, with a cost on it: “launch handoffs between marketing and product lose a day every cycle, and nobody owns the gap”. Leadership looks at how work actually moves before anyone books a demo. The tool gets picked last. In our experience it’s the only path where adoption holds past month 12.

The shallow path has a new version now: “we need an AI Teammate for this”. Same mistake, bigger bill. Teammates run on AI requests from a pool your whole org shares, so a teammate pointed at a problem nobody named gives you the same chaos, faster, and spends the pool doing it. AI Teammates are worth buying. Just not before you can say what they’re for.

How to run it: three goals

  1. Name the problem. “We need better organisation” isn’t a problem statement. Keep asking “and what does that cost us?” until you can write something like: our launch handoffs lose 18 hours per cycle, and we run 12 cycles a year. That’s 216 hours a year we pay for and lose. That’s a problem someone can own.
  2. Get agreement with your Sponsor. Your Sponsor is whoever holds the budget, usually the CEO or COO. By the end you should both describe the problem in the same words. If you can’t, you don’t have a project yet. You have a future argument.
  3. Test the Sponsor’s commitment. “I’ll fund this” and “I’ll show up at the kick-off and back it in front of the team” are different promises. Watch what your Sponsor does, not what they say.

The questions

We run discovery in five layers. Each one gets closer to the real problem.

Who needs to be in the room

The Sponsor brings authority and cover. The Operator is the manager who feels the pain every day and usually started the search. The third seat is an outside thinking partner, someone who can ask the questions you can’t ask your own boss. It doesn’t have to be a consultant: a business coach, an experienced peer or a board advisor all work.

If two of the three aren’t there, discovery is incomplete.

Four things to have ready

Before the session, write down:

  • one paragraph on the broken process: the work that breaks, not the software you’re missing
  • a rough cost: hours lost or deals slipped per quarter. Imperfect numbers beat no numbers.
  • who your Sponsor is, and whether they’ll back this in public or only fund it
  • a guess at the collaboration gap: where handoffs, habits or escalations break between teams

If three of the four are blank, you don’t need a transformation conversation yet. You need a working session to fill them in.

If you already have AI Teammates or Claude

Give one the homework. An AI Teammate, or Claude, can run discovery with our framework and the questions we prepared for this stage. They’re in the Stage 1 toolkit, linked from the stage page below. Ask it to interview you until you have a problem statement, then take that statement into the Sponsor conversation.

The full Stage 1

A forum thread can’t hold everything, so the full Stage 1 lives on our site: the toolkit with our full question bank, a script for opening the conversation with your CEO or CFO, the mistakes that stall an implementation in week one, and red flags when picking a partner (us included). Keeping it in one place also means our public framework is always up to date. Read it here: Discovering problems worth solving

Next week

Stage 2, Preparation. It gets its own topic and a reply in the series index, so watch that topic to follow along.

Shallow or deep: which path did your last rollout take?

7 Likes

Oskar, this is incredibly helpful and affirming. So often teams jump to the solution (read: new tool, new software, new workflow, new meeting) instead of taking time to truly define the problem. By skipping the deep naming phase, we run the very high risk of creating MORE problems and increasing cost and loss. I particularly appreciation your question “what does that cost us” to help guide teams through defining the problem.

1 Like

Thanks Brittany. If I could keep only one question from Stage 1, it would be that one. Have you had a chance to ask it in one of your own projects?

I haven’t yet. Among my go to questions are “what’s the current state” and “what is our ideal state”. I think the question what’s the cost fits in nicely as a follow up to those. That way the team is already thinking about their pain points, where they have a solid foundation to build from, what they are working towards, and why.

Ah yes - those 2 allow for “meeting them where they are” and then building mental bridge to the yet unknown future for them