Product Engineering at Terra API: Stalk your users

1. Turn new hires into super users

• Having new hires at Terra go through an onboarding process as first-time users gives us an ultra-high resolution of our product journey. It allows the team to observe every step and friction point, uncovering opportunities for improvement.

• This exercise helps new hires maintain the perspective of a first-time user, which the company hopes will continue to inform their work.

2. "Stalk" your most important user

• Rather than trying to cater to multiple stakeholders or personas, Terra decided to deeply study a single, carefully selected user.

• They studied call transcripts, emails, social media activities and more to understand this user in-depth.

• This laser-focus approach led to faster alignment within the team, more targeted messaging and product development, and quicker iteration cycles.

3. Go beyond asking for feedback

• When users requested updates to Terra's documentation, the team initially jumped to implement the changes without questioning the underlying issue.

• By repeatedly asking "why" and digging deeper, they discovered the real problem was users' confusion about the product's functionality, not just outdated documentation.

• The key is to avoid asking users for opinions or hypothetical feedback, and instead observe their actual behaviors and tasks to uncover opportunities for innovation.

In the latest podcast, our product engineer Vanessa breaks down how to get inside your users' heads to build products that people love. 

For the podcast: Youtube

Turn new hires into super users

Hi, everyone. Thank you so much for joining today and for listening in. Thanks for having me as well. I'm going to briefly introduce myself. So I'm I'm a product engineer at Terra API. And what I do is I speak to I try to understand users. I observe them. And then I try to get back to my team and align on what shall we build next and how do we really make sure that whatever we're building, whatever we're putting out there in the world is irresistible. So I'm very excited to be speaking about something that at first might seem a little bit obvious, but it's actually really hard to get right. It's truly understanding your users. So I've been a design researcher before.

I worked hand- in- hand with clinicians, patients, nurses to identify what do they need and how do we make this come to life. it's actually not as easy as it Why is it important to truly understand your users? Unless you only want to sell to yourself, you actually have to get out there and make sure what you're building is going into the right direction. Now, quick reality check. We as humans, we're kind of naturally just biased, right? It's how our brain is And especially as a founder, as someone who is trying to build irresistible products, you have to double check yourself. And you might think I'm a super empathetic person. I can put myself into the shoes of a I am that person who understands users. It's actually impossible.

So today, I want to speak about mainly three things. I want to speak about whether it's possible to become your own user and draw learnings from that. want to speak about why it's super important to be extremely obsessed with just one user. And I want to speak about why you should never listen to your So let me go to the next slide. And let's get started. I want to start with brain science, because why not? Everyone loves brain science. Why are we so biased to begin with? Why is it difficult for us as to really put ourselves into the shoes of someone else and try to understand things from their standpoint? So there is a region in the brain called the default mode network.

It's a region in the brain that is active when, let's say, you're daydreaming, when you're zoning out, when you're not really focused on one specific task. So you can imagine that happens quite often throughout the day. And what really happens is introspection. So that part of your brain actually draws from all your memories, your learnings, your experiences throughout the time. And it makes sense from the information without you having any control over it. it sounds useful, right? Because what happens is when you have to make decisions, when you have to make decisions fast and you need judgment, it's kind of like a mental shortcut. allows you to draw from your memories and experiences and make those decisions. But there is also a downside to it because it means it's something that you cannot unlearn.

You cannot just toggle it off. Even if you try to emphasize what it uses, it's almost impossible to turn it off completely. So this is how our brains are And then I remember I was asking myself, is it really impossible to become your own user? Because becoming your own user has so many benefits, right? It means you can draw from your own learnings, you can experiment faster. You kind of develop that product sense that you can trust and you develop that gut instinct that leads your decisions. So here's something interesting that happened at A couple of months ago, I was looking at data. I was looking at some metrics that we track from our platform. So we are a developer tool. We enable developers and companies to connect whatever wearable sensor app that we port to their app.

So they get the data from us, powered through to their app. So I looked at the onboarding metrics. I was looking at, well, why does it take users longer than expected to get onboarded and get started with our product? And I think your first intuition is to try to make sense of that data. And you start with a lot of assumptions. You look at the data from different angles and you try to question whether it's significant. Is there enough data to even draw conclusions? And the main point is, if you just look at quantitative data, there is no context. It's guesswork. There is no nuance into that. So then the next thing I was thinking is, well, obviously I need to speak to users to understand what's going on.

