How SiriusXM Drove Product Innovation Through Bottom-Up Research

Most people know SiriusXM for its satellite radio technology that launched in the early 2000s. But as the market has shifted over the years, SiriusXM’s competition is no longer AM/FM radio, CDs, or iPod music, but instead digital streaming apps like Spotify and iHeartMedia.

The company continues to retain satellite radio as the primary line of business, but is now growing the team to invest in future products that cater to “Zillennials”, the generation between Millennials and Gen Z.

Laura Oxenfeld is a Senior UX Researcher leading the innovation charge at SiriusXM. She sat down to speak with dscout about the company’s recent product launch—and the steps she took as a researcher to help envision what would come afterwards.

See what she has to say about bottom-up research, conducting product-forward workshops, and processes that engage stakeholders from all positions and backgrounds.

Want to watch and listen to the interview instead? Check it out here!

dscout Q&A

Colleen: Can you talk through your concept ideation as an overall timeline before we dive into the step-by-step?

Laura Oxenfeld: This all started in January before I was there. That's when the business said, “We're going to make a new app.” It's not a redesign of the app that was already there, it's a completely new tech stack, new design, new functionality. It's entirely new.

✔ Identifying a gap

I started at the end of August and I was doing my meet and greets and looking around, but I started to sense a gap. That gap I sensed was because of the experience I brought to the table.

Two things. Thing one is that the last two jobs I had were at mid-stage startups where innovation is the name of the game. In these environments, you have to be constantly ideating. What's the next big play? Let's throw spaghetti at the wall and see what sticks. I've really been working in that, ‘What's next year going to look like?’ space.”

The other thing I brought to the table here is well before COVID, I got trained and certified in running human-centered design workshops remotely. I've been running workshops remotely for a very long time. I got trained through Luma Institute, if anyone's interested.

But anyway, I started at SiriusXM, I'm meeting the team, and learning what they're working on. And I realized that everyone is super heads down, executing to hit this launch deadline by the end of the year—which is very important—but also I was wondering, what's next after launch and doing all the fast follows and fixes?

✔ Looking beyond the launch

My boss Dhvani agreed, as she also comes from an innovative UX research role. She was at Moonshot Labs for a long time. She's also used to research, not just making sure the interface is good, but also helping think of product strategy and business strategy as well.

She said to put a proposal together and we'll share it with leadership and go from there. That's where I thought through what this workshop should look like. I ultimately chose the method called “creative matrix.”

In that, I used existing user research—not research I did—but what I walked into. I used that as well as business goals and product strategy as the boundaries of the exercise. Then I shared that with design and research leadership and got the thumbs up.

✔ Architecting the workshop

Then we made a conscious decision that had later consequences—we decided to have this workshop be just design and research. There were two reasons for this. One reason is the most important thing was not distracting people who were heads down, marching towards this launch date. The other reason was that it was the first time we had ever done anything like this, and we wanted it to be an internal pilot.

At SiriusXM, there's a Design Ops function, which I had never worked with before. It was so great to partner with Paul on Design Ops to prepare and think through timing, breaks, and moderation.

Then I ran the workshop. One part that always takes longer than expected is crunching the data afterward. Folks share a bunch of ideas in these workshops, but you have to make sense of them all before you can share them out in a meaningful way.

✔ Affinity mapping themes

I spent maybe a week or two partnering with Kelsey, who's another researcher at SiriusXM, on affinity mapping the themes. As soon as I had something that was clean and digestible enough in FigJam, I shared it with design and research leadership. We went back a few times to iterate this mess of concepts and determine what actually matters most to the business right now, versus what's a little too far out to concern ourselves with now.

✔ Presenting to VPs

And then that's when I transitioned into a lot of collaboration with Dhvani on what to present and how to present to the VPs of Product. They were aware of this process the whole time, they were informed, but not participating. We had to make sure that the storytelling was on point.

The evidence behind these concepts was on point. Otherwise, you're just sharing ideas and there's no context about why they're important. I did that shareout the week before this launch, [then] launch happened and then everyone's focus had been pretty swallowed up on what bugs needed to be fixed. What are modifications we need to make after the Christmas and New Year's holidays?

