Episode Transcript
[00:00:00] Speaker A: Foreign to start us off young by telling us a little bit about you and your journey to founding Insight and where you guys are at now.
[00:00:14] Speaker B: Oh, wow.
Me so. Jesus. I come from about 25 years of design, product design, branding, marketing and whatnot experience. First decade I spent across agencies, than a decade across tech and startups, mostly early stage startups. It was kind of like my sweet spot for the last, I would say between 2014 and 2024. Exactly a decade. Jesus. Yeah. So, you know, Insight is essentially, I like to joke around typically when I talk to investors is it's, you know, the company has been five years in the making without me knowing about it. The reason why I say that is because, so a little bit longer than five years ago, I was head of designer cybersecurity company and we're growing exponentially. We just raised, I think our Series B, moving from a dinky office to half a floor on 6th Avenue in New York and obviously hiring a bunch of people, middle management, more executives and so forth. And so I found myself in a situation where I was sitting in a conference room during our quarterly roadmap planning. And it's basically a World War 3. Like, everyone is arguing, everyone is bickering, we need to build this feature. No, we have to build this feature. No, we have to build this function. No, we have to do this. No, we have to fix bugs. It's just like on and on, kind of like battle between different departments, right? Because each head of department, we're sitting there at the table and I'm looking at the CEO and just like listening to all of this and trying to make sense of what should I do, like, what's the next step? And I'm just sitting quietly and listening to all of this. I'm like, okay, I heard all these arguments and all these debates, but the one thing I haven't heard yet is what our customers actually need or want, what are their employees, which are our users actually enjoy or need again, and what kind of problems we're actually solving. It's all been about if we don't build this feature, then we can't sell. If we don't build this feature, then these customers are going to walk away.
Right? And it's a very common argument in a lot of companies, honestly, regardless if it's a small, medium or large organization. And so I got so frustrated that I went home that weekend and I tried to figure out, how do I solve this?
We just can't do this. We can't have these battles every quarter of deciding what to do or not to do.
And so I came up with a process that I didn't give it any kind of name at the time. I came back on Monday, pulled aside one of the co founders and I said, listen, I have an idea, I want to give it a try. And he's like, dude, at this point, like anything, I don't care, we have to do something. And so the process was essentially me and my team getting access to the entire organization's kind of like tools, if you will, like Salesforce, HubSpot and whatever. And we basically start pulling all the data, dumping it into a data repository called Dovetail.
And we spent honestly weeks organizing everything, tagging everything and trying to make sense of things, trying to understand what is happening internally. Right. Where is the sales team is is at? Where is the marketing team is at? Where is the stakeholders is at? Right. What are their ideas, stats, requests, desires, wishes and whatnot. And then trying to align it with our user research and usability testing and user interviews and everything we're doing as a design team. I'm like, okay, how do these things align? And the things we're finding as in alignment, these are the things we'll typically bring upfront saying, hey, as a company we need to concentrate on these things because it seems like they're coming from almost every direction. Right? So there's like an interesting cross referencing there.
[00:03:53] Speaker A: So let me stop you there because I do have, I do have some questions about kind of this process here because you're right, I have seen this, this happen before where you get the leadership team or visionaries together or whoever and every sort of department head has their own sort of vision of what would be most helpful to users or for sales, whatever. And often it's quite different. You have support saying, oh, We've got these 15 bugs and sales like, well, we've got these big customers who won't close until we get this one feature. And then you've got this other side of the org which is like, well, our four biggest customers are asking for this one thing. And I've seen this where SaaS businesses often turn into almost consultancies just for these really big customers, where there's sort of building their product based on what big customers are wanting. So you mentioned sort of taking user feedback and sort of combining that vision from the visionary team. How should companies think about sort of going down that process? And you mentioned sort of bringing those ideas to the forefront. Just kind of give me some more thoughts on that because I feel like people are not really Talking about this like, I feel like it's product design is either mostly driven by this is what the visionaries want or this is what the customers want. But combining those two can often be somewhat difficult.
[00:04:59] Speaker B: So I think one of the biggest issues that our quote unquote, the digital era or industry, if you will have experienced over the years is there was a gradual transition from, you know, companies turn to agencies to do their work and then suddenly you have internal teams, right? You have the product or design or marketing whatnot internally. And then the, you know, the emergence or converges, if you will, of some of the consultancies like McKinsey's and you know, the Boston one, from just like being business into also design and product and vision and you know, problem solving and so forth. And one of the things that I, that I noticed happening is design as it came in from the outside, right, from the agency world. And even though they're being built internally in the organizations, they're still being viewed as this kind of like an agency thing in the organization.
So they're not necessarily always involved in all of the decision making process that is happening on the business side, that is happening on the sales side, is happening on the financial side, right? And so these pieces of data or information never actually collide unless a design team explicitly goes and asks for them. And then typically they don't get raw data or raw information, they get anecdotal information.
Things like if I go to a VP of sales and say, hey, can I please get some information about what are people that you're talking to that are not their customers yet, but they're looking for and asking for, right? And typically what you will get in almost any organization is, you know what, I was actually talking to this guy from this company yesterday and he said if we don't have this feature, they're not going to buy it from us. So we have to build this feature. I'm like, great, I'm not going to do that. That's just one piece of information.
I need an actual data set. I can't do that.
This is what is happening in a lot of the organization where they disconnect the user feedback data and organizational flow data, all the sales motions, all of the marketing motions, all of the business motion. And that's why it typically is disconnected. And so in order to remedy this, you have to merge all these things.
Sadly, I don't think it will happen on its own because it means that every single team in the organization is going to have to suddenly organically share Data on a regular basis, practically biweekly, and it's just not gonna happen. It's just time consuming, a lot of effort.
[00:07:30] Speaker A: And how do you go about prioritizing? Let's say in a perfect world, you do have this situation where everyone's kind of combining data well, which, well, I think we'll talk about in a minute sort of how that can be done. But let's say even when that is done, how should companies go about prioritizing that data, balancing sort of the visionary versus customer demands versus this is what future customers might want, et cetera?
[00:07:50] Speaker B: Honestly, it's simple. It's just understanding how do these things kind of trend together. Because if I am a CEO of a company and I think the market is shifting and moving into a direction of, I don't know, let's say I'm on the E. Comm and I see that the market is shifting into silk instead of cotton, right? And so my material or my garments or whatever I'm selling probably should be more silk rather than cotton. As an example, I'm just spitballing here, right? At the same time, if, for example, in this entire data triangulation, cross referencing happening, you start noticing that your customer feedback, right? So think of places where they might be complaining about your products or giving you reviews about your products and whatnot. Certainly you see more and more people asking if some of these garments can be silk rather than cotton. That'll be great, right? And then you also have your product and design team that actually does user research, conducts user testing or interviews to understand their needs or desires and marketing and so forth. And you see that from their side is also kind of emerging that some customers would probably love the fact that the button up will be a silk and not.
So these are three sources that essentially talking about the same thing might be in a slightly different way, but it's the same thing. And so these are the things that are trending. So that's the direction you probably should take as a company.
And that's essentially how a lot of companies that I guess win in a regular innovation and having such an incredible desire by their customers and future potential customers to use their product is when they truly understand not only what their customers want, need, but also reading between the lines and reading between the lines comes from a lot of other data sources.
[00:09:44] Speaker A: And to bring us back to sort of this collection of data, what have you seen work as far as ways that companies can get this data from basically multiple different sources, customers, stakeholders, visionaries, and then combine it, evaluate it Figure out what are the common trends and directions.
[00:10:01] Speaker B: It doesn't, that's just simple answer.
[00:10:04] Speaker A: Like it's extremely hard.
I've tried to do this and it is mind blowingly difficult.
[00:10:09] Speaker B: Yeah, like I've seen some places where they essentially create almost like a centralized hub where they don't necessarily share raw data, they share kind of like insights and what they discover with the rest of the team, if you will. And from there the team needs to kind of go and make sense of it. Right. Derive, understand, synthesize and figure out what to prioritize.
But to my understanding thus far, from all the organizations I worked at, all the designers that I spoken with, and that's almost 2,200 in the last five, six years. It doesn't really exist. So yeah, was it Atlassian, I think a couple of months back released a work, what do they call it, the work report or some, something like that. Essentially I'm trying to understand how team work, how teams work, what are they, you know, the biggest pain points and so forth. And discovered that I think, and don't quote me on that, probably gonna have to go back to, back to the report and read it, but they mentioned that in Fortune 500 people waste 2.5 billion minutes a year on finding the right information. Right. And so yeah, I don't, I don't think anyone solved that problem. Like our product solves this problem essentially of unifying the data and then processing everything.
But thus far I have not seen anyone else that does that in the proper way.
[00:11:37] Speaker A: Yeah, the only other way that I have seen do this sort of a broken process where you basically like collected a lot of customer feedback and then you just kind of went by gut. And then you would have a visionary where someone presents customer feedback and then you have your visionaries and like this is where the direction I want to go. And then it turns into this shouting match like you were talking about, where it's like just loudest voice is trying to get a hold on the conversation. But then it eventually just ends up going the direction of the visionary. And I've actually talked to several founders and asked them how they kind of solved this problem. What do you decide? How do you decide to build what's next? And I think the answer that most come down with is just like, well, it's whatever I want.
And that seems like a not great way to build products. Like just looking at the failure rate of startups, like building what I want seems to fail like at least 90% of the time. So yeah, that I Don't think that that's an enormous issue.
One thing I am curious about is when we're talking about customer feedback, I think some customer feedback, like not all customer feedback is created equal, and it's not all of equal value.
So when you're thinking about sort of this collection process of what customers are saying, are there particular places that you're looking? Like, is it in the sales process? Is it in customer support? Are there any particular places you're looking to gather feedback that's sort of high value? And then what places should maybe we not pay attention feedback?
[00:12:58] Speaker B: I would not say that there's such a thing that don't pay attention to specific feedback.
I guess in simple words, every feedback is valuable as long as you understand what it might mean and as long as you can kind of reference with other pieces of feedback to validate the accuracy or importance of it. Right. So the overarching problem sometimes that happens is you would get something along the lines of maybe five or six thousand people asking a very specific thing or something similar to it. Right?
But at the same time, when you start digging, you realize that underlying problem is not what they're asking for, it's something else. It's just they're experiencing a problem, and in their mind the solution is X, while in reality the solution is Y. Right? It's like the famous, kind of like the reference of when you go to Home Depot to buy a drill, you don't need a drill. You don't wake up one morning and say, I want the drill.
You wake up one morning and say, I want to hang a picture. And that's your problem. Like, that's your core need. Right? And for that you look for solutions. And those solutions could be a hammer and a nail or a drill. If you're, I don't know, concrete wall or whatever the case might be, Right. When you're. If you would give it to customers and say, here, you need to hang a picture. What do you want us to build for that? Right? And they'll probably go and say, I want a nail gun shooting into the wall or something like that. I'm against spitballing here, but it might not be the right solution, Right? The right solution might be a very gentle drill that understands different materials when it drills, so it doesn't actually destroy the wall. But customers cannot necessarily think about that in that far right. In such details. And so it's the job of the product team or the company itself, in a nutshell, is to understand what exactly the customer needs, necessarily want These are two very different things. Just like no one wanted an iPhone, but they woke up the next morning after the announcement and everyone needed it.
[00:14:58] Speaker A: I heard a quote one time by, I believe it was the founder of Wix giving a talk at Y Combinator that you should listen to customers pains, but not to customer solutions, because if their solutions were any good, they would have already solved the problem.
[00:15:11] Speaker B: Yep.
[00:15:12] Speaker A: And I'm just paraphrasing, but how true is that?
[00:15:16] Speaker B: It is 100% true 99% of the time. People who are buying your solutions, services, products or whatnot don't necessarily know what they need. They know what they might want.
Just like the famous Henry Ford quote, if I would have asked my customers what they wanted, they would say, a bigger carriage and more horses. It's like in the design world, we have this notion of if you want your design team to solve a problem in the true manner of it, do not come in and say, I want a better toothbrush, but come in and say, I want a better way of cleaning and let them figure this out.
[00:15:49] Speaker A: I feel like that example makes sense because if you ask me, like, I would probably say a better toothbrush, but, like, if there was a better way to clean teeth that didn't take two minutes and I didn't have to recharge it. My mom's a dentist, so I'm like a fancy rechargeable toothbrush.
But like, if you told me today, like, oh, there's a better way you can clean your 18, like, take this pill, like, cleans your teeth, whatever, right? I'd be like 100%, like, sign me up. Like, I. So I think if you ask me, like, well, how. How do I want to clean my teeth? Better be like, oh, yeah, better toothbrush is cool. But if you gave me a solution that was better than a toothbrush, I would be. I would be all in on that one question I have. So maybe calling back to your experience designing products, when is a product good enough to ship? So if you've taken all this feedback and say, in a perfect way, they're using insight, right? They're making. They're using insight to figure out what they should make. They make it. They.
How much effort should they put into, say, testing? Should they just release it? I mean, just sort of generally, is MVP good enough? What are your thoughts here?
[00:16:44] Speaker B: Paper, wireframe is enough. So our product is not necessarily telling people what to do. It's telling people what needs to be addressed, right? How they do it, it's their business.
But from any product Perspective. I would say that once you have the, the raw wireframe that you just want to test out the functionality of something.
Test it, don't get it to a point where it's all 3D and shiny and you spend two weeks building it and then you give it to your customers or users and you basically go back to the drawing board. You just wasted two weeks.
Like the thing, the thing that our product does is we essentially help companies to understand what their customers actually need. Not necessarily just want. Right. We, we show them what the, you know, the customers or users issues are and we tag it according automatically. And then we also utilize their entire kind of like API of their business and who their user is to understand what their insights on their specific product or feature product could be.
And from there like I would say, yeah, you can draw something on a piece of paper and show to people and ask what they think.
[00:18:02] Speaker A: That's interesting. So I have to, I have to wrap my brain around that a little bit because I feel like it goes counter. I feel like it's a little bit counterintuitive to what I've seen in the SaaS world. I feel like this, like build a paper wireframe, show uses is not usually how this process is done.
[00:18:18] Speaker B: Yep.
[00:18:21] Speaker A: It's usually like take six months, build something, release it and it flops.
[00:18:26] Speaker B: Yep.
Yeah, I've seen it a lot of times.
I think there is a reason why I forgot. So there's a VC fund called Designer Fund. I think they're the only ones who are like purely concrete and quote unquote design led founded companies.
But there are other VC funds that I started noticing over the last six plus months, at least from my perspective. I don't know, maybe they were talking about it much longer than that, but I started noticing that a lot of them are looking for founders or at least somebody on the founding team who is coming from a product world or a design world.
Just because for these things you understand that spending six months on something that you have no idea if it's going to work or not is just an absolute waste of time. It's just a silly approach. Right. And I've seen it a lot of times. You're absolutely right. I've been a part of companies that did that. I'm not going to mention names, but I have been right where I would be banging over the head of the founders of like, you guys are wasting time. They're like, nope, we know better. And it flops. Right. Which I don't like being the person coming back and Saying I told you so, but the feeling is there.
[00:19:40] Speaker A: Yeah.
When insight in particular is looking at customer feedback. Maybe I just didn't understand this before, but where exactly are you guys looking?
[00:19:48] Speaker B: So we're not only looking at customer feedback. And this is our kind of like the biggest differentiator among all the other tools that you might find today that kind of automate your user feedback, right? As I told you, right.
The process that I kind of invented back whatever five, six years ago at the cybersecurity company eventually turned into a decision making framework. I wrote an article about it, I spoke about it at several, you know, on several stages, different events. And then I spent five years training other design leaders and product leaders how to deploy it. And so what it means, really.
So our product essentially is based on my framework. What we do is we seamlessly integrate with your tool stack so your customer or user feedback, right, Like Intercoms or Zendesks or whatever the case might be your kind of like knowledge, right Notion, confluence, Jira Sana and so forth, like your workloads. And then with that we also integrate with, we can integrate things like maybe Shopify or Typeform or whatever the case might be. So we do this kind of full integration of your entire tool stack. We pull all the data from there and then we run data triangulation to a firstly validate the data accuracy between different tools and different data flows. And then we dive deeper to understand the relationship between what customers and your internal teams are talking about.
Everything that is kind of like related to each other, is it trending, is it not? Is it something that could be interesting or not? Our system already designed to kind of pass away things that are important.
And from there we essentially just tagged everything with actually this user issues, things like pain points, annoyances, distrust requests, bugs and the list goes on essentially based on three different main tagging system categories.
And so we don't just ingest user feedback because we believe that this is a one sided piece of data that if you're making your product decisions on, will not be as useful or is as successful if you have data coming from other directions. Well, the one that I told you early on in our conversation that I want to know sales motions, I want to know marketing motions, I want to understand our customer support, right? What customers are complaining about, those customers, what future customers are asking for, what are the potential customer emotional response to our branding, right, from the marketing perspective and all of that combined showing what exactly needs to be done on the product and everything to a increase satisfaction with your existing users and then potentially draw more future customers or future users. And then we also give a analytics on your product goals impact, your business goal impact, your entire kind of like user population impact, usability impact.
[00:22:39] Speaker A: And I think one question I have, because it seems like you're very experienced in this sort of whole building a product realm. When people are building products, do you have any thoughts as far as estimating sort of timeline or efforts involved? Because what I've seen again and again is it just takes longer than expected and it costs more than expected.
So. And I think there's even Douglas Hofstadter, which is a. I think he's a physicist. He wrote go to Lester Bach, you're familiar.
He has Hofstadter's Law, which is it's basically like no matter how long you think something is going to take, it's going to take longer even when you factor in Hofstadter's Law.
So is there any guidance that you have or thoughts you have as far as estimating timelines, effort involved and even impact?
[00:23:29] Speaker B: I think I've always been driven by under promise over deliver. And so that's something that I'm trying to instill in my team as well, is that if you're looking at something and you think it's going to take you a day, tell me it's going to take you days or three days. That way you a give yourself time. Because I don't know how R rated your show, but.
[00:23:50] Speaker A: My mom watches this, so.
[00:23:52] Speaker B: Okay, all right, I'll keep my cool.
[00:23:56] Speaker A: My dad's a pastor and my mom watches this, so just got it.
[00:24:01] Speaker B: All right, look.
One of the things that I've learned over the years is the reason why people underestimate how long something might take them. It's because they're trying to in many cases come up as I know better or I'm the professional. So I'll definitely can execute on this. The problem is in many cases there's a lot of unknowns. Those unknowns not always necessarily related to the tech or engineering or design or any of that. It can also be related to you being human. You can get sick. You can feel not, not good. You can, I don't know, you'll press for whatever reason, you can feel down like. And so your productivity levels are fluctuating based on how you feel on every day. Right. Like yesterday I was incredibly productive. Today I was a little procrastinating in the morning. Why? Because just I was tired. Right. And that happened. And so that's why I always Try to say to people, if you think it's going to take you a day, say it's going to take you two or three days. That way, if you execute in a day and a half a you went beyond your original estimation and yet you still came up on top that you delivered before the three day.
I had this pleasure working with VP of engineering at that cybersecurity company.
He's a director of engineering right now at S Meta. He always had this annoying but incredible value where would be sitting in our planning, either backlog or grooming or roadmap planning, whatever. And every single time a stakeholder CEO, whoever else will ask, can this be done in three days?
And engineers would probably say, yep, can do this in three days. And this guy would always say, nope, that's going to be done in six. He would always double like literally every single time. He would always double the delivery time frame. And you know what? It was right. He was always right because his team would always say it's going to be in three days and they'll deliver in four or maybe five. So he'd always double that. That.
And I think, as I said, like people underestimate for many reasons. Oftentimes it's either emotional or they think they can, but then they don't.
They just don't think about the all down, all the unknown.
[00:26:32] Speaker A: Well, if my bosses are watching this, I, I can say that I never inflate how long it's going to take me to do work. And that's a horrible idea and terrible, terrible shame, Yan, shame.
[00:26:47] Speaker B: All right, all right, I'll, I'll. Okay.
[00:26:51] Speaker A: No, I'm totally kidding. Yeah, I mean that happens all the time with engineering. Like I remember one project that I, I, I'm not an engineer myself, but one project that I was somewhat involved in. The initial estimate was about four weeks and it just kept expanding and expanding and expanding. Ended up being about six months and then we launched it and no one ever used it. You know, it was like, oh, just blow our brains out.
It was horrible.
[00:27:17] Speaker B: Yep.
[00:27:17] Speaker A: Jan, I feel like you've given me a lot to think about today. I feel like you've blown my brain a little bit today because this is a world that I'm just not.
[00:27:23] Speaker B: Why? How come?
[00:27:25] Speaker A: I think just your sort of thesis of gathering feedback from multiple places to measure impact and then usability. I think it's one of those things that when you say it, it sounds so obvious and yet it's something that no one is doing.
So I feel like just your sort of thoughts around doing that has been stretching my brain a little bit because it's outside of my experience.
[00:27:49] Speaker B: Got it. Okay. For all your viewers who might be considering of doing something, what we're doing, just FYI, we do have a provisional patent in our software.
[00:27:58] Speaker A: That's right. Well, if anyone wants to use your software, learn more about you, where should they go?
[00:28:01] Speaker B: Absolutely, yes.
If you do, then sure. It's as simple as that. It's InsideApp.com it's n beginning, not I. People like to confuse insight or nsight. Very cool.
[00:28:15] Speaker A: Well, thank you so much, Jan. It's been awesome having you on blowing my Brain. So maybe I can have you back sometime, but it's been great.
[00:28:20] Speaker B: Thanks for having.