How can we speed up the process of them onboarding? But is there anything else we can do? And the next thing that happened was we made it our goal that every single new hire at Terra API is becoming our super user. Well, the benefit I think is quite obvious because first of all, it's someone that you literally hired to do the job. So you can ask them as many questions as you want. But also it's interesting because they have no idea or not enough idea of how your product is intended to work. So they're like a sponge. They're like a user who's never seen your product before. So what happened is every new hire, the first day they joined Terra, they don't get a demo of what we're doing.

We don't tell them, hey, here's the presentation. This is how the product is intended to work. are all the details, all the slides, whatnot. The first thing they get to do is actually a task which is use our product and you don't get help. And that's not just for developers, by the way, right? So we had this scenario where a new designer was joining. He's actually here in the room today. And he went through the same task as well. So we tell them, okay, here, sign up, observe everything you'redoing and tell me every single friction point. Try to connect different wearables, sensors to your app and make sense of that data. And bear in mind that person has never really fully used our product. And we sit next to them and we don't help them.

So their first onboarding task essentially is actually a real life user testing. We sit next to them and the benefit here is you get into the details, into the nitty gritty. You can see every single click. You can see every single page swipe. And more interestingly, you see when they switch to Google or they switch to chat GPT and they start typing in different questions when they get lost. And you might think, well, what am I gonna do with all that detail, right? If I wanna build a great product, why would I care about these little things? Why would I care about clicks? In reality, I believe personally innovation and opportunities are found in small and mundane things at times.

But if you notice that someone has to do a lot of extra work just to get where they wanna get to, that could be something you can automate. That could be something that could be more seamless. So doing this exercise with every single new hire actually gets us an ultra high resolution of how our product is actually working. And I find that really interesting because you might think,well I can do the same with my other users, But trust me, there are very little users and customers out there who are willing to debrief with you for four hours, right? Their time is limited and they might not pay attention to those small little details. But if you can sit next to them and if you can debrief with them afterwards, you get that high resolution image of your product.

Second benefit, well, I was talking about how we as humans are super biased, right? Even if we try, it's kind of But if you start off with that my belief is that you kind of prime your brain into thinking this is how I initially felt as a customer, as a So every new hire that starts at even throughout the time, we hope that they remember this feeling of being a first time user and to be very observant of small details. So that's the first thing, become your own user. Well, obviously you cannot just rely on your new hires to wait for and to uncover product opportunities. So at some point, yes, you do need to speak to Now, something that I personally find very interesting is if you have the problem of, okay, where do I go next?

"Stalk" your most important user

What product shall I build? What feature shall I build next? The general advice out there seems to be, okay, look at the market, look at the try to identify the biggest chunk of the pie, essentially. Speak to different stakeholders, speak to different personas, and just have kind of like a bird's eye view on the things to identify that you're really looking at the right opportunities to And I think one of the most counterintuitive things we did at Terra API is just to do the opposite, right? So we kind of disregarded that part, and I'll give you an example. A couple of months ago, we were breaking into a new market segment, and we did the We became super obsessed about just one person.

So we didn't look at 10 different stakeholders, and we looked at all the potential buyers that would be interested in our product. We studied one person in detail. I almost want to say we stalked them. So what happened was we narrowed down the criteria. We were very, very selective in terms of who shall we study to identify what we should build next, how we should do our messaging, and how should we put the product out into the world. So we studied that person because we were very confident based on these criteria, very selective criteria, that whoever is targeted by what we put out there is matching that person, and they will be interested in us as well. So what did we do practically? We dissected every single piece ofinformation we got from that person.

So first of all, we were confident they were the right fit because they already paid for us. They were from the right niche market segment that we wanted to and they kept using our product, right? So that's how we knew. Then we looked at all the call transcripts. We analyzed the call transcripts. We went through the emails. We went through the messages. We stalked them on social media. We went through their likes, theircomments their reposts, their re- shares, what articles they consume, and we look at the language they speak. So we looked at, okay, what words do they use? How do they present themselves? And what might they also do outside of work? And for someone who's trying to break into a new market, you might say, why are you doing all this?

And also, are you not taking a lot of losses? Are you not ignoring other opportunities because there are other potential buyers out there? The thing that I think we got from this is speed and alignment, right? Because we only focus on one particular user. It was so easy for the entire team to get momentum. Every single person knew that was the person we're gonna study. So everyone was kind of going to the same direction, and our messaging, our product, what we built, it was basically not diluted at all because we didn't have to compromise. There was not a second opinion from a second person that we had to take into account as well. So that was the first thing.

