Pragma Connect

Using Strategic Research to Drive a $500K Product Pivot

Pragma’s core business, a backend engine for online games, was facing numerous headwinds, and we needed to pivot to a faster growing product that addressed a larger target market. There were several ideas we could pursue, but didn’t know which was the right one. This was, conservatively, a $500k decision that we needed to get right.

In under 4 months, I led the strategic research and design of a completely new product direction called Pragma Connect that converted a years-long prospect into a paying customer and secured strong positive responses across sales demos. More importantly, I helped the company pivot from a slow-growing backend engine to a focused social features product with immediate time-to-value.

The Challenge: The Engine Business Isn’t Working

Pragma’s core product, an online backend engine for games, was in trouble. We were selling to well-funded mid-size studios—game companies that had enough money to pay for our service but weren’t large enough to build their own backend infrastructure. The problem? That market consisted of maybe dozens of new studios per year. And many of our prospects were running out of runway before they could even get our product integrated.

In short, the business model wasn’t mathing out and we’d run out of money in 2 to 3 years.

The product faced numerous headwinds that we kept hearing about in sales calls and from paying customers: the setup and integration was complex, the time-to-value was slow (you don’t really experience the benefits until you launch and have scale), and if something went wrong with our service, their entire game would go down (we never had any major launch incidents, but this made it a high-risk decision). And the benefits of scalability and performance came too late in a game’s development cycle to overcome the upfront pain of getting the product working.

We had built something technically impressive but strategically misaligned. Studios couldn’t try before they buy, couldn’t see immediate value, and often ended up cutting online features entirely when budgets got tight.

Using Bullseye Customer Research to Inform our Pivot

The co-founders decided we needed to pivot a large chunk of our engineering team to building a cloud-based product that’s easier-to-use, shows faster time to value, and has a larger TAM (total addressable market).

There were several core pieces of technology we already had that we could build off of: cross-platform accounts (a huge pain point for studios), monetization and cross-platform stores, matchmaking services, social features with ready-made game UI, server orchestration, player data storage, to name just a few.

Deciding where to invest our limited resources was a big decision: it would cost us roughly $500k for a team of 8 (PM, lead eng, 5 engineers, and myself) to build this over 3-4 months (not including GTM motions, marketing budget, further iteration post-launch, etc.). We couldn’t afford to build the wrong thing.

To help us decide what to build, I recommended we use Bullseye Customer Research, a technique pioneered by Michael Margolis of Google Ventures. The gist of it is to create fake landing pages of different concepts to show your target customer to gauge which is most compelling.

Working with our PM and lead engineer, we scoped out rough feature sets for each idea, as well as lo-fi mockups, to help us decided which seemed like the most promising product.

We ended up with three test concepts:

1. Cross-platform identity and monetization - solving the authentication nightmare and payment processing headaches across different platforms
2. Social backend with drop-in game UI - friends lists, messaging, presence indicators, all with customizable interfaces that studios could integrate in under an hour
3. A competitor comparison - I used a competitor, Playfab, as our third option to understand how our concepts stacked up against a full-featured alternative

Doing the Research

Over 3 weeks, the PM and myself conducted research sessions with 6 technical directors and engineering leads at studios that fit our target profile. We interviewed them about their needs and pain points, then we had them look through each concept. I had htem narrate their thoughts aloud as they went in order to judge their reactions and get them talking about what they liked, disliked, and if they’d use it and pay for it or not.

Both of our concepts tested well, but the social features with game UI was the most compelling. People were really hooked by the idea of having the game UI already built (one person said they would try it just out of curiosity to see if it worked the way we advertised).

From Insights to Alignment: Making the $500K Decision

Having research insights is one thing. Getting a leadership team to bet half a million dollars on those insights is another.

I organized a synthesis session with our CEO, CTO, VP of Engineering, PM, engineering lead, and general manager. This wasn’t a presentation, it was a collaborative decision-making workshop where we had to align on our next major product direction.

I structured the session around customer jobs (what are people actually trying to accomplish?), pain points (what’s getting in their way?), and gains (where can we create the most value?). We pulled direct quotes from the research sessions and mapped out which types of studios could use each solution and when in their development cycles we could reach them.

The evidence was pretty compelling. Social features with game UI addressed the strongest pain points while playing to our technical strengths in real-time infrastructure. It also opened up more of the development cycle for sales conversations—instead of needing to catch studios at exactly the right moment, we could be valuable from early prototyping through post-launch updates. It was also a differentiator relative to our competitors.

By the end of that session, we had alignment: we were building social features with game UI.

Designing for Speed and Impact

With the direction locked in, we needed to start building immediately. We set a deadline of 3 months, which felt do-able but aggressive.

For most of the project, I stuck with lo-fi wireframes. These were enough to get the engineering team moving on core functionality like friends systems, messaging infrastructure, and data models, and then I could get the details right later in code.

But for critical user-facing moments—like the welcome screen that would be people’s first impression of the product, or the onboarding flow that needed to get developers up and running quickly—I invested in high-fidelity designs. These moments would make or break adoption, so they deserved the extra design attention.

As features were built, I jumped into the codebase to handle final UI polish and details. I find it easier to do final polish in code (no translation from Figma to code), and it freed up the engineers to move on to other features. In short, it increased quality and speed.

Working with a team of 8 (me, our PM, our engineering lead, and 5 engineers), we hit our 3-month deadline. The key was knowing when lo-fi sketches were sufficient versus when high-fidelity designs were essential, and when jumping into code was the fastest path to a polished result.

The final welcome screen

Soft Launching Pragma Connect

We hit the 3 month deadline, but during development leadership decided to do a “soft launch” and make a bigger public announcement at GamesCon, one of the largest gaming conferences of the year, where a large segment of our target market would be.

During this period, we also decided to brand the product as “Pragma Connect"—a name that captured both the social connectivity features and the seamless integration experience we were delivering.

With the soft launch the product was live and functional, and we started demoing it to prospects. The most concrete result was converting a prospect we’d been pursuing for years into a paying customer after they saw a demo of Pragma Connect. This was a studio that had shown interest in our backend engine but never pulled the trigger because of integration complexity and risk concerns. The social features product solved both problems—easier to integrate, lower risk, immediate value.

This was huge! In a market where decision making usually takes months (and sometimes years, like with this prospect), we got someone to make an immediate decision. This surprised everyone (in a good way!), from the CEO down to the team who built it.

Beyond that single conversion, the demo responses were overall very positive, validating that the social features with ready-made UI addressed real pain points in a way that was obvious to technical decision-makers.

Wrapping Up

I love working in high ambiguity, fast-moving environments with smart, motivated people. In those contexts you can achieve big things together. And that was especially true this time. What I especially enjoyed about this project is that we were facing a huge business challenge, and I was able to drive the solution from strategic research through designing and building the solution in a matter of months. I’m especially proud that the end result was a product that immediately clicked with customers — something you can only achieve when you deeply empathize with your customers and are working with a smart, motivated team.