One idea from Pega’s Q3 FY2026 earnings call matters far more to architects and customers than any revenue number – the Lighthouse team Pega is now shaping.
I have been following Pegasystems as a platform provider more closely than ever. The financial results are already out through Pega’s official channels – link here, so I am not going to talk about ACV, revenue or growth percentages here.
I want to focus on something more relevant to the Pega community, customers, architects and partners. The direction of bringing product expertise closer to clients, and what it could change.
Before getting to that, let me share three situations I have personally come across while working with Pega customers. They explain why this direction caught my attention.
1. Do business stakeholders know what Pega can do?
I have seen this more than once.
Business stakeholders know the Pega application they use every day. They do not always know what the wider platform is capable of.
I still remember a conversation at one of my previous clients. A business stakeholder had just attended PegaWorld for the first time, and his reaction was roughly this:
“I thought Pega was just a CRM tool. I didn’t realize it could do all of this.”
That stayed with me.
He had been working around Pega applications for a while, yet his understanding of Pega was limited to the one solution in front of him.
So how did we get there?
I see no value in blaming the customer, the implementation partner, the architects or Pega. But there is a real opportunity here.
Business stakeholders deserve to understand what the platform they invested in can do, especially when that platform is changing this quickly. Otherwise organizations keep solving tomorrow’s problems with yesterday’s understanding of Pega.
2. Is the product really the problem?
Whenever I hear frustration about an existing Pega application, I often say the same thing.
“More often, the issue is not with the platform, but with the implementation.”
No platform is perfect. But many Pega applications running today were designed years ago. Some still carry architectural decisions, UI patterns, integrations and development practices from a completely different generation of the platform.
Pega itself has moved on. We now talk about Constellation, Blueprint, GenAI, agents, modern cloud architecture, process AI and much more.
Yet some applications, and sometimes the teams maintaining them, still operate with what I call a traditional PRPC mindset.
Heritage applications deserve modernization in this AI era. They should not be looked down on as outdated, or used as evidence that the platform cannot deliver.
That requires one thing at the top. An adoption mindset.
3. Who owns the difficult technology decisions?
This one comes straight from my experience with enterprise customers in the EMEA region.
Some decisions need expertise beyond the implementation partner, the client LSA or even the account team. Sometimes you need someone much closer to the actual product engineering team.
AI makes this even more important. Architecture decisions around GenAI, agents, security, data, cloud and enterprise governance carry serious consequences.
Getting the right product expertise involved at the right time makes a huge difference.
I have seen the positive side of this too. At one of my previous clients, we went through a stack split-up and a Pega Cloud migration. Pega’s Service Assurance team supported us closely throughout. We had weekly conversations, discussed challenges openly and worked through the important decisions together.
We pulled it off together with the Pega team.
That experience reinforced something I have believed for a long time. Bringing the right Pega expertise in early can significantly accelerate difficult transformations.
Which brings me to the Lighthouse team.
What Pega is shaping with the Lighthouse team
During the earnings call, Pega talked about bringing together a close-knit group of experts, including engineering expertise, under what they call the Lighthouse team.
One line stood out for me. Pega described the Lighthouse team as:
“Forward deployed engineers who will work directly with clients to accelerate successful deployment and help them realize value.”
Note the word “will”. This is not a model you can request on your next project yet. Pega is still building and shaping it, and the details of how it will run are not public. (*as of October, 2026)
But the intent is clear, and it is a reassuring one. The people who build and deeply understand the product moving closer to the people implementing and using it.
What it could mean for customers and Pega
If it lands the way it is described, I see benefits on both sides.
For customers, it could mean better access to the right expertise when facing complex adoption, architecture or deployment challenges. The kind of support I experienced during our stack split, but closer to product engineering.
For Pega, it could create a much shorter feedback loop between product engineering and real enterprise implementations.
Think about the cycle:
Product Engineering → Client Deployment → Real-world Feedback → Product Improvement → Faster Adoption
That cycle could become especially powerful for newer capabilities, where established implementation patterns are still forming.
Moving beyond the N-1 mindset
Another interesting part of the Q&A was about customer adoption.
Many enterprise customers follow an N-1 strategy, staying one release behind the latest platform version.
Historically that made sense. Stability and predictability often mattered more than the newest features.
But the landscape has changed. When capabilities around AI, agents, automation and user experience move this fast, waiting too long also means delaying business value.
The challenge for Pega is not telling customers to upgrade faster. It is giving them the confidence to do it.
That means enough expertise, support and evidence to make the decision responsibly. A team like Lighthouse could be one of the ways Pega builds that confidence.
What I will be watching for
All three scenarios share a common theme. Modernization. Awareness. Accountability.
Some organizations struggle to modernize heritage applications. Some business stakeholders do not yet see the full potential of their Pega investment. And sometimes implementation teams need deeper product expertise to make important architecture decisions with confidence.
The Lighthouse approach has the potential to address parts of all three.
Whether it does will depend on how Pega shapes it. Which customers and use cases it targets first. And how these engineers work alongside existing customer teams, LSAs, Pega Consulting and partners, rather than around them.
But the direction is exciting. Bring product engineering closer to the customer. Help customers deploy successfully. Learn from real implementations. Feed those learnings back into the product.
If Pega gets that cycle right, everyone in the Pega community benefits.
Owning the Pega platform is only half the story. The real value comes from continuously adopting what the platform has become capable of.
