Human Insight in a Startup: Rallying Around Customer Needs is a Team Sport

About Eric

The path to working in product teams is not always straight and narrow. This is especially true of Eric Kimberlin’s diverse background, moving from the creative world into UX design, and then into product management. His journey with startup Visiting Media has generated valuable lessons along the way — including great perspective on the role of human insight in a startup where everyone wears multiple hats.

As the sole champion of human insight in his early days with the company, Eric had to push through a number of challenges to show his team the path to delivering intuitive and valuable customer experiences. 

The stories, advice, and practical wisdom Eric shared in our conversation are golden nuggets for folks working in product design and product management who want to rally their teams around customer needs. Ultimately, Eric has found this workflow to be most effective as a team sport. 

How to channel creative skills into UX design

Q. For starters, I’d love to get to know a bit about you. I understand that you have a long history as an artist and a maker. You’ve been a singer-songwriter, a metal worker, a photographer, and a designer. Where does that creative spirit come from for you? 

I don’t talk about the former lives I’ve lived very often. I think all of them were little notches on the compass pointing me towards the direction of UX design eventually. In my experience as a singer-songwriter, there are so many opportunities to get direct feedback from your users in the form of the merchandise you’re putting out, when you’re going on the road playing music, so many different aspects of that relationship with your audience and people turning out and buying tickets at the shows. 

For example, my friend Andrew and I got a big start on MySpace, back when MySpace music was in its infancy and you couldn’t add a song to your profile yet. Like that wasn’t a thing, but it became a very big thing later on down the road. We came up with a way to snag an HTML snippet of the music player and offer it out to people. People were embedding that into the customization of their profiles, which back in its heyday was a really interesting way to cast the net very wide. And although we weren’t getting paid for all these streams, the numbers were moving us up certain independent artist charts because people were putting it on the profiles and it was counting as plays every time they would refresh their profiles. It was a very interesting way to not only have it snowball in that sense, but it was really interesting feedback. Even though I wasn’t looking at it from the UX designer perspective, there were all these little takeaways that we were gleaning the entire time.

There were many little stepping stones leading up to the career shift I made in 2021. I wanted to take UX design seriously, become fluent and more well versed in the language of UX design and what that meant. And then really putting myself out there in the interviewing process. And yeah, before 2021, I hadn’t actually had a role officially with UX Design. I had just been a graphic designer from afar for many years.

Cultivate a beginner’s mindset to identify risky product assumptions

Q. Could you tell me a little bit about the products that you’re building? 

A way to describe Visiting Media is with our flagship product True Tour X. Basically, it’s an enablement tool for salespeople within the hospitality industry. So hotels, all the major names in the industry – Marriott and Hilton, just to name a couple off the top of my head – they recognize that there’s a great return on investment by being able to feel like you’re in a space without having to be there. And much like with the real estate industry, there’s a difference when you are looking at a home to buy or an Airbnb to rent. The photos of the space are nice, but some of those listings actually have a Matterport scan, the 3D model where you can move about look left and right, up and down, and that’s different. Hotels didn’t really have that in a cohesive way. Plus, there’s a lot of back and forth with brochures, PDFs, pricing guides, all these things for a given property. And so Visiting Media aims to package all of that into one beautiful digital brochure called a True Tour. And that’s one of the many products we’re building at this time. 

Ultimately, our domain extends from the experience of what the end customer sees when they receive that digital brochure to the backend and all the dashboards that the salespeople are using to set it up. Salespeople need to understand with so many different assets, how are they building this out intuitively, saving them time in their common tasks.

Q. What kind of assets are you gathering feedback on? Are we talking about live experiences, prototypes, early concepts? Are you doing interviews with your customers? 

It runs the whole gamut. First, it’s things that are live in production that we have already developed with a certain set of assumptions. To go back and change it now, depending on the thing, is a different ask. But double-checking those things that are already done is important – to not assume that there aren’t pain points that we’ve just missed over time. 

Also, we’ll test assets as granular as icons, for example. Are these icons intuitive? Do they mean what you would expect them to mean? Just because we’ve assumed they were the right icon, does it take your brain an extra couple seconds to understand without a tooltip or something like that? Do you intuitively know what we’re indicating by an icon? 

Or just the flow of a prototype in Figma. Without telling you what to click on, can you get from point A to point B without feeling frustration or pain points? So it really does run the whole gamut. 

