Reflecting on troublesome mistakes and what I’ve learned from them

Save yourself some time and learn from my mistakes.


Meghan Wenzel

2 years ago | 8 min read

Astroublesome as they can be, mistakes are prime opportunities for reflection, learning, and development. I’ve made countless mistakes at work over the years, but the following ones stand out as key learning opportunities that have made me a better researcher, team member, and partner. Save yourself some time and learn from my mistakes!

#1: Deferring to opinionated and/or OG team members figuring they must know more

I’ve worked at a variety of enterprise-focused companies where the subject matter is quite complex. From adtech to no-code, I’ve needed to take time to ramp up my understanding of the industry, the company, and the products.

During this time, I often would defer to opinionated senior team members, since I figured they must know what they’re talking about. I sometimes would accept their suggestions at face value, since they were so confident, forceful, and self-assured in their delivery. However, I soon realized this was ill-advised.

For example, when I had just started a new job, my PM jumped right in and asked for my help with some research. He decisively said we needed to research a certain topic and should set up sessions right away. The PM had a clear vision for the research, but he didn’t provide any context around the product or feature overall. Frazzled and wanting to provide value, I decided to trust his vision and I jumped right in.

After the quick study was done though, I realized it was too granular, and we should’ve taken a slower and more methodical approach. I realized I should have pushed back on him to slow down the schedule and invited Design to help develop the research plan with us.

What I learned:

We were all working remotely, and it can be challenging to join a brand new team, get up to speed, and get a feel for each team member’s personality and working style.

I should have slowed things down and asked for more background and contextual information. I should’ve asked the PM or Designers to give me a detailed walkthrough the product and feature in question, instead of simply deferring to the PM’s vision for the research.

I should have had the PM step back and explain what he was trying to learn and why, as well as prompting him to explicitly explain his reasoning around his suggested research approach. Then I should’ve taken time to process the larger context and overall goals and drawn on my research expertise to develop a more thoughtful approach.

#2: Getting pulled in last minute to support a study with a team completely unfamiliar with UX

After switching internal teams, I was worked with folks less familiar with UX. I was assigned to one project team, but other project teams were curious to have research support as well. A newer PM was in charge, and he asked if I could provide some last-minute research support for an upcoming study. Wanting to be helpful and teach others about research, I agreed.

The study happened to be collecting feedback on a questionnaire feature within a complicated insurance product. I set up a time for the PM to give be background context on the product. He walked me through the feature we wanted to collect feedback on, we discussed the goals of the study, and I reviewed the research plan he’d put together.

He already had sessions set up with clients for the next day, so we ran the sessions, he synthesized the findings, and I reviewed them. Only after the sessions ended though did I realize that we were only testing one of four parts of the overall product. Since the four parts heavily interacted with each other, we really needed to test them together for users to get a holistic understanding.

What I learned:

Now, whenever I join projects I request a rather extensive high-level overview of the full product and what we’re trying to achieve, not just the small section we may be focused on. I need to understand the larger project and goals, so I can provide adequate guidance and recommendations.

I’ve also realized that I need to set boundaries and make tough decisions around how impactful a project will be and how my time is best spent. Getting pulled into a project last minute is rarely a good use of my time. Instead, I need to be involved upfront with sufficient time to understand the context and develop a worthwhile research approach. Otherwise, it risks being a poor use of everyone’s time.

Additionally, for complicated, industry-specific products, it’s helpful to have an SME join the research sessions to provide support and probe on relevant industry topics. Since this is beyond my knowledge, they can ask relevant subject-specific questions.

#3: Spending a few weeks creating a comprehensive Pendo report…without getting stakeholder input

When I first started at a small data startup, I was the first UX Researcher. I quickly requested Pendo, so I could understand more about how people were using our products. We implemented Pendo, and I was excited to uncover some interesting insights to share with Design, Product, Engineering, Sales, and Customer Success.

There was tons of data and different ways to slice and dice it, but it wasn’t immediately clear which information would be valuable to the teams. I thought about what each team was focused on, and I spent a few weeks heads down with the data to compile a rich report around the most and least used features, the most and least active clients, key conversion funnels, drop off points, user cohorts, and more.

Finally, my masterpiece was finished. I shared it with the teams, who seemed interested, but then nothing happened. The data wasn’t particularly actionable and there weren’t clear next steps. The teams weren’t bought in and involved in the project since I hadn’t involved them along the way.

I quickly realized that I should’ve involved my stakeholders at the beginning to figure out their specific needs and open questions. Then I could work backwards from their core questions to see how I might answer them using Pendo.

