The future of UX research: AI's role in analysis and synthesis ✨📝

As part of our beta release, you'll gain access to the newest enhancements to our Qualitative Insights tool (previously known as Reframer).
‍

1. Insights: A dedicated space to create, organize, and communicate your key takeaways. Create Insights on your own or with AI.‍
2. AI capabilities: Optional AI-powered assistance to create Insights from your observations to accelerate your analysis process.

Our new Insights and AI functionality streamlines your qualitative analysis process, allowing you to quickly summarize, create, and organize key takeaways from your data.

‍

Help documentation

1. How AI Insights clustering works in Optimal
2. ‍Create an Insight with and without AI
3. How AI generated Insights work in Optimal
4. Our AI guiding principles
5. How to set your preferences for AI
6. Analyzing & sharing your Insights
7. Learn more about Qualitative Insights
   ‍

Notes on AI Privacy & Security

Optimal uses AWS Amazon Bedrock, which is the fully managed service that makes large language models (LLMs) from Amazon and leading AI startups available through an API, for AI generation for Qualitative Insights.

Amazon Bedrock meets industry-leading standards for compliance, including: ISO, SOC, CSA STAR Level 2, GDPR, and HIPAA eligible. Learn more about Amazon Bedrock.

‍

We take your privacy seriously. When you use AI Insights: 

1. Your data stays within your organization
2. We don't use it to train other AI models
3. You control when to use AI for insights
4. AI features can be turned on or off anytime
   ‍

Questions & feedback

‍

If you have any questions, please reach out to our support team via live chat.

‍

We appreciate any feedback you have on improving your experience and invite you to share your thoughts through this feedback form at anytime. Our product team will also be in touch mid-late October to to gather further insights about your experience.

Recently, everyone in the design industry has been talking about design sprints. So, naturally, the team at Optimal Workshop wanted to see what all the fuss was about. I picked up a copy of The Sprint Book and suggested to the team that we try out the technique.

‍

In order to keep momentum, we identified a current problem and decided to run the sprint only two weeks later. The short notice was a bit of a challenge, but in the end we made it work. Here’s a run down of how things went, what worked, what didn’t, and lessons learned.

‍

A sprint is an intensive focused period of time to get a product or feature designed and tested with the goal of knowing whether or not the team should keep investing in the development of the idea. The idea needs to be either validated or not validated by the end of the sprint. In turn, this saves time and resource further down the track by being able to pivot early if the idea doesn’t float.

‍

If you’re following The Sprint Book you might have a structured 5 day plan that looks likes this:

• Day 1 - Understand: Discover the business opportunity, the audience, the competition, the value proposition and define metrics of success.
• Day 2 - Diverge: Explore, develop and iterate creative ways of solving the problem, regardless of feasibility.
• Day 3 - Converge: Identify ideas that fit the next product cycle and explore them in further detail through storyboarding.
• Day 4 - Prototype: Design and prepare prototype(s) that can be tested with people.
• Day 5 - Test: User testing with the product's primary target audience.

‍

When you’re running a design sprint, it’s important that you have the right people in the room. It’s all about focus and working fast; you need the right people around in order to do this and not have any blocks down the path. Team, stakeholder and expert buy-in is key — this is not a task just for a design team!After getting buy in and picking out the people who should be involved (developers, designers, product owner, customer success rep, marketing rep, user researcher), these were my next steps:

‍

Pre-sprint

1. Read the book
2. Panic
3. Send out invites
4. Write the agenda
5. Book a meeting room
6. Organize food and coffee
7. Get supplies (Post-its, paper, Sharpies, laptops, chargers, cameras)

‍

‍

The sprint

‍

Due to scheduling issues we had to split the sprint over the end of the week and weekend. Sprint guidelines suggest you hold it over Monday to Friday — this is a nice block of time but we had to do Thursday to Thursday, with the weekend off in between, which in turn worked really well. We are all self confessed introverts and, to be honest, the thought of spending five solid days workshopping was daunting. At about two days in, we were exhausted and went away for the weekend and came back on Monday feeling sociable and recharged again and ready to examine the work we’d done in the first two days with fresh eyes.

‍

Design sprint activities

‍

During our sprint we completed a range of different activities but here’s a list of some that worked well for us. You can find out more information about how to run most of these over at The Sprint Book website or checkout some great resources over at Design Sprint Kit.

‍

Lightning talks

‍

We kicked off our sprint by having each person give a quick 5-minute talk on one of these topics in the list below. This gave us all an overview of the whole project and since we each had to present, we in turn became the expert in that area and engaged with the topic (rather than just listening to one person deliver all the information).

‍

Our lightning talk topics included:

• Product history - where have we come from so the whole group has an understanding of who we are and why we’ve made the things we’ve made.
• Vision and business goals - (from the product owner or CEO) a look ahead not just of the tools we provide but where we want the business to go in the future.
• User feedback - what have users been saying so far about the idea we’ve chosen for our sprint. This information is collected by our User Research and Customer Success teams.
• Technical review - an overview of our tech and anything we should be aware of (or a look at possible available tech). This is a good chance to get an engineering lead in to share technical opportunities.
• Comparative research - what else is out there, how have other teams or products addressed this problem space?

