Hi! I'm Jemima, a Product Manager. Over the last year the engagement team at Flock has driven a 152% increase in weekly active usage across key features and 40% growth in new users on our customer portal. I don't think we'd have got there at that pace without a pretty fundamental shift in how product and engineering work together.
I've been at Flock for four years and whilst the collaboration between the teams has always been good, over the last year that has been taken to a new level. The pace at which the team can ship new features and products has increased exponentially — we are able to get concepts in front of customers in hours where it would have taken weeks of analysis, scoping, and prototyping. This has been driven by the operating systems and processes built around our AI tooling and ways of working.
Special shoutouts go to: Claude, Granola, Notion, and Cursor.
Building a context-rich AI operating system
We have built an operating system for our key product domains. This includes rich context on personas, the problems we are trying to solve, and key information about the business. It can be referenced in the creation of materials, used to build customer-centric solutions, and to brief engineering teams.
Each team at Flock maintains a context folder: structured .md files that encode business domain knowledge, current priorities, architectural decisions, and how we talk about our customers and their problems. These files live alongside the codebase and are referenced across everything — PRD drafts, engineering specs, stakeholder communications, diagnostic tools, prototypes.
When a new piece of work starts, the context folder is already loaded. Building these context-rich workflows has made integrations, launches, and rolling out new features much easier and more efficient. We can spend more time talking about the difficult stuff.
Prototyping: from customer conversation to clickable demo in hours
There used to be a big bottleneck in early-stage product work between what a customer would ask for and what an engineer deemed technically feasible. The tools we use now close that gap. Granola creates a conversational memory of what customers say, and through the Granola MCP we can build prototypes that reference both the customer conversation and the codebase directly.
Granola records every customer meeting and surfaces the key moments: the specific frustrations, the feature requests, the workflows people describe. We feed those insights, alongside our actual frontend and backend codebase, into Claude Code to assess technical feasibility and scope the approach. Lovable then turns that into a working prototype.
What used to take weeks of wireframing, scoping, and estimation can now happen before the next customer call.
60% feature engagement uplift
When we iterated a key part of our operator portal using this workflow, customer engagement with that feature increased by 60%.
Making Flock's data accessible to everyone
Five months ago we built an MCP server on top of our data platform. Flock generates a lot of data — from IoT devices in vehicles, from claims, from customer behaviour — however, this data was previously only accessible to data scientists and engineers who knew where to look and how to query it using SQL.
The MCP changed that. Anyone in the business can now ask questions directly — "show me the data on this policy, how they are trending and insights we should know about the customer" — and get real, live answers without an analyst in the loop.
Teams across the business are now using this. Our Senior Marketing Manager Liam will query the data lake to get insights on how Flock has improved outcomes for customers and use that to build marketing materials.
This matters for product-engineering collaboration specifically. When a PM proposes a feature, they can now ground it in data from the start. When an engineer wants to understand a customer behaviour to scope a fix, they don't need to file a data request. The investigative work that used to require a data scientist is increasingly self-serve — and the team can move much faster because of it.
What this changed between product and engineering
The time we spend together has shifted. Less of it goes on translating between what a customer said and what that means to build. More of it goes on the harder questions: what's the right thing to build, and why.
Product and engineering are working together more seamlessly than ever before. The clearest description of what's actually shifted came from our engineering manager Ismael:
The technical barrier between PM and EM is less obvious now, because both roles are increasingly speaking the same language. There's a lot more collaboration between the two roles — we end up passing things back and forth, iterating together rather than handing off.
That shift — from handoff to iteration — is what the numbers reflect. And it's what makes the next year genuinely exciting.
About the author
