Our colleague, Monica Obogeanu, product manager at Mozaic Labs, sat down with Thomas to talk about his recent experience at Buffer. After joining Buffer as a researcher and doing plenty of customer development work, Thomas transitioned to the onboarding team, where he does various research and UX tasks to improve the first-time experience of Buffer customers.

Thomas shares about the way they work and different roles at Buffer. Read on for interesting learnings along the way, useful tools for a product manager, and much more. This is the first part of the interview. Read here the second part.

MO: Tell us about your research process – how do you come up with hypotheses and how do you choose what to work on?

TD: We get many improvement signals on a daily basis, so we have to be really disciplined about what we act on. Signals come from many sources, including our support team, marketing team, data team and lots of other places, too. One of the first questions we like to ask ourselves when we get a signal is “How many customers is this affecting?”. This helps us to zoom out and use our data to see where we can make the biggest impact with the limited resources that we have. This isn’t to say that we don’t care about other signals though. It just helps us to prioritise so we are helping as many people as we can.

Once we have prioritised as a team we then feel much more comfortable moving forward with research and solutions.

Another big factor influencing our decisions here is vision. Sometimes I might see a pattern emerging in my research and I get very excited and want to dive head first into solution mode. I have to pull myself back and think “is this going to align with Buffer’s vision for this quarter?”. So there are a few different factors that influence our product decisions here.

MO: How do you have that vision put in place?

TD: That vision comes from Joel, Leo and the other caretakers at Buffer with lots of ongoing context gathering from the whole team. It outlines our mission as a company and the impact that they are excited about making on the world. We use the OKR (Objectives and Key Results) way of setting targets for ourselves at the moment. At the beginning of every quarter, we set targets for ourselves, using this framework. The OKRs are influenced by the overall vision. This way, the many teams we have now are all working towards a common goal, despite the fact that they might be focusing on lots of different features and challenges.

MO: Once you decide to research an idea more, how do you do quantitative vs. qualitative research?

TD: I mainly do qualitative research, but one of the transitions we’ve been making in the last few months is really embracing the data side of things more and working more closely with our fantastic data team.

The whole company has access to a tool called Looker. Is an incredibly powerful analysis tool where we can basically track every single action that somebody makes on our app and we use it to track and measure anything and everything. In the last two years, the data team has done a brilliant job-making data very accessible for members of the team who don’t necessarily have an in-depth data or programming background (like me!).

MO: Do you also look to validate the solution with customers? Show them mock-ups, for example?

TD: If we get to that stage where we do believe it’s a problem that we need to work on, we start thinking about solutions. Before that, on the product team, we do a lot of customer development. Above all, we want to understand the problem that people are facing in their lives. That’s our biggest priority.

We try to stay away from jumping to solutions too quickly and mocking up a design or a prototype. We often find that if we speak to enough customers, they end up designing the product themselves in a way. We start to see lots of very interesting patterns, with customers using the same words and phrases. Those often end up being the words and the phrases in our new features, so they’re basically writing the copy for us too! Once we’re comfortable with the solutions, then we go to the next stage of running customers past simple prototypes – to keep things really lean so we can pivot.

We try to make a very basic prototype, which might be just an image or a simple design of what the feature might look like, using slideshows or InVision. Invision is a really cool tool where designers we can create a user experience that almost replicates an interactive app. If we validate a prototype and get past this stage, we become more comfortable investing engineering time into it, and we’ll build a basic MVP. At that point, we might just speak to 5 customers rather than 10 or 15, like we would have before at the earlier stage, and just look at it from the usability side of things.

Now the challenge is – does our solution make sense? This is where I believe the researcher mindset changes from thorough problem analysis to usability, and our customers getting from A to B without any roadblocks, which is slightly different. Then again, at this point, we still might find that sometimes, we pivot again due to customers not receiving enough value from our solution.

If a product reaches our high bar of validation after customer development and user testing, we’ll often invite customers to use an MVP as part of a beta program or controlled roll out. Sometimes it’ll be months before we are comfortable launching it to everyone and being careful like this helps us to measure data and conduct more research to make sure that it’s helping customers achieve success in their lives.

Does adoption of the feature mean that they’re retained for longer or does it mean that they’re more likely to become paying customers? Depending on what data usage shows, and how this new feature or product aligns with the vision, we make the decision if we launch it officially. It can be quite a big process covering every team including support, marketing, product, engineering, design, research, and data.

MO: You mentioned 10-15 customers during the customer discovery. Is that a ballpark where you start to see patterns?

TD: Yes, exactly, that’s kind of our random ballpark at the moment although we tend to stop conducting interviews once we start to hear the same things over and over again.

MO: Is there something you learned that was unexpected while doing research – quantitative or qualitative?

TD: Yes, let me think of a specific example because there are always many interesting things going on. One that I was really surprised by, was the fact that I’ve always looked at competitors as other social media tools, and up until recently I had never used the jobs-to-be-done framework. I’m new to this and I’m learning a lot from it so far. I was speaking to one of the designers on the team after short course I took about two weeks ago. We came to the conclusion that we weren’t competing with Hootsuite or Sprout Social and were actually competing with Google Spreadsheets for this feature. We found that lots of our customers were using Google Spreadsheets as a workaround or as a hack to solving a problem that they had with Buffer. And it made us really think about the job they were hiring us for.

Stay tuned for the second part of this interview to learn more about insights from product development, tools, and understanding your customers from Thomas Dunn, Product Research at Buffer.