Ideally we do more of the work in that prototype Figma phase where it hasn’t had time with developers yet. But if it has, that’s okay too.

Q. Could you tell me a story about a time when you were surprised by feedback you got in your testing? 

Yeah, it came with something that had been so set in stone for so long – it was our login screen. We have since incorporated single sign-on which has made it very simple, but it was literally just the login screen for our main application. 

People were confused about where they should be clicking the fields. We got comments like, “It’s not letting me enter my email here.” Well, it’s because the label sat above the actual text field. Internally, we overlooked it because we just knew where to go and where to click every time. 

I didn’t expect this feedback because it’s easy to fall into the trap of getting comfortable with what you know. You may miss things that would stand out to people who have never seen it before. You wear a set of lenses that keep you from recognizing something as a pain point, but once this feedback came up time and time again, we knew we needed to rethink the login design. 

I was also shocked by that because it wasn’t some major feature that we were crossing our fingers would make sense to users. It was logging into our app. It was very confusing for a while. And so that stands out as one that just on its surface seems so simple and so “well duh,” but in the moment, it was a big “aha” that only came out through asking people what they thought and felt. 

Q. I love that story. It’s so easy to take those simpler elements for granted and assume that a regular user will know what to do. But that’s why it’s that much more important to get fresh eyes on it, right? And see what’s intuitive to new users. 

One hundred percent. Yeah. That fresh perspective is everything. I would say that’s why it’s so important to test things that have already been released to production, just to double-check, “did we check all the boxes? Are there things that are popping up post-release that we just missed?” Because it’s possible to miss those things. 

To transition from UX design to product management, become a product storyteller

Q. So you spent some time doing UX design work. Then about a year ago you transitioned from UX designer to product manager. What spurred that transition? 

That was completely unique to the company I’m with and the needs internally that they had. They were looking for more folks to support the growing amount of products that we were working on, and they had a real need. I’ll be honest, I was super hesitant at first. I said, “no,” actually. They approached me again and were just like, “Look, we really think that you would have the ability to learn this additional skill set and have an opportunity to shine and bring to the table this unique angle of being a designer.”

So, I technically haven’t taken the design hat off. I’m in Figma quite often building out simplistic prototypes and keeping the grease in the gears, if you will. 

It’s been a unique opportunity to not only come at it with the goggles of UX design, but learn how to write user stories and how to write them so that the development team isn’t needing multiple back-and-forths. Hopefully it’s what they need the first time. Becoming a product storyteller in that sense has been really unique. I didn’t expect to fall in love with that as much as the design role, because in its own way those stories go to inform the design team.

Earlier on with this particular company I was yearning for more well-defined stories so that I knew what I was going to be designing. Now I’m in that seat and I can come at it with a perspective of knowing what was lacking there before.

We’re all growing in certain ways, we’re all getting better at our roles, but I’m hoping that the things that I’m working on as a product manager are everything and more that the design team needs to go and run with it.

Q. So it sounds like carrying those designer skills may help you be a better product manager.

It does, yeah. And I think the hesitancy was – I am forever plagued, like I think most people can be from time to time, with imposter syndrome and felt that enough as a designer. Now, as a PM, I think I’ve just had to grow comfortable with the fact that imposter syndrome never really goes away. And it shouldn’t, it should always be there to a degree. And if you stop feeling it, that might be a sign of something else. But it is this little force that kind of keeps me on my toes and keeps wanting to learn more, yearning to constantly get better.

How product managers can be better design partners

Q. I’m curious if there’s anything that you’ve learned as a product manager that you think would’ve been helpful to you in your designer role? 

I think having enough context for any given feature that’s being built included in the tickets is critically important. Sometimes that can be a lot of information, sometimes it doesn’t have to be as much as you think. Less can be more. Designers really just need to have the structure to push away from the harbor a little bit and go out into the ocean of creativity, but know when it’s time to come back and not float out there for too long.

It goes back to the reflection of being cut loose in certain ways earlier on to come up with features, coming back to the table, realizing that what I had designed was either less or more than what was expected. But it was no fault of my own, it was the ticket that was given to me.

So my lesson is to remember that clear and concise tickets are ultimately more efficient. Well-written, focused user stories using Gherkin formatting save time and help us to deliver features for the company, staying on the roadmap instead of having things pushed out just because of miscommunication. 

