The classic lies in product

Amogh Sarda at UXDX Community: Bridge the Digital Gap and Reconsider Classical Learnings. Video: https://youtu.be/ivO2LMoiE5U

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

101 concepts and the real world

[00:00:00] Hey everyone. My name is Amogh. I was a product manager at Intercom for a few years and at Atlassian for a few, and now I'm working on eesel in startup land, so sort of doing my own thing now. And today we're going to be talking about the classic lies in product.

[00:00:21] When it comes to learning anything new, our brains can only sort of cope with so much at once, and so 101 concepts are usually taught in a pretty black and white way. That makes sense, right? They're taught in a way that this is right and this is wrong, and this is what you should always do and this is what you should never do. And of course, as it always goes, the real world is a lot more nuanced than this black and white, and in practice we actually have to deal with a lot of gray. So in this talk, I'm hoping to cover a few classic 101 concepts and how they can actually sometimes misguide us if we're not too nuanced in how we apply them. Cool, so let's get started.

Lie one: say no

[00:01:17] So of course, saying no is a classic 101 PM learning. We need to say no to bring focus on what we're building. It's how we avoid ending up with a hodgepodge of product strategy. There's plenty of Steve Jobs quotes to be thrown around here about how it's all about the things that you're saying no to, not just the things that you're saying yes to, and so on. So obviously there's a lot of truth to this. In fact, you do need to say no to bring focus. But I would sort of go as far as to say, hey, actually let's try to say yes before we say no.

[00:02:00] Now, why am I suggesting that? So whenever a new idea comes to us, from a customer, from sales, or from any other teammate, it really doesn't feel fair to default to no, right? We have so much inertia to keep things as they are, and a new idea is almost never really going to be formed enough to have immediate sway. And so instead it's actually fairer to first try to build with a yes whenever the new idea comes, and find all the ways that the idea could work, not just all the ways it can't.

[00:02:39] Now, this is hard. Unlike an easy deflection with a no, yes requires us to actively listen. It requires us to empathize. It requires us to pause and try and understand why this person is actually saying this in the first place. And it's just generally much harder to do, and it's probably why we default to no. But it's really important to pause and say yes, to explore this, because that's actually ultimately how we create empowered product teams. It's how we create people, outside of product even, feeling empowered to influence the product. And this is sort of how we can go from rough crazy ideas to good crazy ideas, and it's kind of how we can discover those gems.

[00:03:31] So a nice anecdote to point to here is this talk I came across from — or not even a talk, a Loom recording, I should say, I came across from Pat Grady. He's a partner at Sequoia Capital, and he talks about how when he got into venture capital, his modus operandi when he was super new to all this was, hey, a new deal has come along, what are all the things that are wrong with this? Here's something that's flawed about this, here's another thing that's flawed about this, here's another thing that's flawed about this.

[00:04:09] And he's come to realize that actually a big part of his job is to actually find what's right. It's to go, despite all of these flaws, this thing over here that is potentially right, or could go right for this company, is giving me enough conviction to make the decision to invest. And I really think this sort of touches on what I'm getting at here really well. Of course, product management and venture capital aren't exactly the same, but I think ultimately the analogy sort of holds well. We should try to say yes before we say no.

Saying yes to browser history

[00:04:45] I'll share a story from my personal experience where I had to apply this nuanced PM 102 lesson. So, like I said, I'm building eesel right now. We started this sort of coming from a pain that we felt ourselves. So I was a product manager, like I said, at Atlassian at the time, and I was struggling to find documents that I needed to get my job done. Things were spread across all these different applications and it was just a struggle to find the links I needed to do my job. And I thought, okay, well, I can't be the only one who feels this problem, I think there's an interesting business opportunity here. And so that's how we got started on solving this.

[00:05:35] And we thought, okay, well, the most intuitive way to solve this would be to plug into all your different work applications using their APIs, right? Let's plug into Google Docs and Google Slides and Figma and Coda and whatever, and index all of the content in those different apps using their APIs, and then give you a nice little search across all of these apps in one place.

[00:06:00] And we were pretty deep in this. So we started thinking about this API approach and we were pretty much trying to figure out how we can do this with low latency, and how do we make this feel super responsive, and how are we going to plug into different apps and APIs and all that. And sort of deep into this way of thinking, when we had a lot of inertia, one of the colleagues suggested using browser history. So, hang on, instead of using APIs, what if we used people's browser history to infer all their different document links, the Notion doc that you have and the Google Docs link that you have and so on?

