The Re-Platform Decision at Axon

What You'll Be Doing

You are the Senior Product Manager for trust and identity on Fusus, Axon's real-time operations platform. Fusus brings CCTV, body-worn video, license plate reader data, drone control, and alarm systems into one operating picture for public-safety agencies. When AI triage flags an incoming 911 call as high-severity, analysts pull cameras and launch drones while the incident is live. Seconds matter.

Fusus's permission system was built for one customer shape: a police department. It has since been extended eleven times, for school districts, correctional facilities, private enterprises, and international policing bodies. Each extension was a special case grafted onto the same underlying model.

Here is where that has left you:

Permissions are evaluated inside each service, using a shared library that every team copies and modifies. Seven Fusus product teams now maintain their own variant. Two of them have diverged enough that the same user gets different answers from different services.
A new customer type takes 6 to 9 weeks of engineering work to onboard, most of it spent on permissions.
Last month, a configuration error at a mid-sized agency exposed one district's camera feeds to an adjacent district for four hours. It was caught by a customer, not by Axon.
Leadership has committed to re-platforming. You have engineering capacity for one substantial change in the next two quarters, not a full rewrite.

Your job: decide what to rebuild from first principles, what to leave alone, and what to build first. Then defend it.

Constraints

These are real. Solutions that ignore them score lower than simpler solutions that honor them.

One substantial change, two quarters. You do not have capacity for a full rewrite. Something significant stays as it is. Name it and defend leaving it.
Seven product teams, no reorg. The Fusus product teams do not report to you and are shipping their own roadmaps. You cannot mandate that all seven stop and migrate. Whatever you propose has to give them a reason to adopt it.
Sub-second authorization in the incident path. Policy evaluation sits in the path of a live response. A centralized service that adds meaningful latency to every authorization decision is not viable without an answer for it.
You will own this. Your name is on this recommendation. You are in the room with the engineering leads defending it, and you are on the call when the migration goes sideways.

On Using AI

Use AI. We want you to. This role exists in a world where the work gets done with AI, and we would rather see how you direct it than pretend you didn't.

What we are looking for is not whether the AI produced something good. It is whether you noticed when it didn't. Generic access-model answers are easy to generate. The scenario constraints above are where the real work is, and AI will happily ignore them. The candidates who score well are the ones who caught that and fixed it.

Scope Note

Thirty minutes is not enough time to do this completely, and we know that. We are not looking for completeness. We are looking for what you chose to spend the time on and how you reasoned. A focused, well-argued partial answer scores higher than a comprehensive shallow one.

Communication note: Communication clarity matters here, and it is scored. We assess concision, whether you give the right context for your audience, whether you make complex trust and access concepts understandable without relying on unexplained jargon, and whether you define what "good" means rather than assuming it. We do not assess presentation style, accent, pace, or filler words. Speak naturally, and explain it the way you would to a smart colleague who does not work in identity.

What You'll Accomplish

Reason about a real platform architecture: describe how the authorization system works today, name the trade-off you are making, and account for how your own design behaves when conditions get hard.

Produce a trust and access model that holds up beyond the single example in front of you, including how access ends and not only how it starts.

Sequence a constrained re-platform: separate what gets rebuilt from first principles from what gets kept and extended, and commit to what ships in two quarters.

Design a migration path for 1,200 live agencies and name what customers experience and what could go wrong.

Demonstrate AI fluency by directing the tool rather than accepting its output, and by naming a specific moment you overrode it.

How Your Work Will Be Scored

Platform & Systems Reasoning (30%): Describes how the system actually works, names a real trade-off, and reasons about how the proposed design degrades under live operating conditions.Trust & Access Model Design (20%): The model generalizes past the example given, and access termination and lifecycle are designed, not assumed.Customer-Backwards Product Judgment (15%): Designs from a specific person's specific moment and states what would be validated before building.Communication & Concision (15%): The AI Usage Log and video answer aside, someone outside the identity domain understands both the recommendation and why it is right.AI Fluency (10%): The AI Usage Log and the video answer show direction and override, not acceptance.Resume & Background (10%): Scored separately from your uploaded resume against the role's experience requirements.

What to Submit

Platform Recommendation

DocumentRequired

Format: .pdf, .doc, .docx, .rtf, .txt, .md

Your primary artifact. A written or diagrammed recommendation. Format is your choice, document, diagram, or both. It should communicate:

What the trust and identity platform looks like after your change: the components, and how an authorization decision flows through them
What you are rebuilding from first principles versus keeping and extending, and why
What ships in the next two quarters, specifically

README Document

Document · Section A: 300-500 words. Sections B and C: no length requirementRequired

Format: .pdf, .doc, .docx, .rtf, .txt, .md

Exactly three sections.

Section A — Written analysis (300–500 words). Your recommendation, the reasoning, the trade-offs you accepted, and the risks you're carrying.

Section B — Role-specific depth: failure and migration. Answer two questions directly:

Describe one way your own proposed design fails or degrades under real operating conditions. Name what breaks, where, and under what condition. Then say what you would do about it.
1,200 agencies are live on the current model. Walk through how they get to the new one. Be specific about what customers experience and what could go wrong.

Section C — AI Usage Log (Mandatory). This is not a trick. We want to see how you work with AI, not whether you used it. For each significant interaction with an AI tool, briefly note what you asked it to help with, what it gave you, and what you kept, changed, or rejected, and why. Three interactions documented is sufficient. The log does not need to be exhaustive.

Video Walkthrough

Video · 8-10 minutesRequired

Format: .mp4, .mov, .webm

Record a video walking us through your work. Upload the file directly (MP4 or MOV). Cover these five things in order:

Summary (60 seconds) — the problem as you understand it, and your recommendation.
Artifact walkthrough (2–4 minutes) — walk through your primary deliverable and explain the decisions behind it.
Depth section (1–3 minutes) — walk through your Section B answers.
Mandatory AI question (1–2 minutes) — answer this directly: walk me through one moment where you disagreed with, pushed back on, or redirected what the AI gave you, and what you did instead. Name the specific moment. Explain what the AI produced that didn't meet the bar, what you did differently, and why.
Reflection (30–60 seconds) — what you would do differently with more time.

Speak naturally and explain it the way you would to a smart colleague who does not work in identity. We score clarity, concision, and whether you define what "good" means, not presentation style, accent, pace, or filler words.