From top down during the concept shareout, there were different levels of connection and interest, but then launch happened and everyone's focus shifted to what's most important, which is making sure our new product is satisfying customers and that we're listening.

In January, I had some regroup conversations with the VPs, but that conversation tends to gravitate more towards what's on their mind. What do they want the future to be instead of returning to these previous concepts? Then I decided to pivot because I felt like that wasn't going anywhere.

✔ Shifting to a bottom-up approach

I pivoted to a bottom-up approach, which has been successful.

The bottom-up approach is having 1:1s with the individual contributor-level product managers, the ones who write the requirements, know the nuance of the product, and know the nuance of the roadmap. That's where I've had success. For example, some of the PMs are like, “Oh my goodness, this one slice of a concept I'm already building right now.”

Now I can see how this experience can evolve, or they're saying, “Oh, I actually was talking about this problem space the other day, but have no idea how we could even start to solve it.” Part of this is relationship building—maybe more than getting the actual concepts out there. Both the top down and bottom up know that research can do more than just make sure the interface is usable, like here are the ways we can contribute to innovation.

A couple of these items are definitely on the roadmap now, which is great. That's the bird's eye view.

You looked ahead to the “what's next” after this huge launch. Where did you start?

✔ Learning what people do and don’t know

When I started, my team had put together an onboarding package and part of that was different existing research to use.

And this is what was outdated and it was done by a vendor and done for different parts of the organization that weren't the technology org, but in reading it, I felt that it was segments. So market segments, jobs to be done, and value prop and a study on like young zillennials (young millennials and old Gen Z).

I had these pieces of foundational research that I didn't do. And started asking around, like, “How aware are you of these segments of these jobs to be done?” I realized because almost the whole team had been hired over the last year, people were not familiar with all these foundational older research products. That was a mega input.

✔ Educating on past research findings

Before the workshop, I went through these different studies and I pulled out key slides. What are the most important things to know about the segments, the jobs to be done, the value proposition, and Zillennials?

Two hours of this workshop was me doing a readout of someone else's research. But during that time, people had a scratch pad to write down product ideas as they came to mind. That was a big input. And then the other input was the business goals and the product strategy. In my onboarding package, there was a slide deck of what is the product strategy and vision.

I cross-compared the product strategy with what was in the version of the app that came out in December. I crossed things out saying, “Okay, these things are going to accomplish these parts of strategy.” I was left with a list of product strategy that had been untouched, and I paired that also with listening in all-hands meetings—like anytime I heard an executive leader say something relevant. I put all that together as the other part of the boundaries.

The boundaries were the foundational user research. The other boundaries were the product vision and business goals.

How did you know that a workshop would be the best way to get where you needed to go?

Why the creative matrix as a method? Actually, I don't have the book on my desk, but I still have my book from Luma Institute. And there's also the book Universal Methods of Design, which has a lot of methods. Whenever I'm like, “What method is needed?” and it's not off the top of my head, I'll go through a couple of my books at home and there are different activities to explore.

Like, “Are you trying to ideate? Are you trying to discover? Are you trying to narrow down?” We needed to ideate and a creative matrix as a method has you crank out as many ideas as possible.

It's a lot of silent ideation, so everyone is putting as many ideas out there as possible.

How did you prepare to lead a creative matrix? Was there anything that you had attendees prepare before joining?

No prep for the participants. We wanted this to be as little lift for the participants as possible since the launch was the most important. What took the most time was going through these four different studies and narrowing down the most important thing. Those key slides took about two hours to present—what I originally had would have taken all day.

A lot of the prep was pulling out the most important things that relate to the product strategy we haven't addressed yet. The rest of the prep was more voiceover prep because this wasn’t my work. If it was my own work it would have taken less time.

The picture in the front here is the creative matrix board, like a sliver of it. I made each participant one of these boards as well as a scratch pad. Along the top, it had the human enablers, those segments and jobs to be done.

Then those four gray boxes there were the product strategy business goal prompts. Setting up was making sure each participant had a board and adding in timing breaks. Paul and I talked a lot about how to tell if someone's multitasking and how to address it.

In the beginning of the session, I said if you need to leave and come back, please just sit out, turn off your Slack, and put your phone on do not disturb. We’re going to have breaks throughout this if anyone needs to catch up on Slack.