[00:06:49] Now, just at face value, that's bizarre, right? It's a really unusual thing to suggest here. What about all of the things outside of the browser? I've got maybe some local apps that I'm using that's not going to be in my browser history. What about things that I haven't seen before? Only the things that I have seen are obviously going to be inside my browser history. Anything to do with browser history just generally feels a bit invasive, so that's a bit scary. It's just immediately kind of awkward to even think about building an application on your browser history.

[00:07:28] And it also doesn't really feel as powerful as APIs, right? APIs are literally that thing applications have built to interface with them. It's in the name. And why would we not use that? Why would we as eesel not plug into these applications by using exactly the thing that they have built to interface with them? So it's just a very, very counterintuitive suggestion.

[00:07:54] But this is where we sort of paused and we tried to say yes. We tried to figure out all the ways maybe this wasn't a crazy idea. And one thing we came to realize is that, well, whatever eesel is going to be, it's just going to be a better version of this. Right now, this is kind of where I'm finding the things that I need to do my job. Usually I just type a bunch of keywords in the address bar on Chrome, and if I'm lucky with the right keywords I get it right away. Or sometimes it's not there and I have to try a few different keywords, and inevitably I end up pinging people on Slack or MS Teams if you use that. But that's sort of where I'm finding links today.

[00:08:40] And when we started to reflect on that a bit more, we came to realize a few different things. Actually, most of the time we're working inside the browser. So all this non-browser stuff — most of the time I'm generally just working inside the browser, so that's actually not a big deal. And most of the time I'm actually just trying to find things that I've seen before. It's very rare that I'm trying to do totally greenfield exploratory research. Usually I'm just trying to go, hey, yesterday's meeting notes, or that slide deck that I saw last week, things like that.

[00:09:13] And we realized that actually working fully locally is possible if we're inside the browser, because if we're inside the browser, we're not plugging in with any APIs or anything and we're just using browser history. We can actually store everything locally, and that's actually more private and more secure than APIs, and it's actually even faster as well because everything is local. And also, sure, we don't have the power of APIs, but actually we don't really need that power, and also it gives us power in other ways. There's potential to maybe interact with the web page and take actions for internal tools, and even actions that maybe aren't supported with an API.

[00:09:59] So this is countering all of the initial concerns that we had. And then in addition to that we discovered more interesting things on top, like, oh, actually this approach, a browser-based approach, will work with anything inside the browser, even, like I said, your company internal tools, a shiny new app on Product Hunt, whatever app inside the browser, it'll work with it even if it doesn't have APIs. And the other interesting thing is that it's also going to be a lot easier to maintain. We don't have to deal with crazy API data ingestion magic, and actually it'll just be a lot more straightforward to build.

[00:10:40] And this is sort of where I'm so glad we paused to say yes and we didn't default to no, because it certainly wasn't intuitive to do that. But that's exactly the approach we ended up taking, now this browser-based approach, and that's what we have today. So this is what it looks like: you can search across your different apps, and this is all an integration with all these different apps without an API.

[00:11:07] So it was certainly a case where we went from rough crazy idea to finding, in some ways, a crazy good idea that's ultimately become a key foundation for this company. And not only this company. It's interesting to note that this even inspired others. So there was a Y Combinator company called Station, and $4 million and more than three years of work with several teammates and 600 API integrations later, they pivoted to using the browser history, much like us. So they pivoted from their API-based approach to a browser history approach.

[00:11:52] And so this is really, I would say, one of those cases where this decision we made was a very high leverage decision. It saved us a lot of time, a lot of money, a lot of hassle, and we only discovered it because we paused and sort of said yes to a seemingly bizarre idea. And so yeah, the key takeaway here is to really challenge yourself to say yes, even if it's for a little bit, before you say no. Obviously you're not going to spend hours and hours of thought on every trickle of idea that you stumble on, you need to apply some judgment here. But the key thing is really to try to say yes, even if it's just for a little bit.

Lie two: always start with the problem

