Discovering problems worth solving 🔬
What to ask before fixing the wrong thing.
Most platform rollouts fail before they're even bought. They get sold and signed off before anyone in the room has named what's actually broken — and by the time the team logs in for the first time, the gap between what's broken and what the tool does is too wide for the rollout to close on its own.
In this document
How companies decide on a transformation
How to bring this conversation internally
Questions that surface what's actually broken
What to prepare before this stage
Avoid this if you don't want your transformation to fail or delay
Red flags when picking a partner — including us
What you get with the full protocol
1️⃣ How companies decide on a digital transformation or platform/app implementation
Both paths start the same way: someone in leadership names a pain point.
The difference between them isn't whether a problem gets named — it's how deeply.
🔴 The shallow path.
The problem gets named as a tool gap: "we don't have a platform for this process." The conversation moves quickly to vendor demos, ROI spreadsheets, and a procurement cycle. The platform gets bought, the existing process gets transferred onto it, and the team is told to use it.
Six months later, half the team uses the platform, the other half is back on email and spreadsheets, and nobody can fully explain what went wrong. In our experience, this is how most rollouts stall — not because the platform was wrong, but because the problem statement underneath was too thin to drive change.
🟢 The deep path.
The problem gets named as a collaboration gap: "the way our teams hand work to each other, escalate decisions, and signal completion has drifted — and the platform we have today doesn't carry that work cleanly." The conversation slows down. Leadership audits how work actually moves between teams, where ownership blurs, what habits managers and individual contributors fall back on under pressure.
Only then does platform selection happen — at which point it's a tool choice, not a strategy decision. Implementation isn't transferring the existing process onto software; it's changing how the team and its leadership collaborate, with the platform as the new shared surface. In our experience, this is the only path where adoption sticks past month 12 — because what's been changed is how the team works together, not just where they work.
2️⃣ How to run discovery yourself
You probably think of discovery as a free call consultancies offer to sell their services. It's part of sales — but its actual job is something else entirely: properly understanding the situation so a plan can be formulated. This chapter shows you how to run discovery for yourself, without anyone's help. It's a working session with three goals:
Goal 1 — Surface the actual problem. Don't accept "we need better organisation" as a problem statement — it isn't one. Push the conversation until you can write the problem like this: "our launch handoffs lose 18 hours per cycle, and we run 12 cycles a year — that's 216 hours of capacity we're paying for and losing every year." Specific, costed, ownable. The translation work — from vague pain to numbered cost — is the discovery. Ask "and what does that cost us?" until you hit a number. Then ask "and what would it look like if that number went away?" until you hit a behaviour change.
Goal 2 — Reach conceptual agreement. You and your Sponsor should be able to articulate the same problem in the same words by the end of the session. If you can't, you don't have an engagement yet — you have a future argument. Don't move to platform selection until this lands; the conversation only gets harder once a tool is on the table.
Goal 3 — Confirm your Sponsor commits, not just signs. Your Sponsor is your CEO, COO, or whoever holds the budget for this — the person who has to defend the change publicly when it gets uncomfortable. There's a real difference between "I'll fund this" and "I'll show up to the kickoff and put my weight behind it." Without the second, transformation stalls at the first organisational obstacle. The 19-out-of-20 long-term retention number we measure across 200+ organisations rests entirely on this commitment being real, not delegated.
3️⃣ How to bring this conversation internally
You are the initiator. The conceptual-agreement work doesn't happen because someone schedules it — it happens because you walk into a 60-minute session prepared, and refuse to leave without a written problem statement. Whether you bring this to your CEO, your CFO, or your ops director, the path is the same: lead with the cost of the breakage, not the name of the tool.
Open the conversation with a script like this:
Before we approve a platform decision, I want us to agree on what we're trying to fix. Not "we need Asana" — but "we lose roughly 30% of project capacity to broken handoffs, and that's the cost we're solving for." I'd like a 60-minute working session to write that down.
This lands you in a totally different category in your C-level's eyes. It signals you understand the company-level metrics that matter — not just team productivity. Bringing this to your CFO? Lead with cost and the timeline question: "we're losing X capacity per quarter; if we don't fix it by Q3, it limits the next round of growth." That's the language that gets calendar time.
The hardest part of internal selling isn't getting budget approval — it's getting conceptual agreement with your Sponsor before either of you commits. If your CEO and your COO can't articulate the broken process the same way, you don't have an engagement. You have a future argument.
This is also where pushing the tool too early backfires. ❗ The moment you say "we need Asana", you've replaced a problem statement with a procurement request — and procurement requests get pattern-matched to budget cycles, not strategic decisions. Stay on the disease until everyone in the room agrees on the diagnosis. Then the cure is a conversation, not a fight.
4️⃣ Questions that surface what's actually broken
Discovery questions break into five categories. Each one is designed to disqualify shallow problem statements ("we need better organisation") and surface the operational reality underneath.
Two example questions per category — the full bank lives in the toolkit.
01 Problems & pain points
- What's the main problem you're trying to solve today?
- What's keeping your team from hitting deadlines — what specifically breaks down?
02 Current workflow
- How does work get delegated today — top-down, or pulled from a queue?
- What tools are you hoping a new platform will replace, and what will it work alongside?
03 Expected results
- Imagine the new system is working at full potential — what specifically changes? Which metrics move?
- Where do you want to be in six months that you can't reach today?
04 ROI & investment
- How do you decide whether an investment like this is worth it?
- If you don't fix this, how long can you stay with things as they are?
05 Intangible impact
- What's the cost of not fixing this on team morale, retention, or your own headspace?
- How would your week look different if you no longer had to chase status?
5️⃣ Roles you'll need in the room
- The Sponsor — your CEO, COO, or whoever holds the budget for this. Has to show up to the kickoff and visibly back the change publicly, not just sign the contract.
- The Operator (you) — the manager who feels the pain daily. Often the one who started the search; usually the one running the discovery internally.
- You'll be formally appointed Guardian at the Kick-off 🏈 stage — usually the same person, but not always. The Guardian needs sufficient authority and time to resolve conflicts blocking change.
- An external thinking partner — someone outside the politics of your org who can ask the questions you can't actually ask your own boss. The reason matters: the Operator is too close to the situation to challenge their own Sponsor's framing without sounding like they're complaining. A neutral third party (a coach, a peer Operator, or — yes — us) carries questions you can't.
6️⃣ What to prepare before this stage
Before you walk into a discovery session — yours or ours — have these four things ready:
- A one-paragraph description of the broken process — not the missing tool. Name the work that breaks, not the software you don't have.
- A rough cost estimate — hours wasted, deals lost, deadlines missed, capacity bled per quarter. Imperfect numbers beat zero numbers.
- A clear sense of who your Sponsor is — and whether they're publicly bought in, not just willing to fund. (Public backing ≠ signed contract.)
- A working hypothesis on the collaboration gap — where do habits, handoffs, or escalations break down between teams? Even a guess focuses the discovery.
If three of those four are blank, you don't yet need a transformation conversation — you need a working session to fill them in first.
7️⃣ Avoid this if you don't want your transformation to fail or delay
‼️ Don't jump to the tool. If you walk into your Sponsor's office convinced you need Asana and ask them to approve a contract, the conversation stalls — because you haven't yet had the conceptual-agreement conversation, and the questions you'd need to answer expose that gap. Have the internal conversation first. Don't soften the questions; sequence them right.
‼️ Don't mistake enthusiasm for commitment. A Sponsor who's excited at the discovery session but unwilling to attend the kickoff isn't committed — they're delegated. Transformation under that condition rarely survives the first organisational obstacle. We've seen it dozens of times: enthusiasm at month 0, polite distance at month 3. Take into account: what your Sponsor will visibly do, not what they say.
‼️ Don't sanitise the problem. "We just need better organisation" is not a problem statement — it's a request for permission. Translate it. Push until you have something like: "we lose 18 hours a week to handoff confusion in the launch process, and it's costing us two weeks per quarter in delivery." That's a problem someone can decide on.
8️⃣ Red flags when picking a partner — including us
You'll talk to consultants. Most fall into two camps: methodology people (Agile, Scrum) who teach theory, and software trainers who set up tools. Neither solves the actual problem — which is that people, processes, and platform have drifted apart, and adding software without realigning the other two makes the drift worse.
The red flag is anyone who pitches you tooling on the first call. A real partner — us, or anyone else worth your time — spends the first hour understanding the problem. If a discovery session ends with a quote and no written problem statement, you've just been sold to. Walk away.
📖 The engagements we've seen succeed across 200+ organisations all started the same way: a written, shared problem statement before any tool was named. The ones that didn't always had to rebuild that agreement mid-project — and pay for it twice.
✅ What you get with the full protocol
The full Reliability Protocol is delivered as one weekly action by email. You don't read 15 stages in one sitting — you receive one stage at a time, with one implementable artifact, and one clear next step you (or your Guardian, once appointed) can act on that week. The elements you get for this stage:
- The Discovery Question Bank — the full 50+ question library, organised by sales stage, buyer persona, and depth of pain.
- The pre-discovery readiness checklist — covering the broken-process description, cost estimate, prior-platform history, Sponsor commitment, and timeline pressure.
- The Sponsor commitment script — the conversation pattern from chapter 4, with two variations for different Sponsor profiles (the cautious CFO, the impatient CEO).
- The conceptual-agreement template — a one-pager you and your Sponsor sign off on at the end of discovery, so the engagement starts on shared ground.
💬 Take this with you, and you can run discovery yourself. Hit a wall on any of the four artifacts and want a partner — book your Reliability Diagnostic below.
When to bring in a partner
The package above covers the framework. Most managers run it themselves. Bring in a partner when:
- The Sponsor conversation is stuck. You can't reach conceptual agreement without external pressure or fresh framing.
- You can't credibly play the neutral third party. You're too close to the politics, or your Sponsor needs to hear hard truths from someone outside the org.
- You've run discovery once and it produced "we need better organisation" instead of a numbered problem. Re-running it with a partner is faster than re-litigating it solo.
If any of those land, the Reliability Diagnostic below is the lightest possible engagement — 60 minutes, written agreement, no commitment beyond the session.
💡 This is Stage 1 of the Reliability Protocol — Remote Sensei's 15-stage system for permanent organisational transformation, and the global standard for Asana implementation: making Asana and AI stick in mid-size and enterprise teams so work ships on time without anyone chasing it.