How do I get my team to actually use the platform beyond the alerts?

You're hitting the classic adoption wall where a powerful tool is treated as a read-only feed. The answers about checklists and mandatory gates are correct, but as a PM you have a specific lever: the project lifecycle.

Don't ask them to use it for "research." Instead, modify your *own* project kickoff and launch checklist documents. Insert a required section titled "Third-Party & Infrastructure Risk Screen" with three bullet points that must be answered using Recorded Future, with a field for a screenshot or link to a saved search. For example:
* List any critical vendors or new SaaS tools in this release and their associated domains/IPs. For each, provide the Recorded Future Risk Score and note any active malware associations from the last 18 months.
* For any new external-facing endpoints, provide the CTI summary for the associated IP range or domain.
* Document any mentions of key technology stacks in this project (e.g., specific payment libraries, APIs) within ransomware leak sites in the past 12 months.

When the finance or audit team asks for the risk log prior to launch, that document is your deliverable. The analysts will use the tool because it's the source for a required project artifact, not because you asked them to change their habits. The key is owning the template and making its completion a non-negotiable part of your project timeline.

You've nailed the silent majority effect. The quiet eight are far more important than the two evangelists.

The fragility of habit is the underrated insight here. That screenshot field is a tiny behavioral hook, but it's enough. Remove it, and the entire practice vanishes, not because the tool is bad, but because you've cut the one thread connecting it to the workflow.

It's less about building a great habit and more about never breaking the mediocre one you've forced them into.

Your point about the screenshot paper trail creating the necessary friction is exactly right. It's the initial anchor that builds the routine.

We did try to measure time savings, but like user556 noted, the numbers were fuzzy and less important. The real shift was in quality and confidence. Reviews stopped stalling on "where did you get that?" debates, which saved more time in meetings than any data-entry metric could show.

I really like the checklist and project gate ideas everyone is suggesting. It seems like the consensus is to stop asking for adoption and start building it into a required step.

But I'm curious about something. A few of you mentioned modifying your own project documents, like the launch checklist. Do you find this works better with a formal PM tool like Jira or Asana, where you can create a required field, or is a simple shared doc template enough to create that mandatory feel? I'm trying to decide where to add the "RF check" field for maximum compliance.

The checklist approach is solid, but integration depth matters. A simple field in a shared doc can be ignored or filled with "N/A." For fintech compliance, you need an auditable trail.

I'd recommend embedding it directly into your risk management system's API. For our vendor onboarding, we built a microservice that takes a vendor name from the intake form, queries Recorded Future's API for the associated domains and risk scores, and auto-populates the risk log. The analyst's only task is to review the populated data and flag anomalies. This reduces friction to near-zero and creates a mandatory, auditable step that's harder to bypass than a manual screenshot.

The key isn't just making it a required field, it's reducing the cognitive load of fulfilling that requirement. The screenshot mandate works, but an API integration that pre-fills the data works better because it feels less like extra work and more like a helpful summary they need to approve.

That car analogy is perfect, I've been there. The thread's already got great advice about making it a mandatory step in your project gates, which is the main path forward. Since you're in fintech, I'd add that the use case you mentioned - risk assessments for new product launches - is a great one to lock down. The key is to make it about their job, not about the tool.

Instead of a shared workspace, consider a simple template in your project management tool where the "Recorded Future Risk Score" for any new vendor or external domain is a required field. They can't move the ticket to "Ready for Launch" without it. It becomes a compliance checkbox for them, which works wonders in our world.

One caveat from experience - start with just one or two specific fields like that. If you add too many "RF check" items, it becomes noise and they'll find a way to game it. Pick the highest-risk item in your launch process and anchor the requirement there.

The caveat about starting with one field is critical, but I'm skeptical about baking it into a PM tool's required field. That just creates a new kind of noise - people will type "N/A" or a dummy score to clear the blocker. The auditable trail user568 mentioned is the only way to make it stick, otherwise you're just adding a bureaucratic hurdle that degrades over time.

If you're in fintech, a dummy score in a Jira field is a compliance liability, not a solution. The friction shouldn't be in the ticket workflow, it should be in the actual verification step.

You're spot on with the car analogy. The platform is indeed a powerful engine, but the alerts are just the dashboard warning lights.

Everyone here is correctly focusing on the workflow integration, which is the only thing that works long-term. But I'll push back slightly on the idea that you should start by pitching specific use cases. In my experience, that's putting the cart before the horse.

First, you need to instrument the *outcome* of using the platform, not the act of using it. Before you modify a single project template, spend a week documenting where your analysts are currently getting their intel for risk assessments. Map those sources. Then, build a simple dashboard - even just a shared spreadsheet - that compares the metrics that matter to your business: time-to-assessment, number of sources cited, or (critically for fintech) the audit trail of the source data.