[00:12:32] Now on to another classic 101 principle. You know, product managers, we start with the problem, right? We like to throw in, in a lot of conversations, what problem does this really solve? We like to sort of try to bring it back to the broader picture, and that's fair. Of course there's nothing wrong with that. But the point I'm trying to make is that actually, sometimes, just sometimes, it's okay to start with the solution.

[00:13:02] It's actually okay to get inspired by some cool new tech that you've encountered. Maybe GPT seems to be all the craze now. It's okay to get inspired by some strategic opportunity that you're seeing based on the market, or based on your existing product offerings. These are the "wouldn't it be cool if" ideas, and they sort of need space to grow. They can take you places linear thinking from problem to design can't.

[00:13:41] And we shouldn't feel the need to abruptly cut any sort of discussion in this solution space just because we want to be purely in this first principles, problem-first way of working. And this doesn't mean, of course, that you never come back to the problem. My point is just that it's okay to let your mind wander a little bit.

[00:14:06] And so, back to story time. 2001: A Space Odyssey. Someone watched that in Poland and thought, okay, this is pretty cool, this voice controlled stuff. They built something called Ivona that was trying to do these kinds of things, voice controlled devices. Amazon came along and acquired it and made that into the Echo. And then the Echo is sort of what inspired someone, alongside Star Trek, inside Amazon, who then went, actually, yeah, maybe this should be for more than just music and this should be for everything, and that's sort of how Alexa came about.

[00:14:47] So of course, along this journey there were many people who were, many in time, I'm sure, figuring out problems that this would be solving. But ultimately the origins of this were really not problems. In some ways it was really inspired by sci-fi to start with, which in some ways is essentially starting from a solution. Now, I think that's a great example.

[00:15:14] Another example is a personal anecdote. So this eesel thing that we ended up building, it's in the new tab, you can search across apps. It is going great and it was going great at the time as well. And we thought, okay, what if there's a way to create new documents from this new tab as well? It was totally just an idea that we had in one of our casual coffee chats, and we thought, oh yeah, this is interesting. What if we could build some kind of automation engine inside eesel to take actions for a particular app?

[00:15:52] It just felt very intuitive, and really it was an engineering-first, engineering-inspired idea. And we did some light research on the problem to figure it out, to really get crisp on the problem, and then we ended up building it. And the cool thing to note is that there are at least some people now who find this idea of commands, a way to take actions from eesel, actually more valuable than the core use case of eesel, of finding documents by search.

[00:16:22] So I think it's another example of a place where I don't think a problem-first approach would have necessarily gotten us there, but letting our creativity wander in the solution space got us here. And so yeah, you definitely need to figure out if it's something people want, there's no doubt about that. But it's actually okay to let your creative mind wander for a little bit.

Lie three: if you aren't embarrassed, you shipped too late

[00:16:49] Now, this is going to be a particularly counterintuitive one, or controversial one, I should say. Of course, the classic saying is, if you aren't embarrassed, you shipped too late, right? Reid Hoffman has gone on to clarify this quote. But I think ultimately this really tends to get misused. I think the heart of the idea is that, oh yeah, you want to be lean, you want to keep tight scope, you want to start small, you want to not focus on dumb details, you want to just start learning and get something out the door rather than trying to perfect it, because that's always going to be elusively in the future.

[00:17:30] So it makes sense in theory, but I just think the tricky thing is in the fuzziness of the word embarrassed. What really does that mean? And I would actually flip it around and go as far as to say, don't ship it if you're embarrassed. In my opinion, the risk if you're okay being embarrassed is that you could potentially be shipping stuff that's just so bad that no one can really use it, and shipping it actually serves no purpose.

[00:17:57] The weak cupcake, the gooey cupcake, is shipping something where you're just not really confident it's going to be valuable. You're not sure what you're going to really learn. You're not really proud of it, but you just feel like you need to get it out the door because you're trying to apply this principle. You're trying to work towards getting it out the door rather than hesitating too much about it.

[00:18:22] But I think the key thing to keep in mind is that just scoping it down doesn't make it a cupcake. It still needs to be edible, of course. And it needs to even taste good. Perhaps it needs to be compelling enough for someone to try it, to change their habits and try it. And there needs to be some baseline value that you expect someone is going to extract from it. And so by definition, in my head, you shouldn't be embarrassed about that. You can be slightly awkward that it's not a wedding cake perhaps, but you shouldn't be embarrassed about that, because it's doing that one thing really well.

