Startup UX Research
A little over a year ago, I started as the first and only UX researcher at a cybersecurity startup called Barkly. I came on board part-time in January 2016 when the company was around 25 people and the product wasn’t even yet in beta, let alone launched. It’s unusual for a startup to care at all about having a full-time researcher and I was intrigued that they wanted to hire my position on the team.
Without a ton of users to research would I really have anything to do?
Not everyone had worked with a researcher before, and I was brought to Barkly by a designer I used to work with at HubSpot. He and I knew how things were done at HubSpot, but an early stage startup doesn’t have the same needs or challenges as a global public company. I found things that worked at HubSpot didn’t work at Barkly, and vice versa. I also realized I had the opportunity to build the research role the way I wanted, not swimming upstream against ingrained practices that are hard to undo.
And even though we had no product, my fears were unfounded because there was plenty for me to do. Fast forward a year later, we have grown as a company, released a product, and learned a ton along the way. A lot happened in the last 13 months. I had a hand in getting us there and wanted to share what I did in my first year as the only researcher at a startup.
1. Get to know the team
Research requires collaboration across many different teams and timelines. I focused my first few months just learning the business. I was going on customer visits with the exec team, eating lunch with the engineers, Slacking with marketing, and speaking up with my opinion at meetings. The seemingly off-hand conversations I had allowed me to share what I was learning, see what others were working on, hear their opinions, and spur debates, all of which were important in synthesizing and spreading what I was learning across the company. It also allowed everyone to feel comfortable with me, and vice versa. With comfort came trust and the ability to discuss and debate ideas.
It’s not always easy and you may not feel like you’re making actionable progress, but when people come to you for your opinion and include you in decision-making conversations because of your research, you’ll know it was worth it. Cultivating relationships with the teams you’re going to be working with takes time but it is the single most important thing that you’ll need to be successful.
Takeaway: Spend the time getting to know the team in and out of work to build trust and communication.
2. Score some quick wins
When people hear UX research, they typically think of usability testing. And, fresh out of HubSpot, that is what I was used to doing. The Barkly team was talking with customers but no one really owned the feedback loop, and I knew it would be an easy win to ensure usability testing was part of the development process. Our designer was happy he no longer had to set up and run the tests (now he just had to sit in and listen), and my boss was happy that feedback was formally being incorporated into design.
I wanted the learnings to be available to anyone at the company so I set up a usability testing calendar so that anyone internally could know when calls were happening, and I recorded all the calls and notes and put them on the company wiki. I sent emails to execs and stakeholders after testing, documenting what we did and what we learned. The result was that the learnings got shared, I got visibility across teams, and my co-workers could quickly assign value to my role.
Takeaway: Start with some quick wins to gain credibility.
3. Act on your findings
By my second month I was getting into the swing of things and wanted to pool my growing knowledge with the team’s. Before I got started, the cofounders had done a bunch of their own research into the IT world (our market), and it was really helpful to have that base to jump in and learn from. But, based on what I was learning from my own interviews, I felt like there was a slight disconnect between who they had been interviewing (execs) versus who would actually be using our product (IT professionals). Each were important parts of the purchasing process, but I wanted to make sure we were building for the people who would actually be using Barkly, not just signing the checks.
To discuss, I planned a small workshop and invited key team members (execs, product, marketing, etc) to participate in creating user personas. We used our existing user interview notes as the basis for persona creation to make sure everything was grounded in real data. The outcome was that we got to talk as a team and discuss the different roles, goals, challenges and responsibilities of IT pros. This got us speaking the same language and helped us realize what questions we still had. It also cleared the path for focusing more on our “Doer” persona rather than our “Exec” persona in product and marketing, which we didn’t realize were misaligned until after the exercise.
Looking back a year later, we’ve made great strides in understanding the challenges and needs of each persona and are still continuously updating what we’re learning. The personas have kept necessary guide rails on product and marketing efforts to make sure we’re laser-focused on our actual users. Most importantly, they got everyone using the same language to discuss our users and their challenges.
Here’s some of the example materials I used to run the workshop:
Takeaway: Don’t be afraid to recalibrate as a group when you aren’t sure everyone is on the same page. Speaking the same language is half the battle.
4. Institute the right tools for the job
When I joined Barkly, I was lucky that a lot of tools were already in place for the team. Those were things like Slack, Jira, Confluence, HubSpot, Segment, and Amplitude. I was used to using most of these from my time at HubSpot, but I knew there was opportunity to improve how we learn from and engage with customers within the context of the product itself. Knowing that I wanted a way to talk with customers and learn from what they were doing, I made it my mission to implement Intercom and FullStory in the product by the time we were in beta. We started some free trials so the team could test each out and we were instantly hooked by the amount of helpful information gained from each tool.
We started using Intercom to automatically send messages in the product during onboarding, when users activated, and of course, when they had issues. Our support started to become something of a standout feature for us as a product because we learned that lots of our users tend to be on small teams who don’t have a lot of time or support in their daily jobs. Plus they were used to less-than stellar support from other vendors and pleasantly surprised by our quick and helpful responses. The fact that they could talk to us in real time made the difference to them when they had a question or issue. Intercom also allowed us to have one place for customer interactions, to see individual usage stats, and to use to segment for user research recruiting.
We use FullStory as the DVR of all user interactions in our product and implemented GameFilm Fridays to watch for issues users weren’t reporting on their own. And, seriously, there were a ton. As a new product in beta, this was immensely helpful in understanding the way users were interacting with a brand new product for the first time. It spawned a second (and third) version of onboarding and let us make changes to microcopy and links that might not have been thought of otherwise.
Bonus Tool: I’m now testing out research tool NomNom to help me organize my notes and research themes into one searchable place for the whole company.
Takeaway: The right tools for the job can transform how your team works.
5. Integrate new frameworks & engage the team
As I became more ingrained into the team, we gained more team members, and I learned more about our customers. It became clear to me that there was a huge opportunity to use a new kind of research framework I had never tried before. I knew about jobs to be done from my time at HubSpot, but only as a concept, not as an applied piece of work. I started reading more about it and knew it would take time to educate my team before we could apply it to our business (luckily, Competing Against Luck came out around the same time). I also knew I had to wait until we had moved from beta into general release software so I could talk to people who had paid money for our software before I could do a true JTBD interview. I spent time educating the team through conversations, attended JTBD meetups with co-workers, spoke with Bob Moesta from the Re-wired Group (thanks Bob!), and sent around the book/articles to get them on board. As my boss came around and was engaged, I knew it was a go.
The team started sitting in on JTBD calls I was running with every new customer and they were rallying around the emerging patterns we were starting to see. I ran a workshop to collate our learnings and come up with the initial job we saw customers hiring Barkly to do for them. The emotional and situational pushes and pulls of our users spurred new copy all over our website and marketing materials, transformed how we think about why we are building the product, and gave us another common language to use when speaking about our users.
Side note: We are taking our initial learnings with a grain of salt as the job we came up with is very clearly spurred from the needs of our earliest customers. It will change over time as we evolve as a company. There’s plenty more to say on the topic of startup jobs vs established jobs that I want to tackle in a follow up post.
Here are some ways I organized our JTBD workshop and notes:
Takeaway: When introducing new frameworks, engage the entire team with the research so they’re bought in and learning with you. And, from the biased perspective of a JTBD fangirl, the jobs to be done framework can transform about how you think of your entire business.
I’m still going!
This list is just a smattering of the things I’ve done in the past year to get research off the ground. Other hits this year include introducing growth marketing concepts, a re-branding project, running paid social ads with JTBD language, closed lost research, studying competitor jobs, and lots of surveys.
A year into working here, we’ve made a ton of strides. We don’t yet have the need for things I ran at HubSpot like a beta program or a ton of usability testing. And I think that’s great! If we didn’t need it, I didn’t do it. Startup research and making the job what I want has helped me re-frame how I look at my role and I’m so happy that Barkly has given me the breathing room and trust to try new things.
Have any feedback or things you’ve done as a startup UX researcher? I’d love to know what you’ve done!