‍

Empathy exercise

‍

I asked the sprinters to participate in an exercise so that we could gain empathy for those who are using our tools. The task was to pretend we were one of our customers who had to present a dendrogram to some of our team members who are not involved in product development or user research. In this frame of mind, we had to talk through how we might start to draw conclusions from the data presented to the stakeholders. We all gained more empathy for what it’s like to be a researcher trying to use the graphs in our tools to gain insights.

‍

How Might We

‍

In the beginning, it’s important to be open to all ideas. One way we did this was to phrase questions in the format: “How might we…” At this stage (day two) we weren’t trying to come up with solutions — we were trying to work out what problems there were to solve. ‘We’ is a reminder that this is a team effort, and ‘might’ reminds us that it’s just one suggestion that may or may not work (and that’s OK). These questions then get voted on and moved into a workshop for generating ideas (see Crazy 8s).Read a more detailed instructions on how to run a ‘How might we’ session on the Design Sprint Kit website.

‍

Crazy 8s

‍

This activity is a super quick-fire idea generation technique. The gist of it is that each person gets a piece of paper that has been folded 8 times and has 8 minutes to come up with eight ideas (really rough sketches). When time is up, it’s all pens down and the rest of the team gets to review each other's ideas.In our sprint, we gave each person Post-it notes, paper, and set the timer for 8 minutes. At the end of the activity, we put all the sketches on a wall (this is where the art gallery exercise comes in).

‍

‍

‍

Art gallery/Silent critique

‍

The art gallery is the place where all the sketches go. We give everyone dot stickers so they can vote and pull out key ideas from each sketch. This is done silently, as the ideas should be understood without needing explanation from the person who made them. At the end of it you’ve got a kind of heat map, and you can see the ideas that stand out the most. After this first round of voting, the authors of the sketches get to talk through their ideas, then another round of voting begins.

‍

‍

‍

Usability testing and validation

‍

The key part of a design sprint is validation. For one of our sprints we had two parts of our concept that needed validating. To test one part we conducted simple user tests with other members of Optimal Workshop (the feature was an internal tool). For the second part we needed to validate whether we had the data to continue with this project, so we had our data scientist run some numbers and predictions for us.

‍

‍

Challenges and outcomes

‍

One of our key team members, Rebecca, was working remotely during the sprint. To make things easier for her, we set up 2 cameras: one pointed to the whiteboard, the other was focused on the rest of the sprint team sitting at the table. Next to that, we set up a monitor so we could see Rebecca.

‍

Engaging in workshop activities is a lot harder when working remotely. Rebecca would get around this by completing the activities and take photos to send to us.

‍

‍

Lessons

‍

• Lightning talks are a great way to have each person contribute up front and feel invested in the process.
• Sprints are energy intensive. Make sure you’re in a good place with plenty of fresh air with comfortable chairs and a break out space. We like to split the five days up so that we get a weekend break.
• Give people plenty of notice to clear their schedules. Asking busy people to take five days from their schedule might not go down too well. Make sure they know why you’d like them there and what they should expect from the week. Send them an outline of the agenda. Ideally, have a chat in person and get them excited to be part of it.
• Invite the right people. It’s important that you get the right kind of people from different parts of the company involved in your sprint. The role they play in day-to-day work doesn’t matter too much for this. We’re all mainly using pens and paper and the more types of brains in the room the better. Looking back, what we really needed on our team was a customer support team member. They have the experience and knowledge about our customers that we don’t have.
• Choose the right sprint problem. The project we chose for our first sprint wasn’t really suited for a design sprint. We went in with a well defined problem and a suggested solution from the team instead of having a project that needed fresh ideas. This made the activities like ‘How Might We’ seem very redundant. The challenge we decided to tackle ended up being more of a data prototype (spreadsheets!). We used the week to validate assumptions around how we can better use data and how we can write a script to automate some internal processes. We got the prototype working and tested but due to the nature of the project we will have to run this experiment in the background for a few months before any building happens.

‍

Overall, this design sprint was a great team bonding experience and we felt pleased with what we achieved in such a short amount of time. Naturally, here at Optimal Workshop, we're experimenters at heart and we will keep exploring new ways to work across teams and find a good middle ground.

‍

Further reading

‍

• The Sprint Book - a book by Jake Knapp
• Design Sprint Kit — a whole bunch of presentation decks, and activities for sprints
• Sprint Stories — some case studies that show the processes and value of design sprints
• How to run a remote design sprint without going crazy - an article by Jake Knapp
• Choosing the right sprint problem - a blog by Lisa Jansen

Introduction

‍

The skills market has a familiar whiff to it. A decade ago, digital execs scratched their heads as great swathes of the delivery workforce decided to retrain as User Experience experts. Project Managers and Business Analysts decided to muscle-in on the creative process that designers insisted was their purview alone. Win for systemised thinking. Loss for magic dust and mystery.