Once you can show that a proper RF query reduces the source count from five disparate tools to one, or cuts the research time per vendor by 60%, you have the data to mandate the change. You're not asking them to adopt a new tool; you're requiring them to meet a new performance standard. The tool becomes the most efficient way to hit that metric.

Forcing it into a checklist without this baseline measurement just creates resentment and "N/A" fields. Show the efficiency gap first, then hardwire the solution.

The car analogy is charming, but let's be honest, your team is treating it like a rental they're scared to take out of the lot. I'm going to push back on the core assumption in your question, which is that you need to "pitch use cases" or build a "shared workspace."

You've already identified the perfect use case - risk assessments for new product launches. The failure wasn't the use case, it was your method. Asking analysts to change their habits for the sake of a new tool is a consulting fairy tale. They have their own tools, their own workflows, and you're just noise.

Forget pitching. Your job as the PM is to modify the environment so the old habit becomes impossible. If a risk assessment requires a vendor risk score, then the source of that score must be Recorded Future. Full stop. You don't ask them to use it; you design the process so that completing their work *forces* them through it. The screenshot or API-driven log others mentioned isn't a nice-to-have, it's the evidence that the step was completed. In fintech, lack of evidence is a finding.

Start with one mandatory checkpoint in your launch gate. Just one. But make the proof of completion non-negotiable and auditable. They'll grumble, then they'll comply. That's how you build the mediocre, unbreakable habit user1367 was talking about.

That's exactly the kind of concrete framing that bridges the gap between tool and task. The transformation from "look at RF" to "answer these three questions using RF" is the entire battle won.

My only caveat would be to periodically review those checklist items. If you formalize them into a vendor review template, they can easily become static and drift away from the actual threats you're seeing. We schedule a quarterly check to ask if the questions are still the right ones, which keeps the data useful and the process from feeling like a rote exercise.

Preach. The "time savings" metric is a trap. Management loves it because it's easy to measure, even when the number is nonsense. The real value is in the unmeasured arguments you *don't* have to have.

But watch out. You'll get a year of that quality and confidence, and then someone will try to cut the tool's budget because you can't "prove" the ROI. That's when you need to have a paper trail of those stalled meetings from *before* you started using it.

You're right that new hire adoption is the real litmus test, and I think you're also right that "two out of ten" is a data point, not a pattern. Where I diverge is the assumption that a mandate can't create the conditions for that organic adoption.

A mandate creates the baseline usage that generates internal examples. When the next project rolls around, you don't point to the vendor documentation, you point to Susan's vendor review from last month where she caught a critical issue using the platform. That's the social proof that gets the next person, and eventually the new hire, to start there without being told.

But the mandate has to be paired with making that example easily discoverable. If Susan's work is buried in a PDF in a closed ticket, it's useless. You need a searchable internal wiki or a channel where those wins are linked. The mandate provides the raw material; you have to build the showcase.

Your car analogy hits the nail on the head, but you're thinking like a project manager, not a fintech auditor. You're asking about use cases and shared workspaces. Forget that.

The only thing that matters is the workflow lock. If a new product launch requires a risk assessment, then the official source for that assessment's external indicator data *must* be Recorded Future. Period. It's not a suggestion, it's a sourcing requirement in your control framework. You don't pitch it, you policy it.

The trick is, you don't make the lock about "using RF." You make it about completing the deliverable. The deliverable is a risk assessment memo. The memo's appendix must include the RF report for all third-party domains. No report, no sign-off. They can use all their old tools for the analysis, but the sourced data comes from one place. Turns the tool from an optional step into a compliance artifact.

Agree on consistency being the main win, but that only matters if the baseline data is actually correct. A screenshot mandate just creates the artifact, not the quality. We tried this and had to add validation rules because people would screenshot the first result page without scrolling or applying relevant filters, making comparisons useless.

The adjacent task discovery is real, but it's a double edged sword. Once people start poking around, they often misuse data because they don't understand the context. Finding an IP range is easy, but understanding why it's flagged requires platform knowledge they don't have yet. You need to pair that forced entry point with immediate, specific training on how to interpret what they're seeing, or you'll create a new problem of false positives.

I was in a similar spot with a different subscription tool. The advice here about policy over pitching is good, but you can't just make it mandatory without showing them the "why" first.

For us, it worked to identify one specific, painful gap in their current tools. Like, what's the one piece of intel they always struggle to find or verify quickly? Don't ask them to use the new platform for everything, just for that. The time savings on that single task is what gets them to poke around for the next one.