From Services to Product: Aurasma's Journey
- Chris Burgess
- Feb 27
- 6 min read
Updated: Apr 29
HP's acquisition of Autonomy included the small AR startup Aurasma, where I worked as a producer. To leverage the emerging AR smartphone market, HP envisioned a move from a services-only model to software licensing. This post will detail how we transformed our internal tools into a scalable product, evolving beyond a service-oriented business.
While my experience was shaped by the unique advantages of financial backing from a Fortune 50 company, the lessons I learned about shifting from services to product are broadly applicable. I'm eager to discuss how these insights can be adapted to different contexts – feel free to reach out!
Situation: Services Masking Issues
Following the company's acquisition, I found myself leading a services team. The team was comprised of talented 2D and 3D artists, animators, and technical experts, and was pushing the limits of what AR could do at the time. The 'no-code' aspect of our internal tool was a major attraction for HP, who envisioned it as a public-facing solution for broader technology adoption. But what HP saw as 'no-code' didn't translate to simple, presenting significant challenges in preparing it for external users.
Unfortunately, usability of this tool was not considered - it wasn't ready for our customers to use without extensive onboarding, despite the fact that it was 'no code'. To fix this issue, the engineering team prioritised two things: 1) making it simple to build something simple, and 2) making metrics dashboards for campaigns. While this successfully reduced the onboarding time from hours to minutes, a significant challenge remained. Customers continued to struggle with building the content they desired, such as incorporating lots of interaction, or creating personalised user experiences. This often led to frustration and disappointment as they were unable to fully realise their creative visions.
However, the platform's limitations were not reserved for our customers; even we were constantly needing to find workarounds ourselves. For example, tasks that should have taken a few hours were taking days because of the complexity of the logic gate system that was used. This meant the team was spending an extra 20-30% of their time on these workarounds, which was incredibly frustrating and prevented us from focusing on delivering truly innovative AR experiences. While the team was upskilling to handle custom JavaScript code, this process was slow when also trying to deliver projects, further hindering our ability to meet customer expectations.
We desperately needed a way to create more sophisticated experiences without adding unnecessary complexity to our workflow.
The Task: Shifting from Services to Product
My team and I knew that to unlock the true potential of Aurasma and scale the licensing aspect of the business we had to empower our users. We needed to provide them with the tools to create the engaging and interactive AR experiences they desired. This would not only increase customer satisfaction but also drive adoption of the platform, leading to business growth. As a result, I took matters into my own hands
When we lost two artists from our team, I saw an opportunity. Instead of replacing them with two new artists, I made the decision to bring in a developer. This wasn’t the obvious choice for a services team, and it carried a certain degree of risk. However, I knew that we needed more than just artistic talent—I therefore targeted a developer with creative skills—we needed better tools to execute our creative vision whilst also better empowering our users.
Once onboard, I shielded the developer’s time for tool-building, often absorbing extra work myself. Their dual role (services and development) let us prototype solutions while delivering projects. Slowly, we shifted from firefighting to designing a system that could scale. In many ways, this was the start of a product mindset within our team. Our goal was to empower our team and, ultimately, our customers.
The Action: Iterative Development and Collaboration
Agile Development:
Biweekly releases, prioritised via a spreadsheet backlog.
Team testing and feedback loops (“What worked? What’s missing?”).
We adopted an agile approach, with the developer delivering new releases every two weeks. I became the de facto product owner, with the rest of the team acting as our key stakeholders. I maintained a simple backlog in a spreadsheet, allowing us to prioritise features and track progress. Each update was tested by the team, who provided feedback on what worked, what didn’t, and what they needed next. This cycle of rapid iteration helped us gradually refine the tool while still delivering services.
Technical Pivot:
Replaced Java’s rigid logic gates with JavaScript, enabling flexibility without requiring coding expertise.
Reduced AR experience build time while boosting complexity (e.g., interactive animations).
We focused on building on top of JavaScript, moving away from the limitations of the logic gate system that was built using Java. By layering our solution on top of JavaScript, we built something that gave us the flexibility and power we needed without requiring the entire team to become proficient coders overnight. The improvements allowed us to create more advanced AR experiences while reducing the time and effort required.
Feedback-Driven Refinement:
Showcased early prototypes to clients, aligning features with their goals.
Launched a closed beta, letting users test the tool in their workflows.
Our focus remained on delivering a tool that truly met customer needs. To achieve this, we engaged in a continuous feedback loop, starting with showcasing content created with the new tool and validating that it aligned with their desired outcomes. This direct input informed our development priorities. We then expanded our feedback gathering by launching a closed beta, allowing select customers to experiment with the tool in their own workflows. The insights gained from this real-world testing were invaluable, shaping our final releases and ensuring the tool was both powerful and user-friendly. However, one critical challenge remained:
Solving the Power User Gap:
Built a modular system for power users first (scripting, custom animations).
Simplified it for novices by hiding advanced options.
The original platform worked well for novice users but failed to meet power users' needs, and its underlying architecture made scaling impossible. We chose to prioritise power users first, confident that novices were already well-served by the legacy system. By tackling power users’ complex requirements—such as scripting and custom animations—we built a modular system. Once these advanced features were in place, adapting the tool for novices became straightforward: we simply hid or disabled specialised options. This approach not only resolved scalability issues from the start but also created a unified solution. By addressing both user needs and technical limitations, we positioned the new tool as the natural replacement for the legacy platform—delivering scalability for users while capitalising on the flexibility of JavaScript to reduce operational costs.
The Result: Tangible Gains and Product Integration
Efficiency Gains:
70% faster production: Complex AR experiences dropped from a week to days.
15% performance boost: Smoother frame rates on 2015-era mobile devices.
User Empowerment:
25% surge in user-generated content after integrating our tool into Aurasma’s core platform.
Clients created showcase-worthy AR themselves, freeing us to focus on platform innovation.
Strategic Impact:
The new tool replaced the legacy platform, cutting operational costs via JavaScript’s flexibility.
Boosted HP’s vision of shifting from services dependency to scalable product growth.
Lessons Learned: The Shift from Services to Product
Looking back, this experience was a pivotal moment in my career. This journey taught me that services teams can be product incubators—if you:
Start with a pain point you live daily.
We built tools to escape our own inefficiencies, not to chase trends.
Protect innovation time fiercely.
Even one developer, shielded from short-term demands, can drive transformational change.
Let users shape the tool.
Our closed beta wasn’t a vanity metric—it exposed real barriers to adoption.
Build for extremes, then simplify.
Power users stress-test systems; novices reveal intuitive design flaws.
Metrics matter, but adoption matters more.
A 25% content surge meant nothing until users chose the platform.
For XR companies navigating the transition from client work to product development, the shift can start from within. The tools and processes you build to solve your own problems can become the foundation of something bigger.
Have you ever built a tool out of necessity? Did it ever become a product?
Comments