Did you find that folks were pretty engaged and present when they were in there?

Folks were engaged and it was good to have Paul as a co-facilitator. When he noticed someone was not really writing ideas down during the ideation portion, he would message them.

And some people actually felt even though they've been here for three years, they're like, “Why would my ideas be any good?” It was great to have that emotional partner in there. He was building people up and we said no ideas are bad ideas, we just want as many ideas as possible.

Who did you include in the creative matrix, and what emerged from the meeting?

Because I was so new, I didn’t have much to do with the list—I didn't even know who all the designers were. I worked with Kelsey, the other researcher and my boss Dhvani, to decide who should be on the list.

The initial list they gave me was about 15 people and for the exercises we were doing, we needed to limit it a little more. We narrowed it down to people who had the context, people who crank out good ideas, someone from design systems, someone from research, someone from the app, and someone from content. All the different design disciplines were covered.

You ended up with 143 concepts! How did you whittle those down?

This is what the analysis, the affinity mapping, and FigJam ended up looking like.

This took two people at least a week, if not two weeks. Basically each person had their FigJam board, and they had their little names on the tickets so we could see who wrote each of the ideas.

✔ Affinity mapping

Then we copied all the ideas/sticky notes into a new workspace. We maintained their original boards, made a new affinity mapping space, and then just started affinity mapping and figuring out what the themes were.

✔ Granular analysis

And my analysis style is extremely precise. I go down to the atomic level. I break it out into the absolute smallest pieces before you regroup it. I do feel that's a piece of critique that I have.

Sometimes after workshops, I'll see there's a bunch of great ideas, but then people don't give it the time to do as deep of analysis as they would on a normal study. If you don’t then you don't squeeze all the juice out of it.

✔ Meticulous labeling

Here, we squeezed all the juice out of it. And then the color coding—the blue, green, and purple were the three highest level categories. Each black item is a subgroup, and then under each black item has the more specific categories.

The image is zoomed out but I try to make my FigJam boards as digestible as possible. If you're a stakeholder and you pop in, you can understand what the themes are.

✔ Checking viability

This is what I brought to my first review with design leadership instead of wasting time and putting it into a slide deck and seeing that, “Oh, wait, half of these are actually not viable for the next five years.”

I brought this to get that gut check of, “Here are the things that bubbled out, and based on what you all as senior leaders who have been here longer know about the business, what should we just cut entirely?” It was more of a conversation of things being too far out or cutting. And then we can learn where we have actually already tried something in the past and then stalled or failed.

What steps did you take before sharing these concepts with senior leadership?

There was a lot of work between that FigJam board and then actually sharing with senior product leadership.

✔ Communicating with product managers

I had 143 [concepts]. I kept getting rounds of feedback from the senior design and research leadership, which was helpful. But then I also started tagging each concept with which product manager it's their area. And I would just Slack them, “Hey, are you working on something related to X, Y, and Z?”

Sometimes I hopped on calls with people, sometimes not, because I didn’t know if I could share the concepts quite yet, so I was just having conversations to ask people about what they're working on.

✔ Connecting concepts through storytelling

I started to track what there are already product briefs written on, what's already in the road map versus what's a new idea. When I was making the slides for the VP-level product leadership, what it looked like was the storytelling of what research is important for them to understand so that the concepts have meaning. But then once we were looking at each concept, I had little tags of, is this an existing work stream or is this a net new opportunity?

If there was already a product brief, then I would link the product brief. I was showing breadcrumbs that we didn't just do this workshop and then here's ideas.

I did the due diligence to figure out like, what's that already in motion and what's net new? Because that was one critique as well. People in the past here have thrown things out, but then product is like, “You sound tone deaf because you didn't know we were already doing this, or we already tried that and decided not to.” I had to do that sleuthing behind the scenes.

✔ Making basic wireframes

The other thing I did too is wireframed everything myself, which researchers don't always do. But because everyone was focusing on launch, we didn’t want to take away time from a designer. They were purposely very low fidelity, like just gray boxes and more Miro-level wireframing than a design system.

