Hi! I am Mima 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 have been at Flock for four years and whilst the collaboration between the teams has always been good, the last year that has been taken to a new level. The pace at which the team can ship new features/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 in the new world.
This post outlines our approach to this and some of the tools that we are using: 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, problems we are trying to solve and key information about the business. This can be referenced in the creation of materials, used to build customer centric solutions and brief engineering teams. Context matters because AI is only as useful as what it knows. Without it, you get generic answers that don't understand your customers, your codebase, or what you're actually trying to solve. With it, you get something you can actually use.
The workflow looks a bit like this:
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 with what a customers would ask us 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.
The workflow we run now looks like this:
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 wire framing, scoping and estimation can now happen before the next customer call. 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.
What does the Flock MCP look like:
The MCP changed that. Anyone in the business can now ask questions about the business 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 this to build marketing materials and insights.
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 means that the team can move much faster.
What this changed between product and engineering
The time we spend together has shifted too. 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. His read after a year of working this way: the technical barrier between PM and EM is less obvious now, because both roles are increasingly speaking the same language. There becomes a lot more collaboration between the two roles, and we end up passing things back and forth now, iterating together rather than handing off.
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.
Ismael - Engineering Manager
About the author