If you think about that, if you just have to study one person in you don't have to spend weeks on it, right? You basically just have one laser focus. And what happens is you act very quick on that data that you get. So you're able to bring out a product, a marketing website, messaging, that is laser focused in minimum amount of time. And that speeds up your learning as well. So you will know right away whether what you've put out there actually works. And chances are, even though you've built this product for just one person, there are at least five to 10 to 20 people out there who quite resonate with it as well. And then it accelerates your entire learning process through multiple iterations. So that's kind of what we did when we broke into the new market.

Go beyond asking for feedback

Now, the other thing that I want to speak about finally is, all that put aside, how do you actually speak to users practically? How do you get to the core of the things, right? Like how do you make sure they actually tell you what they need or how do you identify that? then why shouldn't you listen to them in the end? that one is quite an interesting one. also one of the more counterintuitive things that we do at I remember when I first joined Terra, saw a lot of requests coming in from customers. And those requests were quite interesting. So the basic messaging was, hey, please update your documentation. It's not updated. It's outdated, right?

Very straightforward. I think a lot of developer tools might have this issue. that was months ago. And the first thing we did was, well, that's such an obvious request. We're gonna drill down into it straight away. we went in our documentation, we look at the different sections, we started dissecting it, we started thinking, this needs updating, this needs updating. Here we need to place an exclamation mark. Here we should make an out call. No one should pass this section without seeing it. So we were completely stuck with documentation. And to be honest, it makes sense, right? If you're a developer, the first thing you think of is, well, the docs are outdated. Obviously you need to update them. I don't think anyone would really question that user request. It's kind of natural.

There is a thing that you miss out if you just go into that route. So the thing is, we didn't really question why did they have to read the documentation to begin with. And I agree, they're developers. Yes, it makes sense. But what was the underlying issue here, right? So when we then started inquiring, what was your actual goal? What did you do? Why did you have to go into the documentation? There was a little bit more insight here. And the point is, it can feel almost funny to repeatedly ask your users why. Why is that a problem to you? Because at some point they're just like, well, it doesn't work, that's why. And it's quite, I would say, it's quite an art to lead the conversation in away that opens up other avenues, that makes the conversation even more personal and almost vulnerable.

Because you wanna understand why are they getting angry? What were they trying to And it turns out for that user in particular, well, what they did was, they were trying to implement something in their backend. It didn't work as And now they were confused whether it was their issue, whether it was them who did a or whether it was us. So then, because the product, because it wasn't obvious from our product itself what was going on, they were trying to take the other route and go into the instructions, go into the documentations, and try to find that information. So repeatedly asking why, and I usually say you have to ask at least three times why to get to the core problem, can feel a little bit unfamiliar, but it's really, really helpful.

And to summarize some of my learnings in the past years, but especially at think when you speak to users with a goal to how do I make my product irresistible? What shall I build next? There are three general tips, or three things that I personally think of. The first one being, never ask your users about opinions. Don't ask them, how do you like it? What do you think about this feature? Do you think you will use this feature in the future? It's the most obvious route to take, because you expect direct answers, but those answers are super vague, and they're not grounded in any facts. So what you want to do instead is, you want to ask them something where they can't lie about. Something that gives you a robust answer.

For example, instead you could ask, okay, in the last seven days, tell me on which day you were working the longest. And tell me exactly what you were doing that day. Like, what were the main tasks that you did? And how much time do you spend on each task? And what was the most annoying thing about that task? So you really want to understand how they walk through live, and how they walk through work, in case it's in a B2B context. And then you'll understand their opinions. Now, the second thing is, don't accept vagueness. I've mentioned it before, but don't accept vagueness. Let's say you have a new product idea, and you want to validate whether it's solving an actual problem that your users are facing.

And they might say something like, yes, it's definitely a big problem. It's definitely something I'm struggling with, and I would love a solution for that. Again, it's an opinion, kind of and you want to take it back to some grounded answers. You might want to ask them, okay, if it's such a big problem, have you ever looked for a Have you ever tried to solve your problem, actually? And what makes that problem so dramatic for you? And then lastly, never ask hypothetical questions. All the what's. Would you buy my product if it was a little bit Would you buy my product if there were more features? you buy my product if this? You kind of want to avoid that situation, because you kind of force your users to take on your work, which is identifying the opportunities.

They're really good at describing what they do throughout their lives, throughout their work, but it's really difficult for them, within one minute, to give you ananswer that they have to roughly analyze. And it's generally probably better to just observe them and ask them which tasks they were doing at what time and how much effort they had to spend on these things. So to summarize, and I'll leave you with that, each struggle of your user, I is not really a complaint, it's actually a and it's an opportunity for you to So observe the little things, observe the mundane things, and take it from the details.