[00:19:02] So a great story here is from a side project of mine. So I was building an analytics tool for Intercom, and it was a one-click way to see some reports on your Intercom data. And we got to a point where it looked like this. It looked fine. It was okay. We were a bit awkward about it. I wasn't even going to tell my Intercom colleagues about it because I was kind of embarrassed by it. But I thought, whatever, I've got to ship it, I've got to learn and keep moving, I don't want to hesitate too much.

[00:19:30] But I was wrong. This is almost a gooey cupcake, because the way the charts work was really confusing. Like, I never really understood it and I was not really clear on what I was going to learn either. The users were defined as being seen in the last 60 days. Churn was defined as not being seen in the last 90 days. All these kinds of implicit definitions were floating around the app. It was just not really usable. I don't really know what I was planning on learning from it. I felt like I had to get it out the door, but it's silly to have done that in hindsight, because ultimately I had to take a step back and question the data model some more and land on a place that was a bit more usable. And it's of course not a huge success story anyway still.

[00:20:12] But my key thing here is that ultimately, whatever you're getting out the door, you need to have reasonable belief that it's going to deliver something of value to someone, and you need to have some clear understanding of what you're going to learn. And there's nothing to be embarrassed about when it comes to that. It may not do much, but it really needs to do something well.

Lie four: people care about your app

[00:20:42] Cool. So another classic PM 101 way of thinking, I should say, is thinking that people care about the app that we're working on, right? We think that people care, they have this kind of relationship with the product we're working on, they have affinity with the brand, when we release something they're going to care to try it out. And of course the sad reality is that we are spending five days a week, eight hours, on it, but that's a focusing illusion. However much we think the product is important, it's not the case, usually. It's the center of our working world, but it's certainly not going to be the center of everyone else's world. They've got lots of other things when it comes to their work and outside of work as well.

[00:21:32] And the key thing to note here is that when we misunderstand this, we do stuff that just doesn't make sense. We expect people to try and switch over to our product when we ship something. We expect them to invite their teammates when we ask them to, but actually they're going to be awkward about that. We just expect them to care, essentially, about what we're up to. But the sad thing, or the harsh reality rather, is that they just have problems. Users just have problems that they're looking to solve, and really the product that we have is just a means to an end to that.

[00:22:04] And I think a great example here is with my time at Intercom. So we were, for the longest time, positioning Intercom as this customer communication platform, this interface to all of your interactions and touch points with Intercom, whether it's support or sales, marketing and so on. And in Intercom we loved Intercom. We used Intercom for everything. It was really the heartbeat of the company.

[00:22:35] And of course when it came to talking to some users in particular — we were talking to sales teams at the time — hang on, they've got Salesforce, Marketo, Salesloft, LinkedIn. These were the apps that sales teams were running off, and Intercom was kind of just that thing on the side. It was just this web chat thing on the side.

[00:23:02] And to an extent there are two things here, right? To an extent it's on us to educate the market and explain, hey, Intercom can be a bigger part of your working life than it is right now. But to an extent it's also just accepting the reality of all of these other tools and finding a world where we fit into these existing workflows. And we kind of did both. So we deeply integrated with Salesforce, also Marketo, we built landing pages specifically for these. We really accepted the reality, essentially, of these key foundational-level apps. And we also started educating that, hey, we are the messenger that you've come to love but we're also other things, you can do bots and apps and product tools and all those other things with Intercom too. And so it's essentially understanding people's reality and bridging to the world that you do want to make.

Wrapping up: nuance is key

[00:24:00] Now, I do have another product principle, but I'm mindful of leaving some time for questions, so I might just skip over it. Just to wrap up, let me just skip past that.

[00:24:14] Just to wrap up, I think this is an interesting thing to point out. I came across this tweet from Brandon Chu. He's a great product leader, where he was talking about how swinging the pendulum, going from one extreme to another in leadership style, is really one of his most favorite operating principles. And almost days later, I was listening to a podcast from Paul Adams, another great product leader, where he was talking about how you should avoid pendulum swinging. And I just think it's amusing to get that. Of course, there's a lot of context in which these people are sharing these things, but it's just amusing to have two great product leaders sharing the opposite things of each other.