Q. So in that communication there, it sounds like there’s a certain amount of context that’s helpful for giving that creative liberty while also enough direction. What is that context? What do you think is the most powerful way to communicate between a PM and a designer in those projects? 

I think having a healthy cadence and understanding of how often you’re going to meet is important. In the design role, I never felt like anyone was necessarily breathing down my neck, but I also understood very clearly when was the next time we were going to meet to show what had been developed and worked on. 

I think it’s different for every product and every company. That cadence needs to be tweaked over time so that it’s a healthy rhythm. And then I think over time you get used to that rhythm and that expectation of “I do have questions, but I know tomorrow at noon we’re gonna be meeting anyways, so I’m not gonna pull them out of what they’re doing and derail their train of thought. I’m gonna save it so that I can just come to that meeting and spitfire the questions that I do have, get the context I feel I’m lacking, and run.” 

Share the responsibility for gathering customer feedback

Q. So, if I understand it correctly, in both of these roles, you’ve been a big champion of human insight in your organizations and helping your teammates learn about your customers. I’m curious if your approach has changed at all from when you had your designer hat on to now that you have your product manager hat on.

I would say that emphasis and desire haven’t changed for me in the product manager role. However, I have less frequency for me to be able to create the tests, digest the feedback, make the highlight reels, and build the understanding. 

For a very long time it was me as the sole full-time designer and a contractor. That was the design bandwidth for seven or eight different products. A lot of asks, a lot of different things, a lot of crossover — it was a lot. And so championing the human insight element, and also the scaling, was difficult. That’s natural to being with a startup, and it’s not to speak negatively about our situation at all. 

When we brought on our next full-time designer, we had briefly touched on the value of human insights and user tests in the interview process, but I didn’t know that they knew the UserTesting platform like the back of their hand. They had created many tests and done the thing. And so the day I realized that, I was like, “oh my gosh, I’m not the only one in the room screaming from the rafters that this is so important!” Because it’s one thing to be getting the feedback from the product owners who are then informing the product managers what we need to prioritize and what we need to focus on for releasing quarterly. But getting insights from people who have never seen and are not emotionally connected to what we’re building in any way, shape, or form was a puzzle piece not on the table for so long. And we felt it; our products reflected that. 

Now, we’re in a great growing season where testing is being done by UX designers who have since joined. The team is currently two full-time designers and a contractor, who is still here because they’re just incredible and the context they’re bringing to the table is invaluable. 

So our focus has been on teaching those newer members of the team the same value. One of those designers also came with UserTesting experience and is well-versed on the platform. We’re starting to incorporate that. And I think that that value just solidifies why we’ve chosen to stay with UserTesting and I’m super happy about that. 

Q. So it sounds like the designers own a fair bit of the testing themselves at this point. Is that fair to say? 

They do, and I think the goal is to not only have the designers knowing how to run tests, but to also get product managers incorporating that as a part of the rhythm and creating tests. Maybe not as big of a scope, but being able to understand “How do I set up the thing? What is a screener question? What do all these settings mean when I’m setting it up?” 

We’re running the marathon in segments, but we’d like to all be running it in the same direction, guided by our customers.

Q. Let’s say you’re at the point where all of your PMs and designers are trained up. How do you see each of those roles leveraging testing, either similarly or differently, to inform their work? 

That’s a great question. It’s not differently. I think we’re looking for the same things, but not everyone’s coming to the table knowing how to ask quantitative and qualitative questions. That’s a skill that takes time to learn so that you’re not setting bias in tests. That way, you don’t need to have the same person who is that testing rockstar set up every test. 

The thing is, a test could be set up by two different people hoping to achieve the same exact thing, and you’ll get two really different outcomes because of the questions that are being asked. 

I think instilling that ability for us to ask objective questions, not leading the user down a particular path but really setting the stage properly, is something I hope that our whole team can calibrate over time. 

How to socialize customer feedback among product managers

Q. Would you look at testing any differently as a PM than as a UX designer? Or is that really just a shared responsibility and a shared perspective on it?

I would lean into this shared responsibility and shared perspective. What I learned, I can remember from the seat of the UX design role doing everything: creating the highlight reels, having the summarized data from a given test, and being confused [as to] why my PMs weren’t watching the highlight reels. Like, we’d go into future meetings and I’d reference something, but they hadn’t had the time to digest it the way I had. 