What I learned:

After the report fell flat, I set up working sessions with each team to understand their unique goals and questions. What questions were they trying to answer? What were their challenges? What information did they wish they had?

After discussing their high-level questions, I walked through Pendo to show what types of data we collected. The walkthrough helped spark ideas, and we brainstormed what information would be useful.

Working with each of the teams allowed them to share their functional and contextual knowledge and highlight which data was actually useful and actionable. Additionally, it made them much more engaged and bought into the project.

From there, I developed a weekly report of the key metrics and data the teams wanted. I shared it each week and iteratively improved it based on continuous feedback and suggestions from the teams.

#4: Doing discovery work with the wrong audience

For one project, we were adding brand new role-based access control (RBAC) functionality into a relatively new feature. We didn’t know much about what the RBAC should entail, so we decided to do some exploratory interviews with current users. I put together a participatory design exercise and was quite pleased with myself.

I reached out to Account Managers and the Partnerships team, asking them to help me find project admins within our platform who set up and permission projects. I set up sessions with the people they connected me with, but the sessions fell flat. It turned out the people I was speaking with hadn’t thought about RBAC functionality in this context before, and they didn’t really have expectations or relevant experience around it.

I realized that since the functionality didn’t exist yet, project admins weren’t the best people to speak with. Instead I needed to talk to higher level system admins, who did have relevant knowledge and experience.

What I learned:

Recruiting the right people can be tough. Design and I thought project admins who set up and manage permissions within a project would be the right people to talk to, but we should’ve consulted with internal folks who had more first-hand knowledge around this.

It’s helpful to provide as many detailed recruitment criteria as possible. For a recruit like this, it could’ve been helpful to set up a screener to ensure the people I was talking with had relevant experience. Additionally, piloting the study with 1–2 people before completing the full recruit could’ve been helpful, so we could validate that we were reaching out to the right people.

In the end, we pivoted and did competitive research with system admins. These folks had extensive experience with RBAC and had strong opinions and insight. I invited them screen share and walk through a variety of tools’ RBAC, providing their commentary on what does and doesn’t work in each. From there, we were able to glean core functionality to include in our MVP.

#5: Failing to provide my intern enough structured support

To prepare for my summer intern, I worked with Design to determine which projects she should work on. We paired her with us on a variety of projects, but we wanted her to lead one project on her own as well. We decided that the Design and Research interns could lead a permissions project together. Once they started, it was clear they were very bright, and they were eager to own a project end to end.

The interns really enjoyed working together, and they’d set up extensive working sessions together. I had regular check-ins with my intern, but it took a little time for me to realize that the permissions project was much more complicated and extensive than we’d first realized.

Over time we realized that the interns might not be working very efficiently. They were getting caught up in the weeds and didn’t know how to properly scope and narrow down the project’s focus to be more manageable.

I realized that no matter how bright and motivated they were, they still needed more hands-on professional and tactical guidance. They’d never scoped or worked on such a complicated project before, and the Lead Designer and I should’ve provided more granular and structured guidance.

What I learned:

Before we assigned the project to the interns, we should’ve met with more technical folks to more deeply understand and size the project. Had we realized it was such a big project initially, we would’ve carved out a smaller, more manageable assignment for the summer.

Once we realized the project was so complex, we worked with them to scope a reasonable amount of work for them to accomplish within the summer. They were keen on continuing the full project, but we had to push back and create more reasonable expectations.

Taking time to acknowledge and reflect on your mistakes is an excellent opportunity to learn and improve. Some of the most important lessons I’ve learned over the years have come from reflecting on the mistakes I’ve made. I’ve even created a document where I jot down successes, mistakes, and learnings.

I’ve realized that it’s important to have the courage to slow down, take a step back, and ask team members for additional information, walkthroughs, and context.

It’s important to reflect on that’s the most valuable use of your time, and be willing to say no when you’re pulled in too late on a project. It’s important to constantly engage and work with relevant stakeholders, so your research is as valuable and actionable as possible.

It’s important to spend time upfront determining who has the necessary knowledge and experience to answer your research questions, as it might not be who you initially think. And finally, it’s important to constantly support, mentor, and actively develop those who you’re managing.

Thinking back on your own experiences, what can you learn from your mistakes?


Created by

Meghan Wenzel

As a User Researcher and Strategist, I help companies solve the right problems and build more relevant, efficient, and intuitive products. I started my UX career at a Fortune 500 company, and I've since helped established the research practice at three B2B startups. I'm currently a Senior User Researcher at Unqork, the leading enterprise no code platform.







Related Articles