Episode transcript:
Jose
Welcome to the Smooth Scaling Podcast, where we talk with industry experts to uncover how to design, build, and run scalable and resilient systems, with the ultimate goal of providing a great user experience. I'm your host, Jose Quaresma, and today we have Ka-ren Risvig with us. She’s the Head of Product and UX here at Queue-it, and we talk about how to build features and products when scalability, resilience, and security are critical.
We get into some of the trade-offs and considerations when building those and when deciding what to build. One thing I really enjoyed from her perspective was how she thinks about the problems we're solving for our customers—and the solutions we have for those.
Hi, Karen. Welcome to the Smooth Scaling Podcast. Maybe you want to tell us a little bit about yourself—how did you get here?
Karen
That's such a big question—how does anyone get anywhere?
So, way back when, I came from a background in political science. I studied that at university and then went into management consulting for a few years. Through that, I got into some of the IT projects we were doing and started working more on these smaller iterations and improvements that customers needed for the specific platforms we’d built for them.
Over time, I got more and more familiar with that space and started to see—can we use this platform for more than just one customer, so we can benefit from the work we’ve already done? Based on that, where I was at the time, we decided to start building a self-service tool for doing surveys. Not just a general survey platform, but specifically for HR and engagement surveys, like the kind you'd know from so many different tools out there.
I was asked to head that up, based on my experience in the HR survey world. I had been a team lead for the HR project managers and worked with the IT projects. So I kind of just delved into that. That was my first role as a PO—product owner, in Scrum terms—and I really dived in.
There were so many new things to learn: how do you approach a product versus a project? What are the differences? What can we utilize from these different toolboxes? What's the newest research? What’s happening in that world? Everyone was reading Inspired and focused on the customer—and it really is all about the customer.
I found real joy in that. When you come from a project world, where your focus is on the deliveries, and diving more into the problem-solving mode—where you say, “I don’t know exactly what I’m going to deliver, but I know what problem it is”—that really lit a fire under me.
After doing that for a few years in that company, I wanted to try it in a different world, in a smaller setting. It's not that Queue-it is small-small, but it’s about the size of my previous department. That company had around 17,000 people—here, we’re just the 200 that we are.
What I really love is that we’re all focused on the same product. We're not doing a bunch of different things. No matter which department we’re in, whether we’re supporting customers, helping them with setup, or selling to them, we’re all working for the same thing.
So that's my journey to getting here. I was a product manager for a few years at Queue-it, and then I transitioned into the role as Head of Product late last year.
Jose
You mentioned the differences between project and product work. When you made that transition, was there anything that surprised you or that felt unexpected—going from focusing on a project to more of the product side?
Karen
I don't think there was anything that surprised me as such.
One of the things I often felt as a project manager was that you're hired to deliver on some-thing very specific. And if, halfway through the project, you realize that’s not actually what the client or customer needs, you can't really change the scope—because there’s a legal agreement, maybe a tender process, all these different constraints.
So you end up having to deliver what you were hired to do, not necessarily what the customer actually needs. And you always leave the project with the delivery, not the actual change that should come after. You don’t get to follow up on the problem-solving part.
That was always the unsatisfying part. So I actually think I found the missing piece, so to speak, when moving into product. It’s not that it’s easy, or that we always get it right—not at all. I’m also a big believer in failing, because that’s where we learn. But there’s a satisfaction in being able to keep hammering at that problem until you figure out what the right solution actually is.
Jose
Any specific features you’d highlight that you've helped develop at Queue-it—something that really stands out?
Karen
Well, I think the obvious answer is invite-only, our invite-only waiting rooms. That was kind of my first thing. It was more or less developed in a very early stage when I onboarded, and then it became my task to say, “Let’s get it out in the state it’s in. Let’s see how customers interact with this product, how they want to use it, and then figure out where to go from there.”
This specific problem, we talk a lot about bots and bad actors. How do we fight them? How do we keep them out of sales so that we make room for the real, valuable customers we want to let in? And invite-only was kind of an easy one to work with in that sense, because that’s the core idea: just ignore the bots, invite the people you want, and don’t let anyone else in.
Before we even put the invite-only waiting room out there, you could technically build it using different building blocks we already had in Queue-it. But we needed to make it easier for customers to make that choice.
So initially, we started with a very basic solution that a few customers still use today: just a list of long links that you distribute. It’s not super elegant for the end user, and we also realized it’s kind of difficult to work with, because you can’t easily merge those long links into email templates.
But it solved the problem in a very out-of-the-box way. You didn’t need development capabilities—just download a list and send it out. And then you’re protected at a very high level.
From there, the work became: how do we make this easier to work with? How can we help customers verify their visitors in a simpler way? That opened up a lot of other questions:
Where in the UI do you do this? How do you do it? What do you want to verify, and how? Is it a simple one-step verification? Or do we need two steps? All of these different questions that arise along the way.
It’s a product we’ve been working on continuously for the past three years, and we’re seeing more and more usage every year. That’s been an exciting journey.
And, of course, once you start interacting with customers around these things, you start learning more about how do they work with valuable visitors? Do they know who their valuable visitors are? Do they have anyone to invite? Do they have enough information to avoid just saying, “I’ll invite everyone in my email database”? Can they instead focus on where they believe there’s the highest rate of conversion?
So a lot of other projects have spun off from this, from the research we did. And I think that’s one of the interesting things, when you start lifting stones, you never know what you’re going to find.
Jose
So, we just talked about one feature you’ve been involved in—invite-only—which I know is always evolving. I’m also a big fan of that one.
Is there anything else you're working on now that’s still in those early, exploratory stages? Something that excites you, maybe even scares you a little bit? Anything you're analyzing or thinking about taking further that you can share?
Karen
At any given time, we have a lot of things in different stages. But continuing on from the invite-only discussion—one of the things we started to learn in those discussions was that over the past several years, everyone’s gotten really good at collecting behavioral data. We know how many people click on something, how many visit a certain page, and we try to use that to predict what their next step might be.
But we don’t know anything about people’s preferences. I only know what you show me—I don’t know what you don’t show me.
So, if you're buying shoes for your daughter, all I see is that you're interested in girls' shoes. I don’t know that you might also be interested in spearfishing gear or something totally unrelated. You might have a hidden interest I have no way of knowing about. So I only know what you show me and I don’t know anything else.
And that’s really one of the gaps we uncovered when talking to our customers. They know they don’t know this stuff—but they also don’t know how to get that information. Getting people to interact with something on a webpage that's already filled with options is incredibly difficult.
At the same time, when we get users into a ticket shop or an online retail environment, we want them to convert. We want to put the most relevant product in front of them and move them through the process quickly. Because the more time they have to think, the less likely they are to buy.
Now, the waiting room is a bit of a strange element in this whole ecosystem. Some people talk about it in the context of the attention economy—where we’re constantly being bombarded by everything, everywhere. But the waiting room is a unique moment in time when nothing else happens. You're just watching that little man walk.
And we know that people stay on the page because they don’t want to miss their turn.
So, even though the product is primarily intended for infrastructure protection, which does really well, it also creates this rare moment where you actually have someone’s attention.
And so one of the things we’re working on is can we use that moment for something valuable? Something that’s engaging for the visitor, something they want to interact with, and at the same time is valuable for our customers? Could we help them gather more knowledge about their visitors or help the visitors dis-cover more than just what they’re waiting for right now?
Maybe it’s not just about the ticket. Maybe there’s an option to buy a t-shirt. Maybe you can pre-order dinner. These different things.
Can we use this moment in time to educate people about other options? So that by the time they get to the main page, they’ve already made decisions like, “Yeah, I want the t-shirt,” or, “I’m going to pre-book my dinner,” because they already had that knowledge up front.
Jose
I guess they wouldn’t feel overwhelmed when they get to the page, because they’ve al-ready thought about it beforehand.
Karen
Exactly.
I remember—I was buying tickets for a festival last fall. There wasn’t a queue on, but you still had that 10-minute window to complete your purchase. And I really wanted to go, so even without a queue, I was already feeling the pressure: “I need my ticket.”
And you have this timer going down, then suddenly, I get a question: Do you want a T-shirt? And I’m like, I don’t know—what are the sizes? What does it look like?
Now I have to think about this extra decision while the timer is counting down. Sure, I could let the time run out and go back and do it over—but that’s just not the mental space you’re in at that moment.
But if I had been prepared upfront—if I knew that when I came in to buy my ticket, I’d also get the option to buy a T-shirt, and I could see what it looked like and pick a size in advance—I would’ve just made the choice right away.
And I think that can transfer into dinner options with your concert ticket, hotel booking if you're traveling, or even the bag that goes with the shoes. Basically anything.
It all becomes an upsell opportunity—if we can help people make those decisions in advance.
So that’s something that’s in a very early stage right now that we’re working on, and I think it was really born out of the conversations we had way back during invite-only.
Jose
Super interesting. Those examples really make it very concrete.
If we zoom out a little bit and look at the whole process—I'm especially curious because I’m usually more involved in the later stages, when a feature is already developed and you’re getting feedback, or it’s being released—what about the very early stages?
How do you look at signals then? I know you mentioned listening to customers, like with Invite-only and the other example you shared. But do you have any rules of thumb or usual guidelines for how you think about ideas and analyze them before deciding whether to move forward?
Karen
I think it really depends on the problem that you have found and where you found it, how you found it, and what kind of problem it is.
Sometimes a problem arises because we've put out a feature, and customers interact with it differently than we expected. That can open up a completely new avenue. Then you can say the timeline from spotting the problem to validating that it is a problem is very short—because the customer has already expressed it simply through how they’re using the product.
Then, of course, it becomes a question of cost-benefit: how difficult is it to build, what’s it going to cost us, what are the risks, and how many customers can we help by doing it? We always have to weigh those factors. Even if we had unlimited resources, we’d still need to prioritize—you can never do everything you want to do.
Sometimes you see, “Oh, I thought you were going to use this differently,” or “You’re using this in an unexpected way—what are you trying to achieve?” In those cases, the product kind of validates its own problem, and it becomes easier to say, “Okay, this is something worth supporting—let’s build something that’s fit for purpose.”
Or maybe we decide, “This isn’t a good way to interact with the product.” In that case, we take it as feedback and adjust the product behavior instead.
Then there are the ideas that are more out there—things we don’t already do. That process is longer. A customer might express, “This is something we’d like to do.”
But I usually equate that with the pony.
Jose
I know what a pony is, but what’s the context?
Karen
What do you want for your birthday? A pony. Everyone wants a pony.
But that’s not the same as being willing to feed the pony, ride the pony, build a stable for it. And at the end of the day—do you really want it? It’s a nice picture to paint.
Jose
You want the idea of the pony.
Karen
Exactly—the idea of the pony.
So there’s always this question: is it a need-to or a nice-to? And if it’s a nice-to, is it such a delighter that you'd still be willing to pay for it? Because let’s not kid ourselves, we’re also running a business.
There are steps we need to go through. One thing we usually do is work with POCs—proof of concepts—to see if we can get a customer to actually use a new feature or functionality before we commit to fully building it out. That helps us gather valuable metrics to see if it’s really solving the problem the customer had in mind.
The other method is going back to good old desk research. I’ve read so many reports, I follow what’s trending in e-commerce, what the biggest challenges are, what people are trying to solve.
That provides a different view. It’s not just about what our customers are saying they want. It’s also about what’s being discussed across the industry—whether that’s e-commerce, ticketing, or something else.
We always keep a broader view. We know our customers are reading these reports, attending conferences, hearing the same conversations. So we need to stay on top of that as well.
Industry movements are a good place to look at different opportunities, especially when they line up with real customer pain points. When those two things match—that’s usually a strong case for doing something new and different.
Jose
You mentioned finding the problem, or problems. Is it always a problem, or can it start with an opportunity? Does it have to be a problem, or could it be an opportunity you're exploring? Or am I just splitting hairs?
Karen
I don’t think you’re necessarily splitting hairs. I think there can absolutely be an opportunity we’re looking at.
But the reason it's an opportunity is usually because there’s a void, and that void is, in a sense, a problem.
Sometimes we spot the opportunity first, and then we have to dial back and figure out: What was the void? Why did this even become an opportunity in the first place?
Because when we go out and position something, and I think this is true of anything you're selling, if you're selling the promise of a better life, you also kind of have to establish what the “worse” life looks like.
Even though that’s not always fair.
Jose
No, no, no—it’s really two sides of the same coin.
Karen
Sometimes you see the opportunity before you find the problem. And sometimes you see the problem first and then have to figure out what the opportunity is.
It’s two sides of the same thing, and you need both.
If we spot a problem, we need to understand what the opportunity is. If we spot an opportunity, we need to understand what the problem was that led to it—because that’s what will guide us in scoping out the right solution for where we want to. Because that underlying problem is what ultimately needs to be fixed.
Jose
Let’s circle back to the beginning—we mentioned we’d talk a bit about product development from the perspective of scalability, resilience, and security.
You can pick one of those—scalability, resilience, or security—or we can look at them together as a set of core requirements, a kind of one side of the scale.
But how do you see the balance? How do these play into your thinking when you're evaluating problems and solutions? How do you think about the scalability and resilience site, especially here at Queue-it, where those aspects are such an important part of what we promise our customers.
Karen
I think everything I’ve said up until now is more or less generic. It could apply to any software company.
But when we get into the finer details, that’s where the nature of the company, and the product, starts to matter.
When we say to our customers, “We’re here to protect you on your busiest days,” then we have to make damn sure we can handle not just one customer’s busiest day, but 100 customers’ busiest days—all at once. That becomes a core concern.
Of course, it depends on the type of feature and what it’s supposed to do. Some things we develop are for our admin tool, which has, on average, about 3,000 users per month, never that many at one time.
So there, it becomes more about accuracy. We have to make sure the numbers we show customers are correct, that they know how to interact with the product, and that they can’t make harmful mistakes. Or if they can, that they’re not mistakes that can hurt them, that we guide them to make good decisions.
That’s really important—because if you make a mistake in your setup, or if we give you incorrect data, you might make decisions that hurt your business. We know that if you put full protection on your website using Queue-it and you get your actions or triggers wrong, you might be out of business for five minutes—which could mean an immense amount of money lost.
So it’s crucial that we get those things right and help customers make good decisions.
We’re very aware of the fact that Queue-it might be a product nearly everyone in the world has had contact with, but not everyone has seen. We're that invisible layer in between. And that makes our responsibility even more important.
Now, when it’s a feature that passes through the waiting room and the connector, scalability becomes key. It has to scale. If it doesn’t, we’re back to having that same problem we’re meant to solve.
So how do we do that well?
There are a lot of different considerations. First, we need to validate that it’s even the right thing to build. So in the very early stages, we take more control. We might test with a customer during an event where traffic is lighter or where the risk is lower. We monitor it very closely and we’re ready to pull everything if anything starts to go wrong. That’s our risk mitigation strategy at that stage.
But as we move closer to a finished product—one that we’ll release broadly—we need to know it can handle the load.
So we look carefully at the technology we’re using. We make sure we have autoscaling in place, and of course, we run extensive load testing to make sure we’re ready.
So we need to feel secure that what we’re building can handle whatever we throw at it.
We also look at how we design the technical implementation. Take the feature I mentioned earlier—where we can ask questions and collect preferences from users in the waiting room.
One thing is ensuring that the real visitor has a good experience and that we can collect their answers in a timely manner. But if the world were just full of good visitors and good people, we probably wouldn’t have the jobs we do.
There are a lot of bad actors out there. They don’t even see the UI—but what are they going to do? How will they act? Will they try to take down a waiting room by hammering an API? So how do we protect against that?
There are different approaches. Sure, we can look at things like stampede protection. But we can also think about how we design the data points we’re willing to listen to. That means building in validation, checks and balances, and thoughtful architecture.
For example, instead of writing everything directly, maybe we send everything into a message queue. That gives us a place where we can introduce a bit of latency, which also buys us time to process things safely.
So there are a lot of different considerations that go into it.
And honestly, I think that’s one of the things that attracted me to Queue-it as a place to work. The user experience is so delicate, it looks like nothing. It’s so simple on the sur-face.
But when you lift the hood and look underneath, making that simple experience possible is extremely complex. It raises so many different questions that really make you think about what’s important—and when it’s important. That’s one of the things I find super interesting.
Jose
When you were talking about scalability, I was thinking about that feature we discussed—the one where we’re collecting answers from visitors.
We talked before about how it’s relatively easy to make a survey and get users to respond. But it’s not so easy to design one that can handle millions of visitors answering at the same time.
So that scalability perspective, together with resilience, is super interesting.
Karen
And I’ve been in the survey business. I remember we had, I’m not going to name names, but we’d have maybe 50,000 people enter the platform at once—and that would be a problem.
Here at Queue-it, 50,000 is nothing. We have to handle so much more.
So then it becomes a question: How do you balance scalability? Does everything have to happen at once? What exactly needs to scale?
In this case, it’s important that every visitor can see the questions, interact with them, and that the data isn’t lost. But it’s not necessarily important that all of those answers are written to the database instantly. It’s not urgent.
Take our Traffic Insights product, for example. There, it’s really important that you can instantly see if an IP address is aggressive—because you need the ability to block it in real time. So for that, data instantaneity is critical.
But with survey responses, if it takes two minutes to update, that’s fine. The key is that the data is captured and stored reliably—not that it’s written immediately.
So it's always these different balances and trying to figure out what is actually most important. What is it actually that needs to scale? And balancing these things out.
Because scaling, again, all comes down to software costs money to run. It doesn't just run on thin air. And so how do we balance these things out? So we ensure that we have a scalable and reliable product that also runs cost efficiently.
Jose
Can you think of any examples—since you mentioned trade-offs earlier—where you were directly involved in having to make one?
Maybe a trade-off you weren’t totally happy with, but had to make anyway? Or something that sounded great in theory, but once you looked closer, there was just no way to make it scalable?
Karen
Probably! I don’t know. I think we tend to remember our successes and forget our failures, which is probably a good thing.
I’ve definitely had some weird ideas along the way, and the team has pushed back with, “This is over-engineering. This doesn’t make sense.”
Nothing specific comes to mind right now, so it probably wasn’t that important.
But I do think it highlights how important it is to have different roles on a team. You need a product manager who can dream big, who wants to reach some amazing future in a few steps. And then you need engineers to bring it back down to earth and check it against reality.
That’s where the magic happens, where you find the good solutions. I’m a firm believer that three brains think better than one. The more diversity we bring into those discussions, the better the product will be.
So yeah, I might come up with a wild idea, get UX involved, we make beautiful mockups—and then we take it to the developers, and they say, “This would take 10 months of work just to do this one small piece. Is it really that important?”
And of course, that grounds the conversation. But I still keep those ideas as future dreams. It all really comes back to team dynamics and how we work through things together.
Jose
Thank you. You did end up sharing some great examples I really appreciate that.
So, how long have you been at Queue-it now?
Karen
Three years and... two, three months.
Jose
If you think about the top one to three lessons you’ve learned while working at Queue-it, maybe also through working with our customers, what comes to mind?
Karen
When you start at a new company, even though I firmly believe that product management is a general toolbox you can apply across a lot of industries—I came from a hosted setup and moved into a cloud-based setup, and there’s a difference.
Having a better understanding of cloud technology probably would’ve helped me earlier on. But that’s part of the learning curve, right? I think I only really began to appreciate the complexity of the product once I was inside the company.
And again, I don’t think I could have known that beforehand. That’s just how it goes. But yeah, we’d all love to understand everything faster.
The whole world of bots was also completely new to me. Of course, I’d heard about bots in the news—ticket scalpers and so on—but seeing it in action, what it actually looks like on the network, I had no idea.
And that’s a constant learning process. I think you’d agree with me—every time we feel like we’ve figured them out...
Jose
It’s a constant fight.
Karen
Exactly. They slip out again.
So yeah, those are probably my top three lessons. But I don’t think I could have come in knowing more. Sure, it would always be nice if we could absorb knowledge faster, if I could just put a book under my pillow. But that’s not how the world works.
And part of what I enjoy, and still enjoy today, is that every time we start something new, there’s new knowledge to gain. New things to learn. And that’s a big part of what drives me.
Jose
Thank you. Let’s wrap up with a few rapid-fire questions, are you ready?
I’ve got four questions. Just answer whatever comes to mind, ideally short, but no pressure. Let’s try it.
For you, scalability is...?
Karen
Important.
Jose
Is there a resource, could be a book, blog, or person, that you’d recommend to listeners?
Karen
That’s a tough one, because my favorite product podcast is Danish, unfortunately. And it’s no longer running, but it has about 60 episodes.
It’s called From Agility to Beyond, and it’s been a bit of a guiding light for me. They cover different subjects, talk to Danish startups and product people.
When the whole Bandcamp thing happened, they did a full episode on that. It’s not focused on specific frameworks—it’s more like, What is Agile? and What does it look like in the real world?
For me, it helped take things from the theoretical into the practical. I got a lot of inspiration from it.
Jose
Very cool. At least our Danish listeners can check that out, or anyone who wants to learn Danish!
Karen
Right! And of course, there are the usual suspects: Lean Product Playbook, Measure What Matters, Build Trap—but I think most people already know those.
Jose
Maybe not—thanks for sharing!
What advice would you give yourself early in your career?
Karen
Don’t be afraid to change course. I think it’s the best thing I’ve done.
Jose
That’s good advice. I think we should wrap it up there, that was a really nice way to close.
Thank you for coming by.
Karen
Thank you for having me.
Jose
And that’s it for this episode of the Smooth Scaling Podcast. Thank you so much for listening. If you enjoyed it, consider subscribing and maybe share it with a friend or colleague.
If you want to send us any thoughts or feedback, write to us at smoothscaling@queue-it.com.
This podcast is researched by Joseph Thwaites, produced by Perseu Mandillo, and brought to you by Queue-it, your virtual waiting room partner.
I’m your host, Jose Quaresma. Until next time, keep it smooth, keep it scalable.
[This transcript was generated using AI and may contain errors.]