[00:24:56] And I think it sort of is a great way to wrap this up. Nuance is really key. Sometimes we tend to be misapplying the 101 concepts, and sometimes they actually just don't apply to begin with. And ultimately I think you need to sort of build your judgment of this over time and trust that you do know best. But cool, yeah, happy to take some questions if there are any.

Q&A

[00:25:25] Host: Excellent, thank you very much. I really enjoyed that presentation, because you gave, for me personally, really good examples of what you meant in each case, so it really kind of hit home. So thank you for sharing that. And if anybody has any questions out there, please do post them on whichever platform you're using and I'll put those questions to Amogh.

[00:25:46] Host: But I'm going to kick it off with a question. I've got a few here, but actually the pendulum one just struck me at the end there, so I'm going to start with that, because I can think of the negative reasons why somebody would be unpredictable and you don't know, are they going to react in different ways. So what's the positive of what was the explanation that could be a positive for doing the pendulum leadership?

[00:26:11] Amogh: Yeah, so to be honest, I think it's been a while that I empathized with the other point of view as well. So basically my intuition is sort of to stick with what you're saying and keep things more predictable. But I think the main thing is that you tend to go in cycles as a company, and it's almost like you should accept that you're going to go through cycles as a company and you should swing the pendulum to acknowledge that.

[00:26:44] Amogh: So let me use a concrete example. Let's say you have a problem with a project because there were dependencies that weren't in sync, and so you go, oh, these teams need to do a better job at staying in sync, let's add meetings for these teams to stay in sync more. And you'll have meetings to stay in sync, regular catch-up calls, that'll pile up, and then at some point it's going to be like, oh, actually maybe we can go async with these calls, and then at some point you'll actually stop having calls, and then at some point you're going to be back to square one, like have some problem that shows up.

[00:27:24] Amogh: And so the way I think of it is that we tend to go in cycles like this, and I think swinging the pendulum is sort of, in my head, acknowledging that and oscillating to that one extreme to take care of that problem, and then oscillating to the other extreme to take care of that problem, and kind of acknowledging that you're going to have to go back and forth.

[00:27:42] Host: There was a great — I can't remember what company said it, but the founder likes to do reorgs as a muscle-building kind of experience in the company, to kind of every so often, when he thinks it's becoming kind of stable, he'll do a reorg to kind of get people used to change and make sure that people aren't kind of getting stuck in a rut. Which is an interesting theory, but it seems to work for them.

[00:28:09] Host: The other one, I guess, is just the Echo example that you gave. Amazon have kind of publicly said now that they're struggling to find any way to monetize it and they're not sure what to do. So it's a technology that's like, yeah, it's cool, and oh, people want to use it, and it's actually a good example of people wanting to use it, because sometimes you might build a technology that people don't want, but then they could find a really good monetization. So what's your tactic? Because I remember you saying in your example, okay, let's dig into the problem to make sure we're not just building technology for technology's sake. But how do you look at the business side of it?

[00:28:47] Amogh: Yeah, actually I might just share my screen again to show my slides. Are you able to put the slides back on quickly?

[00:28:59] Amogh: So yeah, I think this actually touches on one of the points that I didn't get to make. But I think ultimately, when we are prioritizing and when we're picking up things, we need to stay grounded on problems. And so I think that almost comes as a caveat for everything. So the way I think of it is essentially, it's okay to start with the solution, it's okay to think that, oh, there's this strategic opportunity that's interesting for us to look at, because there's a new technology that's come and now that's enabling this kind of interesting use case. And like you said, it's interesting, but ultimately you need to stay grounded on problems, because those are the least abstract concepts.

[00:29:41] Amogh: Everything else is kind of this made-up thing that we create in companies, but problems that people have are just this foundational truth that you discover them, you don't create them. And so yeah, the short summary, because I'm mindful of time, would just be to say that ultimately you still do need to come to that foundation, and just starting with the solution there, with technology, isn't enough.

[00:30:10] Host: Excellent. But yeah, so thanks for sharing. You're right, we are just slightly over time actually. But thank you very much for sharing, I really enjoyed that. And if anybody has any other questions, just keep sending them in, and what I'll do is I'll put those to Amogh on the Slack group. So thank you very much, Amogh.

[00:30:27] Amogh: Cool. Thank you.