So I realized quite quickly that I was sitting in this important seat to not only create the test, run the test, make sure I had the data set, but then create the highlight reel and summarize what the test meant. I really needed to refine the way I was distilling that information. Because in the beginning, those highlight reels were far too long. There’s no way I could expect them to sit down and engage for 10 minutes and go through all the users that ran through it and feel what I felt was important. I needed to learn how to distill that in a way that was just what they needed, nothing they didn’t, and move on to the next. 

I think that that just comes [from] time running tests, understanding what needs to make it in, and how much of the test you actually need to watch. I would say huge kudos to the platform and the different things that are being done with AI for sentiment analysis and helping you home in on those specific parts, because it’s a huge time saver and a huge differentiator for how we were doing it with recorded Zoom calls and Google Docs before. We weren’t walking away with the same data sets and the same insights. It’s been a huge evolution. 

Q. Could you expand a bit for me on how your sharing has evolved over time? It sounds like one element is condensing down what needs to be shared. I’m curious what else you’ve done to get your teammates on the same page. 

Within every test, there’s the Summary page. I recognized that there were a couple different fields that didn’t exist, but I kind of modified the one main text field to basically outline the assumptions that informed the questions we were asking, the findings, what was essentially the overall average from these users, what was the main takeaway from that one particular question, and what next steps need to happen. It became a version of that over time, of just marrying the assumptions, the findings, and the next steps. 

Really, that’s all that needs to be taken away from a given test, versus saying “Hey, yes, sit down, watch this 10–15 minute highlight reel, look at this summary page, and walk away with it with the same feeling, like you got to sit in my seat watching videos at 3x mode and have the same insights for a given prototype.” So, when I think back on it, I kind of wish I had been able to recognize that sooner as a way to speed up the process. 

Q. So looking ahead, it sounds like you have a growing team and a growing appetite for insight-driven development. What would you say is the next step for you and your team in that journey of incorporating more customer feedback into your process? 

Yeah, I have plugged into the platform’s community forum and am getting really engaged in the CommUnity within UserTesting. And I’ve been encouraging my teammates to do the same. There are a lot of takeaways. 

Like, Mike’s Tip Tuesdays – I think content like that can easily be overlooked or brushed aside as not as important or not applicable. But I’ve chosen to incorporate that in my weekly regimen of what I am consuming and the impact is way greater than the invested time that I’ve put into it. It’s made me a better test maker and a better digester of the information that we’re getting. 

There are so many things to glean if you’re willing to put in that little bit of effort and time. So, championing not only the use of the platform but also becoming better test makers and better test distillers.

I think the distilling is an interesting point, too. You could have someone that created a really great test. You got paired with an incredible panel of people who are willing to give you the insights. And if you just sit there and glaze over that stuff, they’re diamonds that you chose to never pick up off the ground. They’re there, archived forever, but could have impacted your product in ways that really would’ve made it more intuitive. You can’t let those fall through the sifter, you need to know when you’re looking at something valuable. 

Q. If there’s a PM or a designer out there who’s facing challenges with a culture that isn’t as accustomed to testing or gathering customer feedback, do you have any tips for how they might press on and still infuse the customer into their process? 

Yeah, I would say, even if it [your current feedback process] looks like recorded Zoom calls and Google Sheets, don’t give up. Keep whatever process you can. Even at a bare-minimum level, connect with customers. Because once you’re empowered with the tools that come with the UserTesting platform, you’ll be able to compare and contrast what that experience was like for you as a designer or a PM having the rudimentary version of it, going from things like rainbow charts and Google Docs and reviewing Zoom calls that don’t have sentiment analysis telling you “this is where pain points live, and this is where things were clicking.” 

Carry on with whatever version of human insight that you have within your company. Try to be a champion for getting better tools down the road. And when that time comes, the best advice I could give would be, don’t make the same assumption I made about everyone on the team being able to digest the test the way that you did as the maker or the one that put the reel together. Give them the distilled version of the takeaways they really need and let that speak for itself. They don’t need to know all the directions. They just need to know the starting point was here, the end address was here, but the amount of lefts and rights are kind of on the side. So learning the value of “less is more” is super important.

Photo by Paul Szewczyk on Unsplash

The opinions expressed in this publication are those of the authors. They do not necessarily reflect the opinions or views of UserTesting or its affiliates.