Speaker 1: Hey there, product lovers. Welcome to The Product Love Podcast, hosted by Eric Boduch, co- founder and Chief Evangelist of Pendo and super fan of all things product. Product Love is the place for real insights into the world of crafting products as Eric interviews founders, product leaders, venture capitalists, authors and more. So let's dive in now with today's Product Love Podcast.
Eric: Welcome, lovers of product. Today, I am here with Nash from Integrity. Nash, why don't you kick this off by giving us a little overview of your background.
Nash: Thanks so much Eric for having me. I'm Nash, I'm the Co- Founder and CEO of Integry. We build the Integration infrastructure for SaaS companies. I'm originally from Pakistan, this is my fourth startup believe it or not. In my previous life I've built Pakistan's largest social network, and we've done payment startup in the telecom space, and custom telecom solutions in another one. But mostly I've been in the B2C space, and what we're doing now is we're bringing a lot of that B2C stuff into this new startup here. This is the first I've done a company which is essentially a global company servicing B2B SaaS companies across the global. I am an engineer by training, I'm actually an Electronics Engineer, so this is an interesting mix for me in what I'm doing now.
Eric: So I'm interested. Tell me about your early companies. What you learned from them? What you took away from that experience. What it was like building the biggest social network in Pakistan.
Nash: Yeah, it's really interesting. So if you go to Twitter, I'm actually Nash, just Nash. I was one of the very early few users. This is because when we started, so my company was called Pring. It was around the same time Twitter was starting. When I looked at Twitter I recognized it immediately as something which was going to be a huge deal. So in Pakistan back in the day, this is now mid- 2000's. Smart phone wasn't really quite there. So we actually had to build an entire conversation system on top of text. It's sort of funny, Twitter started the same way if you recall. You could text your username on Twitter, this short code was a five digit TWTTR short code, and you started getting updates. So we started in that same fashion. We started earlier than Twitter. The idea was you can say, " Follow Nash." And you can text it to the short code and you start getting my updates. So it was a fun, quick thing for your quibbling, and you had this massive following, some of the people that we had had a million plus people. Every time they would say something it would send out a million texts. We built a lot of interesting stuff on it. We built entire multi- variate or AV testing on top of testing. We built multiple language support back in those days. You have to realize this has been, Unicode wasn't really that well squared on these handsets. If you go back before the iPhone era, this was these really clunky dumb phones that you call, back then they were called feature phones. Those interface could only show three or four lines at a time, and that was also for our audience. But what's really amazing about that time was BBC did this really short story on us, and it was this kid from this very remote village in Pakistan. He would join this group, and he would get every day these MCQ's, these multiple choice questions. Which would help him prepare for Engineering school. So he would answer these and he would learn from that. Actually he travels to major city like Lahore, where I'm originally from. Over there he joined this study group, they go and study at this public library, and he ends up getting into the biggest engineering school in the country. That was a change in trajectory in somebody's else through texting. So I had a lot of fun in that. Eventually we had about eight million users, and we sold it to a large E- Commerce in the country. This was a time when there was no venture capital in Pakistan. So we raised close to about$ 2 Million back in that day. It was all essentially individuals like angel investments, and corporate funding and stuff like that. As you can imagine, a social network takes a lot of capital to run. Now it's a completely different environment. This year alone Pakistan had more funding in 2021 than the last decade combined in just the venture world. It's insane. But I had a lot of fun in building that.
Eric: Awesome, yeah that's a great story. So talk to me about Integry. What is it? Why did you start it?
Nash: So Integry is infrastructure for integrations for SaaS companies. Think of it as just like you would use Stripe for payments, or you would use Trillian for messaging inside your app, you would use Integry to add integrations inside your app. So in one of my previous companies it was a enterprise social network, just like Facebook for work. We didn't have any integrations, we were very early on. We built our first integration with Salesforce. As you can imagine, just like a communication app like Slack or like Facebook, they get super charged at integrations. So most of our customers were these sales guys, and when they turned on Salesforce, anytime they had a fantastic lead coming in you saw this activity spike up inside the network. All this flurry of messaging app. We realized integration is really important. This is early maybe 2010's, 2012. So we want to build more integrations. Now around that time, just like a lot of the other players around 2014 we decided to use these off-site integrators like Zapier. So when a customer used to come to us and say, " Hey we need an integration." We'd say, " Sure, you can Zapier to build those integrations out." The problem was most of our customers weren't that sophisticated, and we saw a huge churn. Up to 85, 90% of the customers we would lose them, because they just didn't understand how to set that up. We ended up collecting all these usernames and password on Zapier, and we were just setting this up. So what we did was we built the same Salesforce integration within the app, and we saw that if you had an integration which was just a button, which a user would click, activate and they're done. It had a 30 times higher conversion rate. Not 30%, but 30 times. It blew our mind how important the whole experience over there was. So we realized that building integrations inside your app in a way which is congruent with your UI or UX is really, really important. But there just wasn't a company doing this. So I, the head of server side, and integrations and a third engineer were quick to start this company. Our goal here is to provide fast- moving, fast- growing product teams the ability to create fantastic what we call integration experiences. So if you are a product team, and you believe that a fantastic UI, a fantastic UX is critical to your success, you will not outsource your integration experience. You will not have consultants to particularly do it. You will not hand it off to some outside integrator. You'll want that to be a first- class citizen within your application. Integry makes that possible. So we tend to help you, the product that we do it helps you with the whole end to end thing. From creating, managing, deploying, the integration, customizing UI/ UX, all of that within your application.
Eric: So you mentioned integration experience, I've heard you guys talk about that before. Can you define that a little bit more, what you mean by that?
Nash: Typically you have your standard, the UI that a user has, a UX that a user has. An integration experience is not just the part where a user interacts with for example a setup form where they explain what they're integrating. It also it happens behind the scenes once integration is setup. So for example, I might want to send a tweet every time I create a piece of content in my for example WordPress. Or for example I might want to import my data, my customer data from Salesforce let's say into Pendo. Now how the data gets transformed whether they were European dates that had to be converted to American dates. Whether you want to import all your data or some of your data. The users don't want to mess with that, they just want that to work. So when we think about the integration experience, it encompasses all of that stuff the user sees, the stuff the user does not see behind the scenes. So if you are product leader, you want to think about this holistically. So Integry is spearheading this movement of taking back control of your integration experience. So bringing back that integration control to product teams is bringing back the experience back inside your app, rather than abdicating it or handing it off to these external services.
Eric: So as a product leader, why are integrations important today?
Nash: One of the things, you have to look at this from a multi- generational level. Integrations have existed since the day a company bought two software, they had to talk to each other. Over time what has happened, if you go back maybe ten, fifteen years, integrations were very enterprise, very large scale. One of the things which happened in 2012 is that two companies, Zapier and IFTTT came along, and this demonstrated anybody should be able to build integrations. But since then, if you pick up any app, any public SaaS company, all of them are essentially integration companies. They have 100's of integrations. Our approach here today is that what we're doing is we're sending a lot more apps to users. Users, especially thanks to the whole pandemic, are now digitalizing really, really quickly. They're buying more and more applications. Users are reaching this breaking point, this app fatigue. You're switching between these ten, 20, 30 apps. You want these apps to work with each other. If they don't, you end up being like this little shoveler who just keeps on moving data between these apps. So if you're a sales or a product guy, you're selling your app to a new customer. Your customer no longer wants to start from scratch. They already have their user data. They already have their customer and their employee data, they want to get up and running really quickly. So it's really important for them that these tools work well together. It's because of the fact that we have so many of these apps now that we're using, that integration has become really central in what we're doing. You want things to work seamlessly between each other. If you want to continue on this rate of technological growth. If you want to keep on adding more apps to our stack, we need integrations to work seamlessly. Imagine having twice as more software that you're using today, in ten years. Which is very likely going to happen. Without integrations that just doesn't work. I think integration has become a really key part of both why you choose a software, and to how you keep your business running.
Eric: Yeah, it feels like to me if I'm a product leader in a SaaS company, integrating with the other things in the enterprise is essential. The other things, or at least in my customers enterprise, it seems like there's way more of those things than there were five, ten, even two years ago.
Nash: That's right. It's actually interesting. Look at the tools we use today and almost half the tools that I'm using today did not exist five years ago. Or were not really that much adopted. Even though Zoom existed for some time, I think it really everybody got to know Zoom in the last couple of years I believe. Or I feel in that. So similarly there ara a number of things which we're using today which just weren't there. Five years from now we'll have tools we're using which we just aren't today, but are now completely essential. So that onslaught of getting better, of having these apps which do improve your work, is going to keep on happening. Without integrations, it's really hard to maintain that pace of growth.
Eric: Yeah, that makes sense. So why shouldn't product leaders build their own?
Nash: That's the biggest problem that we have. When we talk to people in product, they all know they have to build integrators. It's very, very frustrating to have a conversation with a product leader who doesn't understand that they need an integration, they do understand that. The problem is two- fold. One is that to ask engineering to build integration is to take that precious bandwidth away from product features. Because Engineering is one of your most expensive resources. The second is that even Engineering doesn't like integration, no engineer wakes up and says, " I'm going to work on my tenth integration today." That doesn't really happen in the Engineering world as well. So as a result, product leaders would consider integrations a necessary evil and offload them, or hand them off to these consultants or outsourcing firms which may not really understand your UI/ UX needs. Who might not have the same gene that you have while you build your product. Or they might do it with these offsite integrators who have their own goals, their own UI, their own UX. They're not necessarily in alignment with what you're doing. So if there was a way for product leaders to implement their integrations, which would be less of a time suck, would be low code or even no code, which what Integry does. I think if we give them the key or the solution to integrations, or roll out integrations, product people are actually very keen on building those experiences. They actually love implementing integrations and seeing it come alive using their own UI, using their own UX. Because we pride our technologies customs in a way that you can change the UI or the look and feel of the skin in however you like. It's something which product leaders really love. The payoff is high. Like I mentioned, if you have integrations inside your app, that has a 30 times higher setup rate for users compared to these other integrations which are not on your platform.
Eric: Yeah, so it sounds like you're moving the responsibility for integrations from the Dev layer up to product. That seems to be where software companies or people building software are more likely to embrace it. Is that accurate? Is that what you see?
Nash: So that's actually a really good point. Most integrations were typically, if you look at ten, 15, 30 years ago, CIU's, the IT department would be responsible for integrations. I am an Engineer, but I would say that a lot of the reason why integrations haven't been that great is because they weren't really built with a product lens. It was built with an engineering lens. So what Integry does is it involves all stakeholders. So while the people in product do spearhead integrations. I would argue that whether it's Integry or not, product people should definitely design the concept, the flow, the UI, the UX, the IX, the integration experience of the integration. Once that has been understood, then it goes to Engineering. Rather than just giving it to Engineering, which we do see a lot of these companies do, they think of it as an API- specific thing. So it definitely is elevating integrations from a software or engineering specific ask, to a first- class citizen on the UI/ UX level at part with all your other features. Like I said before, previously this wasn't as possible because the technology just wasn't quite there yet. With Integry we're hoping to change that. We're hoping to unlock what product people are able to do, thanks to some of the advances we've seen in low code and no code.
Eric: Yeah, it's interesting. Now from a users perspective, their expectations changed a lot as far as if I'm buying a CRM package, do I expect it to integrate with my marketing automation? The rest of my sales and marketing stack? It feels like more and more, the end buyers are getting more sophisticated about what they expect to be out of box in the form not just of integrations, but frankly training and other things in the product.
Nash: That's true, but I think this is credit to the product community. Not only has the user become sophisticated, but also what technology can do has also become much easier to use. Before Salesforce came along, CRM was limited to these larger companies, but thanks to concepts of SaaS and things like that any company in the planet can now deploy a CRM. I think the same has happened with the expectations around integration. Because I'm buying these apps, I might already be an existing CRM user, I want this to work with my existing data. So if you start any new app, well the first thing you do you have to set it up. Inevitably, you have to import your data in some shape or form. If you just are able to give a one click import experience, or at least some way to link to an existing app you can pull stuff in, it helps to get your users up and running really quickly. That is just good for you as the product owner, but is also good for users who are able to get things done quickly. I think as users have become more sophisticated, we've moved from people in sales using from one app to 15 apps today. They are using far more apps, and they have this expectation that the UI just works. There's not a lot of running around, which was what integrations used to be in the past. So I think there is definitely a higher bar for integrations today than it was ten, 15 years ago. I think that's good, because ultimately you want people in your company to work on the creative aspects of their job, rather than this repetitive shoveling bits and bytes between apps. That's where we want the world to move towards.
Eric: Yeah, interesting. It feels like you've mentioned no code, low code. I've seen this big trend when building product where PM's should try to buy, or rent in the case of AWS or Google Cloud, as much of that underlying typing or infrastructure so to speak as they can. If it's not your core competency, it seems like the trend is starting to be get that from other providers, as opposed to build it out yourself. Do you see that?
Nash: So that's true. But I would say two things. One is, around 15 years ago, so I mentioned Pring, in Pring we built our own data center. It was a huge pain. We had to learn civil engineering, power engineering and all that stuff. We had to have those competencies. Ultimately the math just didn't work in favor of building your own infra. Ultimately AWS and all that has won. Now traditionally, if you're using something that works in the back- end, like for example a Toolur API to send a message, or transacting something through Stripe. It typically works well, some things is behind the scenes. SaaS companies have been less willing to use something which is front- user facing. Or at least something which the user interacts with. As a matter of fact, I was reading a book by the Toolur CEO and he mentions, it just came out this year, that you should own the front- end UI of your customer. I've seen that is changing now. Even Stripe gives you this ability to build your own checkout experience now. A lot of these companies are helping you do so. The premise remains the same. You focus on what you're good at, what your core is, what differentiates you. All the other things, whether it's a database, or a back- end, or a messing, or a payments thing, that should just work for you. Ultimately I think it's really exciting for a startup to start today, and out of the box just provide 100 integrations just on day one. This would have been unthinkable five years, ten years ago. So I think that's super exciting, and that's a huge win for users as well.
Eric: Yeah it's something the startups can sell. They can monetize that portion too.
Nash: That's right. I think monetization of integrations, if you look at any of the good players in SaaS, the leaders in SaaS, they have found interesting ways to align their pricing, the monetizations with integration usage. So you want integrations to be designed in such a way that the more integration users there is, the more revenue you make. As opposed to thinking it's a necessary evil, and you want to minimize integration usage, which we've seen as well, depending on how you approach integrations. I'd say using off- site integrators, while they solve the problem today in a decent way, not as great. But also the trade- off you're making is you leave money on the table as it comes to monetizing those integrations. But I think once you bring those integrations in- app, once you build a better experience you're able to monetize them better as well.
Eric: Yeah, do you see this trend continuing? It seems to be a big trend. You can think of Pendo as, " We give you instrumentation right out of box through our snippet of good. We give you guide creation and deployment out of box. We give you analytics, product analytics out of box." You see people like Auth Zero, or AuthO or however you say it, giving that layer. Okta, similar. That whole OSS, authentication layer. You see things like the work OS are doing. What you're doing at Integry. It seems like this is a big trend over the last couple of years where startups are going to keep pushing into different areas of we will help you do this right out of box so you don't have to code it yourself. If that's true, what other areas do you see moving in that direction?
Nash: Everything. I think it's great. I personally think it's fantastic. When we look at a car, when you see a car today you think about power steering, you think about airbags, you think about seat belts and all of these cool things. But today it's even automatic lane changing and stuff like that. A car 50 years ago was still called a car, but it had a lot less features. So today I look at software the same way. So when you have fresh software, brand new software even if it's by a one guy, they can implement single sign- on using all these other services using Auth0. They can have multiple sign- on with Okta and stuff like that, they can have instrumentation with Pendo all out of the box. What is also very exciting is the way the ecosystem has decidedly the direction they've chosen here is they have these really generous free tiers as well. So if you're trying out something, you can pull something together really quickly. I think that's really great. In terms of other areas, I think if you are a hacker, if you build something, any aspect of something that you have to do by hand that is not your core, that is an opportunity. So there are whole companies that are to be made if you just take away that five per cent every company has to do. If you aggregate that, I think there's a whole huge opportunity there. There's a whole bunch of things that you can look into in that.
Eric: I'll put you on the spot. If you weren't doing integrations, what other one would you do?
Nash: It's very interesting, before I started Integry I went into the soul- searching phase, in which I short- listed maybe five or ten ideas. I went completely off the rails, so the idea which was Uber for farming, an electric car for the every man. Which would be targeted towards the region, the Pakistan, Indian at large. There was a concept of photo stores, which is essentially a way of back- end as a service for retail stores. I went all over the map. Ultimately those are areas which I really didn't have that much of an experience in, so it would have been a multi- year endeavor.
Eric: But what about product. If you're selling to a product person like you are today. Instead of outsourcing integrations what would you say, " Hey you should outsource X."
Nash: One of the pain points I do feel is around content management systems. So for example, I don't know if you've used stuff like Noosh, or Click Up, or Koda. They're fantastic, multi- player editing tools. So there's a whole class of tools like Zen Desk that have these help articles, and you have these whole knowledge bases. There's just no easy way to collaborate on that. Whereas if you just completely replace them with things like that, I think there's a big opportunity over there which has still not really been exploited. So I think content, which is multi- player within the company, that I think could be a potential thing. That's the one that comes to mind. There's a bunch of engineering things which I think should be simpler. There's no clear winner over there. For example even today, an infinitely scalable SQL is still very expensive. There are Google Cloud, Spinner, stuff like that. But I do feel that a good scalable database you can just plug in and start up free would work. That's just the Engineering in me talking. But from a product perspective, the most recent feeling I felt is around being able to build collaborative content rapidly between all members of your team in which you can review and stuff like that as part of your knowledge base and stuff, and maybe your help and support. It's not a fun answer, but yeah.
Eric: No it's good, it's good. One of the things obviously or maybe not so obviously, I think this podcast will be out in the next few weeks. So we're still going to be more or less in pandemic mode. Integry has been a distributed company since day one, right? In 2017 when you guys were starting. Talk to me like that, why do a distributed company versus in- person? How do you think it's better?
Nash: So we actually consciously decided to make Integry a distributed company since the beginning. This is about 2017, pre- pandemic and stuff like that. We felt that you needed a lot more discipline in terms of communication to be a distributed company. So we actually inside our company we heavily discouraged chat and calls, funnily enough. So if you're a distributed company and you're against chats and video calls, then how do you work? So the answer is that 90, 95% of work should not be chat or calls, it should be the actual work artifact. So for example, we have a management- wide meeting on a regular interval, at the beginning of the month and so on. What we found out was that if every person who has to make a presentation, instead they just write the stuff they have to present down, and everybody has to review it before they come to the meeting. The quality of discourse, the feedback was really phenomenal. That was the impetus that we had, that we have to have a distributed company where people focus more on long form, they spend more time thinking about the actual thing rather than struggling with the presentation itself. So we saw some of that before we started the company. So when we started Integry we realized we wanted that as part of our DNA. There's also something about writing. There's something about writing down what you're thinking about before jumping right into a conversation with someone, that helps you hash out what you're thinking through. Of course there are some things you still should do, like brainstorms and maybe sensitive topics and social stuff you should do face to face in a live call, stuff like that. But I feel the quality of discourse in a distributed company that uses writing as a core communication, I feel it's better. This is my fourth company, I've done other startups before. I do feel that has been a recurring factor. This is also very common in other companies, and was on a famously writing- heavy culture as at Stripe. I think a distributed company just takes that and dials it up to ten.
Eric: Yeah I've interviewed a few people that are memo- driven companies. As opposed to meetings, discussions, it's asynchronous pitches, then criticism of that all happening asynchronously depending upon when they happen to be working. It's interesting, you definitely have to hire differently too if you're a very writing- focused company, because then you have to have people that communicate well in that medium. So has that affected your hiring?
Nash: Absolutely. So we filter for, or look for these attributes. Some people are naturally very extroverted, and we have extroverts in our company. So Integry is not just distributed in space, we also say we're distributed in time. So you can work at any time, and you can work from any place. If you're an extrovert you're able to work from different places as well. So you get your fix in other ways as well. In terms of hiring, it takes a bit of getting used to. It takes a bit of understanding how this way of working is. We have some ways to filter for that. We look for existing work that you might have done in writing, in communicating. For some people it doesn't work. For some people they are very meeting- driven, especially people in management or leadership, they're very heavy on if there's something I will just talk through it. So that definitely makes an impact. We have an elaborate process when we hire, we go through these exercises that we send over, and we filter through that. But also we get the benefit of being able to hire from anywhere in the world, and that has been since the beginning. As a matter of fact, a lot of folks who... We saw this in the pandemic. So San Francisco suffered the greatest shrinking in terms of people moving, and so did all the major, these centers. New York faced the same thing. So a lot of people who are getting, they're able to earn from anywhere they want. They're able to then shift to anywhere that would be lesser expensive, or get a better deal on the house and stuff like that. So I think there are many benefits that comes with a place like that. So it helps in recruitment, that freedom, you're able to bring in a lot more people who otherwise you would filter out because of location and time zones and stuff like that.
Eric: So you expand time zones, you expand location reach. You lose some people depending upon their communication style I would guess.
Nash: That's right. I always lead, not every company's style is meant for everybody. So I think that's just natural for any company. You want to pick and choose a company which matches your lifestyle, it matches how you work. So this is a conversation both potential employee and employer has obviously through the hiring process.
Eric: Yeah, absolutely. What advice? We're talking about distributed, but we're also talking about sync versus async in these kind of environments. What advice would you have for other companies that are looking at having a distributed company, and having this asynchronous culture? What advice would you give them versus an in- person company that has a synchronous oriented culture, or even a synchronous oriented culture with multiple offices?
Nash: Yeah so synchronous is obviously having a phone call, or having a face to face meeting. I think the biggest thing I would say is in the synchronous world, which is the default, every time you have the urge to, " I want to get on a call with someone, or I should start this chat conversation." You should ask yourself, is this the best way to approach this? So for example, if there's a question regarding a code problem. The best thing would be to put a comment on your comment code system, like GitHub or something like that. Because what chat does, is chat induces urgency. So similarly, we internally use different software like Convo, we recently shifted to Click Up for internal documentation. You have to have a healthy culture or guidelines around how do you want to start a conversation. So we have a bunch of guidelines around what questions you should go to your head before you want to set up this meeting. So there's this meme that yet another meeting which should have been an email. So a lot of that happens in companies. So what I highly recommend that if you're in a sync company, take a look at anything you're doing and question whether this should be... is there a better way to do this? Whether that is communicating through a document, if there's already a document, putting a comment there might be the best thing to do. If it's a design review you're doing inaudible, or just giving feedback, it might just make sense to put comments over there. There are many tools now, so I think collaboration some shape or form, it makes sense to consider instead of this knee jerk, let's get on a call, let's get on a chat. Another thing that you shouldn't, but I think in a vast majority of cases it just makes better sense to go down this written route.
Eric: So I'm curious, documents versus emails. Do you have any guidance for that?
Nash: 100%. So for internal company stuff, 100% documents. I'll give you a quick example. Notion has now popularized this. But just imagine a company that starts on Notion, on Devin, or Click Up or any documentation system. If you join such a company, you will be able to see all the documents and all the decisions and all the discussions they've done since the company. If you want to look at something, if you're headed or something you can very quickly look up what has the conversation been. Whereas if I'm joining the company, and let's say I'm filling up this new product role, and maybe the person who I'm filling in for has left the company, their inbox is completely useless now because it's their personal inbox, how it's organized is up to them. Nobody searches other employees inbox, that's just creepy, weird and it just doesn't happen. So when a person leaves a company, the sum total of their knowledge is typically inside their email, and that knowledge dies with them when they leave the company. But with a common documentation tool, you're able to retain that knowledge, and so I highly recommend for larger companies to have some sort of an internal library which helps employees understand how to file and find information, and to use a tool which makes that really easy. We internally have a system of how we file things. So Integry, if you look at it from the inside it's like a big book. There's this large table of contents, then you can go inside each section, there's a section for product, inside product there's a section for features and stuff and thinking. So you can actually zoom into wherever you want. But you should be able to find anything if you're just browsing along. So I do think that a document- based approach is much better internally versus email. Obviously when it comes to external world, there is yet no good replacement for email. Slack Connect has been doing some inroads over there, but I prefer email to Slack on most days.
Eric: Yeah, have you ever thought of just sharing documents, just send an email with a link to a document. Does that kind of stuff work for trying to not lose some of that knowledge that's internal/ external collaboration?
Nash: Absolutely, but the problem with some of that is documents are created really rapidly, and if there's no glue which connects them together, a way to file them, or a way to categorize them which is usable and distributable, those documents will eventually live out and it'll be hard to find them unless you use Google search in a way which helps you. But definitely you can. Look, I'm not saying my way is the right way, or we're doing that. But any sort of approach in which people are able to do things on their own time, be reflective, be thoughtful, not be in the pressure of a meeting to think on their feet. In a meeting you're presented information live, whereas if you're given that information earlier on you're able to think, reflect, percolate on that, and you're able to be more thoughtful in your questions and your feedback. I think there's a lot to be said on a memo- driven company.
Eric: Yeah I would agree with you there. A lot of us are always pulled into meetings, and we're presented with something and it's like, " Tell me what you think." It's instant reaction, no research, no pontificating or pondering or being your own version of the thinker so to speak. So you worry about how good is that feedback you're giving people, given that that might be the first time you even heard of that concept. So I do get a lot of that. I was also thinking about this whole thing of I use Superhuman on the email side, it definitely makes my email more productive. But should we rethink email altogether, and what the purpose of email is. You see some of that Slack taking away a chunk of email, there's people that think of email as a communications tool. In a lot of cases in my case it turns into a task list in some ways too. But it's not built like a task list, does that makes sense? It's like, " Oh I have these 15 emails I have to respond to which end up being tasks. I need to do this and send this to someone so it fulfills a task that was associated with this email." But email is not built for that. So it's that whole process. Sometimes I think we should rethink how we work a little bit that way too. Email is a part of both the good things about work, and the bad things about work.
Nash: That's right. There have been several attempts but nothing has really stuck as a replacement for email. Email is not going away anytime soon. As a matter of fact email volume has increase every single year, and continues on. Email as a task is interesting, and in my point of view very stressful. It's like giving the world access to your task list where anybody can just come in and insert into that.
Eric: Well let's be serious, even if we don't want people to do that, we do that. An email comes across, and there's a task associated. Even if you're a CEO you've got a board.
Nash: I love Superhuman. I want inbox zero, but I will tell you this. Keeping inbox zero is super stressful. You're constantly trying to keep on that zero.
Eric: Totally, I want to get to it every day and then right now I'm looking at, because I have a number of email boxes now and one of them has like 39, it was 200 this morning or something. I'm like, " I've got to get to zero." So there is a stress associated with that.
Nash: You're right, but the good thing about email versus chat, so I do prefer email over chat. Email is still long form, so a person could actually really mention what they're looking for, they can add images and stuff like that. Whereas sometimes you'll get a chat message that'll be like, " Hi, are you there?" You're like, " Yes I'm here." You have to get the ball rolling, and they'll ask some basic question. So and the other problem with chat is that the search in chat is just not useful, because they're these little tiny sentences and just finding anything. Try finding an address in your iMessages. Somebody sent to you some address, it's impossible.
Eric: It's crazy, and when people send me files in Slack, another thing that's even worse. Now I've got files in email, files in Google Docs, files in Slack. It's ridiculous, you don't know where to look to find the file. Where did they send that? What medium? Disaster.
Nash: There are some companies that are working on unifying the document, or this artifact discovery process. For example I think there is FYI search, I forget the name, I think inaudible company. Essentially it's a whole bunch of integrations which resemble to you search something is able to search in all of your SaaS tools. It's a middle solution, but it's not quite there. But I do agree, there has to be something better there. I think not just the tool, it's also the way human behavior has to maybe change in this. I subscribe to so much stuff, I love Superhuman, I use Superhuman, when my other folder, it always reaches 1, 000 and I just select all and just mark it as read. These are all marketing stuff, social media updates, or newsletters which I really thought I had the time to read. But now it's just this huge pile of guilt. The good thing is email is biodegradable, so if you just leave it piling on, I think that email just goes away. So yeah, but I love Superhuman.
Eric: My other folder is a conundrum. I forget now the command for mark all as read. It should be one I know instantly.
Nash: Command A and E. I think it's command, you, I think you just have to hit that.
Eric: Anyway, well this has been fun. I know we're getting to end of the podcast right now. I'll turn it back to Nash, what's your favorite product?
Nash: I'm not sure if it's my favorite product, it's the Bose headset, it's the noise- canceling headset. It's very funny because I originally bought it because I was traveling a lot on the BART and the BART when it goes underground it gets really, really shrill. I was traveling on it twice a day and I thought it's going to damage my hearing. So I bought these noise- canceling headset. I'd wear these when I was traveling on airplanes and trains. But then the pandemic came along, and it turns out it's a fantastic tool to have in your house when you have kids around. It really minimizes a lot of the noise over there. Not perfect, but it does it to a degree that it makes your environments more workable. I think it's a fantastic piece of technology. The guy who sold me the Bose, I bought this at an airport. They could make this even higher noise- cancellation but it would be illegal. I'm hoping there's some bootleg version of getting that high quality noise- cancellation somewhere.
Eric: Awesome, awesome. So one final question Nash. Three words to describe yourself.
Nash: God I hate that question so much. I tend to not think about myself. I avoid that at all costs. I just find it strange and I'd rather just talk to people about them. I guess human, I love making a ton of mistakes. I'm also driven, but this is not an interesting answer here I suppose. I guess just that it's human, it's driven and yeah, that's just two words. Will two words cut it?
Eric: Yeah two are fine, I'm not going to push you on it. I think it's going to be interesting, I'm on this is episode I think 140, 3 years or so of podcasts. It'll be interesting to go back and look at the three words, and just do see what people had picked, where the overlap is, and how that differs based on CPO's, and user experience or design people, and CEO's. I think there's some interesting data there.
Nash: What's the best answer you've gotten so far?
Eric: I don't know that there is a best answer.
Nash: Something that stood out.
Eric: There is definitely people that have been more creative, none of them pops immediately to mind. I once answered this question by describing myself as a salty, ocean breeze, three words.
Nash: I like that.
Eric: There are people that have described that as a phrase, as opposed to three adjectives. Those can be kind of interesting. I just find it, there's a lot of overlap with product people. There's a lot of driven, there's a lot of curious, there's a lot of human or empathetic, that kind of thing. I think product leaders tend to have a strong sense of empathy, because I think in order to build a product that appeals to a broader group of people you have to have a strong skill I would even say of empathy. You see that in a lot, just like your human aspect. We do see a lot of ambitious, driven, go- getter kind of words too. I think maybe some people are more hesitant to pick those at times, and they're picking softer words. It's fun, I'm going to have to dig in one of these weekends, " Okay, what's the list of everyone's three words." And build a spreadsheet with that.
Nash: A real fun project.
Eric: Yeah. It says a lot about us that we think this is a fun project. But thank you Nash, this was awesome. I greatly enjoyed it.
Nash: Thank you Eric, I had a tremendous amount of fun here, and I look forward to hearing this once it's out.