AI has fundamentally changed the world of engineering. Build cycles that once dragged now move at pace, and teams are scrambling to keep up with the shift. To find out the reality of how engineering teams are actually changing on the ground, Nathan Connolly, CEO of Consortia, spoke to Bruce Pannaman from 9Fin (experts in Financial Analytics Software).
Firstly if you havent yet heard of 9fin, they are a financial analytics software company that organises debt market information and turns it into data, news, and analytics that finance teams can use every day. The platform helps teams save time, make clearer decisions, and win more business. 9fin works across complex debt capital markets and supports important financial decisions with technology and AI. The company operates from offices in London, New York, and Belfast and continues to grow at pace.
Here are the five key insights from Nathan and Bruce's conversation on the transformation of the engineering role, the essential skill sets, and the future of product leadership.
Insight 1: AI Moves the Bottleneck Upstream
Bruce didn't overstate the impact of AI copilots at 9fin: "What used to take two engineers two weeks now takes one engineer a day or two."
AI copilots like Cursor completely changed the pace at 9fin. Build time stopped being the limiter; instead, the bottleneck moved upstream.
"The bottleneck always used to be how quickly we can execute requests and needs, engineering time to build them," Bruce explained. Now, the challenge is building "a backlog of ideas and a backlog of what we should do next".
When AI removes the drag, teams need engineers who understand the user problem, not just the ticket. This means leaders must rethink hiring and process. Capacity is no longer the issue; choosing the right thing to build is.
Insight 2: The Independent Product Engineer
Bruce described the Product Engineer profile in a simple triangular shape: Product Sense, Front-End Skills, and Back-End Skills.
It sounds tidy on paper, but he made the challenge clear. Full-stack excellence doesn’t really exist. No one is equally strong across every layer. The point, he clarified, isn’t perfection. The point is independence.
A product engineer should be able to:
- Understand the user problem, not just the ticket.
- Get a prototype out independently and as low-scoped as possible.
- Make decisions fast, iterate, and drive business impact.
- Know when something is good enough to test.
Background Matters More Than a Skills Matrix
Bruce explained that focusing purely on tools and frameworks misses the mark. Instead, he looks for specific backgrounds that breed this mindset:
- Early-Stage Startup Founders/Engineers: They thrive because they've had to do "a bit of everything" , fostering curiosity and a focus on impact.
- Consultancy Engineers: They excel because they're used to "very quick MVP and very quick turnarounds of proof of concept" , trading deep system knowledge for pace and functional delivery.
This is where Consortia’s work sits tightest. These profiles are rare. You can’t just scan CVs for tools and frameworks. You need to understand how someone thinks.
Insight 3: PMs Don't Get Replaced, They Get Elevated
Bruce didn’t see Product Engineering as replacing Product Managers. He saw it as a movement that lifts them.
He told his PMs:
“This is an opportunity for you to lead at a higher level.”
When engineers understand the why, PMs stop spending their days pushing sprints through. They move up into strategy, stakeholder shaping and vision. Engineers stop waiting for instructions. They run with outcomes and check in less.
The PM–engineer relationship becomes a partnership. Less handover, more shared ownership.
This shift is showing up across the market. PMs now need technical literacy, user depth and data fluency. Engineers need product thinking. Teams drift together because the work demands it.
Insight 4: How 9fin Actually Adopted AI with Structured Experimentation
The adoption of AI at 9fin was a careful, slow rollout, not a sweeping transformation or glossy story. The CTO initially pushed back at first on quality concerns. Others felt they’d fall behind if they didn’t learn the tools.
So, 9Fin set clear rules focused on risk mitigation and accountability:
- Data Security: Don't send data anywhere unsafe.
- IP Protection: Use tools that don't train on company IP.
- Accountability: Follow the same QA steps whether a person or a model wrote the code. "You have to put that pull release out, and everyone's going to assume it's your work".
The breakthrough came from hackathons. These low-risk experiments allowed the team to "drop tools for two or three days" and see the speed gains were real. "We were amazed at what we could get out of it," Bruce recalled.
Builds improved. Ideas sharpened. The team backed wider adoption because they’d seen it work.
This simple lesson became the foundation: Structured experimentation beats sweeping transformation.
Insight 5: Where Product Engineering Works and Where It Doesn’t
Product Engineering excelled at 9fin in specific areas: growth and trial-conversion work. These teams rely on pace, small iterations, and strong product sense.
But Bruce was clear: It won’t work everywhere.
- Specialist Engineering: Deep systems, heavy infrastructure, and complex system design don't suit this model. These areas still need specialist teams because Product Engineers can get blocked if the work depends on large backend or systems design changes.
- The Rising Pattern: Bruce highlighted the rise of forward-deployed engineers. These roles sit close to clients, have a product mindset, and build fast end-to-end without slipping into bespoke consultancy work. This role "fits really nicely" with the product engineer mindset.
For CTOs and Heads of Engineering, this nuance matters. Product engineering is powerful when the problem fits. It’s not a blanket answer.
Bruce’s Markers: What Good Product Engineers Do Differently
Bruce's clearest markers for a truly impactful Product Engineer came near the end of the conversation:
Good product engineers:
- Ask why before they act.
- Switch between user language (non-technical) and engineering detail (technical).
- Talk to customers and extract data from user interviews.
- Make quick, small bets (hypotheses).
- Say “we’ll know by Friday” and keep to it (accurate estimation).
- Drive outcomes (business impact), not story points (lines of code).
They also need to be curious, comfortable making calls, and adapt based on changing requirements. These behaviours define product judgment, which Consortia look for, beyond just capability.
Final Thoughts
AI has reshaped product and engineering work over the past year, and now the dawn of Product Engineering gives teams a way to take the lead. It works when engineers can think for themselves, PMs shift up a level, and leaders build the right structure of team around them.
Many companies want to make this move. Few know where to start or how to source the rare profiles that combine product sense with deep engineering ability. That’s the gap Consortia can help with: helping leaders separate the hype from the real thing and hire people who can deliver impact.
.jpg)