‍

With UX, research and design roles being the first to hit the cutting room floor over the past 24 months, a lot of the responsibility to solve for those missing competencies in the product delivery cycle now resides with the T-shaped Product Managers, because their career origin story tends to embrace a broader foundation across delivery and design disciplines. And so, as UX course providers jostle for position in a distracted market, senior professionals are repackaging themselves as Product Managers.

‍

‍

‍

Another Talent Migration? We’ve Seen This Before.

‍

The skills market has a familiar whiff to it. A decade ago, Project Managers (PMs) and Business Analysts (BAs) pivoted into UX roles in their droves, chasing the north star of digital transformation and user-centric design. Now? The same opportunities to pivot are emerging again—this time into Product Management.

‍

And if history is anything to go by, we already know how this plays out.

‍

Between 2015 and 2019, UX job postings skyrocketed by 320%, fueled by digital-first strategies and a newfound corporate obsession with usability. PMs and BAs, sensing the shift, leaned into their adjacent skills—stakeholder management, process mapping, and research—and suddenly, UX wasn’t just for designers anymore. It was a business function.

‍

Fast-forward to 2025, and Product Management is in the same phase of maturation and despite some Covid-led contraction, bouncing back to 5.1% growth. The role has evolved from feature shipping to strategic value creation while traditional project management roles are trending towards full-stack product managers who handle multiple aspects of product development with fractional PMs for part-time or project-based roles.

‍

‍

‍

Why Is This Happening? The Data Tells the Story.

‍

📈 Job postings for product management roles grew by 41% between 2020 and 2025, compared to a 23% decline in traditional project management roles during the same period (Indeed Labor Market Analytics).

‍

📉 The demand for product managers has been growing, with roles increasing by 32% yearly in general terms, as mentioned in some reports.

‍

💰 Salary Shenanigans: Product Managers generally earn higher salaries than Business Analysts. In the U.S., PMs earn about 45% more than BAs on average ($124,000 vs. $85,400). In Australia, PMs earn about 4% to 30% more than BAs ($130,000 vs. $105,000 to $125,000) wave.

‍

‍

‍

Three Structural Forces Driving the Shift

‍

1. Agile and Product-Led Growth Have Blurred the Lines
   Project success is no longer measured in timelines and budgets—it’s about customer lifetime value (CLTV) and feature adoption rates. For instance, 86% of teams have adopted the Agile approach, and 63% of IT teams are also using Agile methodologies forcing PMs to move beyond execution into continuous iteration and outcome-based thinking.
   ‍
2. Data Is the New Currency, and BAs Are Cashing In
   89% of product decisions in 2025 rely on analytics (Gartner, 2024). That’s prime territory for BAs, whose SQL skills, A/B testing expertise, and KPI alignment instincts make them critical players in data-driven product strategy.
   ‍
3. Role Consolidation Is Inevitable
   The post-pandemic belt-tightening has left one role doing the job of three. Today’s product managers don’t just prioritise backlogs - they manage stakeholders, interpret data, and (sometimes poorly) sketch out UX wireframes. Product manager job descriptions now list "requirements gathering" and "stakeholder management"—once core PM/BA responsibilities.

‍

‍

‍

How This Mirrors the UX Migration of 2019

‍

Same pattern. Different discipline.

‍

‍

‍

The Challenges of Becoming a Product Manager (and Why Some Will Struggle)

‍

👀 Outputs vs. Outcomes – PMs think in deliverables. Transitioning PMs struggle to adjust to measuring success through customer impact instead of project completion.

‍

🛠️ Legacy Tech Debt – Outdated tech stacks can lead to decreased productivity, integration issues, and security concerns. This complexity can slow down operations and hinder the efficiency of teams, including product management.

‍

😰 Imposter Syndrome is Real – New product managers feel unqualified, mirroring the self-doubt UX migrants felt in 2019. Because let’s be honest—jumping into product strategy is a different beast from managing deliverables.

‍

‍

‍

What Comes Next? The Smartest Companies Are Already Preparing.

‍

🏆 Structured Reskilling – Programs like Google’s "PM Launchpad" reduce time-to-proficiency for new PMs. Enterprises that invest in structured career shifts will win the talent war.

‍

📊 Hybrid Role Recognition – Expect to see “Analytics-Driven PM” and “Technical Product Owner” job titles formalising this shift, much like “UX Strategist” emerged post-2019.

‍

🚀 AI Will Accelerate the Next Migration – As AI automates routine PM/BA tasks, expect even more professionals to pivot into strategic product roles. The difference? This time, the transition will be even faster.

‍

‍

‍

Conclusion: The Cycle Continues

‍

Tech talent moves in cycles. Product Management is simply the next career gold rush for systems thinkers with a skill for structure, process, and problem-solving. A structural response to the evolution of tech ecosystems.

‍

Companies that recognise and support this transition will outpace those still clinging to rigid org charts. Because one thing is clear—the talent migration isn’t coming. It’s already here.

‍

‍

This article was researched with the help of Perplexity.ai