How I would think about Flock as a platform.
How can Flock unify its ecosystem into one platform that law enforcement agencies can easily integrate, trust, and use for daily operations?
I used public information to map the ecosystem, reconstruct the data and integration flows, identify product opportunities, and prioritize where I would invest first as a Senior PM, Platform & Integrations.
This is an independent product strategy exercise, not commissioned work. I have no inside knowledge of Flock’s systems.
The Flock Platform
From real-world capture to actionable intelligence, reconstructed from public sources.
Capture·Falcon LPR·Falcon LPR reads plate ABC 1234 with make, model, color and distinguishing marks
Read by RTCC analyst· audit writtenHover for what triggers
What surfaces: the hotlist alert on the FlockOS live map
Who is looking: the RTCC floor where the alert lands
Awaiting accessnot yet openedI start by mapping the system. It helps me see how the pieces connect, where data moves, and where the biggest product opportunities are. This architecture is based on public information.
The problem
Information from CAD, 911, LPR, video, maps, drones, partners, and evidence is spread across different people and systems, and it often arrives too late for the moment it is needed. Responders must manually piece together an incomplete picture while the incident is still unfolding.
7:42 Call intake. The call taker holds 1 of 9 in the tool they are already working in, having taken the incident from the caller. Nothing else has entered the incident yet.
One incident
The incident moves to a new person every few minutes, and each one starts from what their own tools happen to show. The rest is still reachable, one system and one login at a time.
Reachable in full at every minute. Assembled at none of them.
With Flock Assembled Context
Flock brings the relevant signals together in real time as one shared, authorized incident context. The right people receive timely information in their workflow, with its source, freshness, permissions, and access history attached.
7:42 Call intake. 1 of 9 assembled and delivered to the call taker, each carrying its source, freshness and permission state. Nothing was handed back at the change of shift.
One incident
The incident still moves to a new person every few minutes, and now the context moves with it. Each one picks up everything gathered so far, with its source, freshness, permissions, and access history attached.
Only ever climbs, because the context belongs to the incident.
Who it is for
The API is the mechanism, not the outcome. Before I would design a single endpoint I would name who is served and what each of them is actually stuck on.
The job
Route the right response quickly
Friction today
CAD, camera, and location signals are disconnected
What good looks like
The incident enriches itself with nearby context
Prioritization
This is the working model, not a picture of one. Each candidate integration is scored one to five on six weighted dimensions. The sliders hold the weights I would publish. Move one and the ranking below recomputes, which is what a roadmap review should be: an argument about weights held in the open, not a contest of who escalates loudest.
Weights
Scores are fixed at one to five per dimension. Only the weighting moves.
Wins on every dimension that matters and touches the most agencies. First lighthouse.
Lower reach, highest differentiation. No competitor can copy it without Flock's vehicle data.
The trust score carries it. Custody is where agencies feel exposed.
Easy and broad, but it differentiates nothing. Useful, not a wedge.
Strong demand, weak feasibility, competes with an incumbent's core product.
A segment bet. Waits until the governance model is proven.
VMS ingest is the instructive one. Scoring it publicly is how you decline a loud request without the conversation becoming political.
The build order
The score ranks work inside a stage. It never reorders the stages themselves: foundations ship first because every integration inherits them, and no partner logo buys its way past that queue. Select a stage to see what belongs in it and why it sits where it does.
Governance
Trust is the product here, not the paperwork. In this market governance is the moat, and it has to be experienced in the product rather than published on a policy page. Each principle below is paired with the thing it becomes once it is built.
Local control by default
The customer sets sharing, retention and access boundaries. Cross-agency reach is opt-in and reversible in one place.
Purpose limitation
Every sensitive search carries a case or offence code as structured data, not a free-text note nobody reads.
Least privilege
Attribute-based access: this analyst, in this agency, on this open case, inside the retention window.
Explainability
The user can see why a record surfaced, which source produced it, how confident it is, and who else has opened it.
Human verification
The product distinguishes a lead from a fact, and requires confirmation before consequential action.
Auditability
Every search, view, export, share and policy change writes an immutable event a city council could read.
Transparency
Agencies get tooling to publish retention, sharing partners and aggregate usage without exposing operations.
Measurement
One question underneath all of it: are integrations actually making the job easier? Five groups of evidence answer it. A platform can get faster and less accountable at the same time, so speed and governance get reported side by side or not at all.
Speed
- Incident to useful intelligence
- Lead to verification
- Time to first action
Reliability
- API uptime
- Data freshness
- Failed and retried events
Adoption
- Customers running 2+ integrations
- Weekly active use by role
- Connected workflow usage
Efficiency
- Time to onboard an integration
- Engineering effort per integration
- Support tickets per connector
Trust
- Policy-compliant access rate
- Audit coverage
- Unauthorised access events
Why me
Every claim in this strategy is something I have already had to do somewhere else, on a smaller stage.
FalcoScan
I built the LLM and API workflows that pulled 6,700+ products across 29 markets into one model, designed around the decision the user was making rather than the quirks of each source.
CFPB complaint product
On 17.1M records I caught a rolling-window transformation that would have overstated complaint volume several times over, traced the lineage, corrected the model, and shipped behind 91 automated tests.
Public sector client at AWS
For a public sector client at AWS, I helped map how towers, ground sensors, plate readers, drones and body-worn devices reached command centers over links that could not be relied on. The same shape as FlockOS.
AWS Global Visual Assets
I built and ran an internal platform for 98 global leaders across 60,000+ assets, with four environments, role-based access and governance tags in the model from the start.
What I would bring on day one
A product manager who can take heterogeneous source data, define the model and the trust boundaries, pick the smallest high-value workflow, and lead engineering, solutions, legal and partners through delivery and adoption.
Next work
CFPB Complaint Data