That was also to communicate that these are design concepts, not design solutions. These are not thought through. These are just to communicate what this could be. Doing the sleuthing, talking to PMs about what's working, identifying what we've already tried and had a bad experience with, and then also making the wireframes themselves was all the prep.

I think I worked two weeks almost exclusively on getting ready for that VP conversation.

As you started to have those VP-level conversations, what were you hearing back?

There are between five and seven product VPs in the room, and many of them are new. It's still a very new team and they're figuring things out. Meanwhile, we in research and design are figuring the product relationship out. I think that was a layer of the dynamic.

Then the other layer is, some of these new people come in expecting research to be a super close partner. Some of them don't have the experience of research doing anything except for usability testing. We had a range of experiences.

The most immediate reaction was that most of our user base is Gen X and older, and we need to grow into the younger generation. There was a lot of discussion around the concepts that were pointed at those. How can we pull in and satisfy the younger generation?

On those [younger generation] concepts, there was more discussion. But the other thing that was really apparent is that people started messaging my boss saying things like, “We need Laura to run workshops for us.” They saw what was possible, but they wanted to do one where they were involved in the planning and they had control over who participated. They wanted to run a similar workshop that was more focused on the outputs they wanted.

Tell us more about the choice not to include product in the workshop itself.

I originally did push a little bit on that, I wanted product to be a part of it. The two reasons we did it this way were, one, this was the first time we were doing it. We wanted to make sure it went well. Because again, the design and research leadership team are new, so they're figuring each other out.

Two, we didn't want to take time away from people. But also looking back, the workshop was four hours total. It was a lot of work for me—but for the participants, it was four hours. I don't think it would have been detrimental to ask some product managers to participate for four hours in a workshop.

But yeah, in the future we would definitely have product managers, maybe some tech leads. And then at SiriusXM, there is a group called programming and they should definitely be in it as well. So outside of product too.

Any other final learnings you’d like to share?

✔ Make time for concept validation

I used this old foundational research that was for the marketing organization.

When I was doing the readout with the product VPs and the ground level PMs, everyone asked, “What did customers think about it?” Back when I was at my previous company, I did concept validation research all the time and I enabled other people to run concept validation research and I wanted it to be part of this process—but we didn't have time.

Our recruiting process is continuously improving, so we can be more targeted about who we speak with. What I would definitely do next time with this workshop is bake in time to do concept validation research.

Do all the stuff, get the ideas out, narrow it down to some sort of list, and then do the validation research. That way when you’re sharing it with product partners or whoever, you actually know what ideas customers want. Otherwise I think it's a little too abstract. Things can spin and, whatever they care about in the moment, they're going to latch on to.

But both here and several other places I've worked, when people get that evidence from user research, they listen to it. I do feel skipping that part led to less traction in the uptake.

✔ Don’t wait for the “perfect” time

The other thing is that the timing did not work super well, but there is no perfect time. Don't wait until everyone has bandwidth or the timing is right. Just do the thing and trial and error as you go, pivot if you need to. I think that's mainly what didn't work well.

There's another slide on what did work well. A big thing is, this is a culture building exercise. The participating designers and researchers had been incredibly heads down on the nuances of this product. They really enjoyed the opportunity to carve out time and space to take a breath, think forward, be creative. They really enjoyed that.

I'm sure a cross-functional group would feel similar. I keep saying everyone's new, not everyone, but so many people are new at SiriusXM. It's cross functional to building relationships between the designers and the PMs and the other partners. [They are normally] working together having these transactional, remote, Zoom based conversations. Having this other space to build connection [made a difference].

✔ Find the people who listen

There is at least one VP that fiercely believes in some of these concepts, and she has some new hires. Basically I'm making sure we are baking research into our process—so I think that is something that worked well.

That's something in general I recommend with research. You can't force people to listen, but you can find the people that listen. And then when they succeed, other people are going to learn from them and then people will start coming.

It's relationship building. You can lead a horse to water, just work with the people that are excited for your research.

Final words from Laura

Don't forget, just keep trying different ways. You’ve got to push innovation in any way that works for your organization.

You may also be interested in…

• How Microsoft Fosters a Continuous Learning Culture

• Using Journey Mapping As a Tool for Cross-Functional Research

• Research in Three Dimensions: How Fjord Mixed Modalities for Iterative Insights