Building Category-Defining Products across Kindle Fire, Twitter, Box and Amplitude with Ibrahim Bashir

Foreign. Today on 0 to 1, I'm joined by Ibrahim Bashir, product executive writer and a speaker with over two decades of experience building platforms, scaling teams and launching category defining products. He's had products at companies like Twitter, Amazon, Amplitude and Box across everything from infrastructure and internal developer tooling to enterprise SaaS and analytics. Beyond his operator experience, Ibrahim has also become one of the sharpest voices in the product world, offering practical insights through writing, speaking and mentorship that helps PMs at every level think more clearly about the craft. Ibrahim, thank you so much for joining me.

Yeah, thanks for having me, Roman.

And we'll start with your journey. I'd love to understand just a bit more about sort of what drew you into building products and how did your early experiences, especially at companies like Amazon and Twitter, really shape your view about how great, what great product leadership looks like?

Yeah, I mean, what drew me into building products was, I mean, over the years I figured out I'm what you call a systems thinker. So I'm always intrigued by how all the different puzzle pieces fit together. And you know, at the simplest level, that's how you sort of design a system as an engineer. Right. So when I was engineer that that skill kind of parlayed itself into thinking about the end to end system. But at some point I realized like the code was just one part of a larger system. And how do you get distribution? How do you position this, how do you price it, how do you package it, what audience is it for? Those questions are also really interesting. And so what organically drew me into product building was just this curiosity around how ideas get conceived, productized, brought to market and then commercialized was all fascinating to me. And so I, you know, I went from an engineer to a tech lead, to a manager, to sort of an architect role to sort of a consulting arm to eventually product management. And then I think you also asked sort of how I sort of take that experience from companies like Amazon into my product building. You know, we're all a product of our environment. So, you know, my first exposure to product management really came in the Amazonian culture. And so I would say some of that ethos that I carry is data driven, customer obsessed, write things down, debate ideas. That's my version of product management. But there's many versions of product management that are quite successful. You know, some more intuition based, some less data based. Right. Some more about storytelling than deep analysis. So there's many ways to build successful products.

Yeah, it's interesting. I was actually just having a chat today around sort of data driven PMs versus kind of like more like evidence based PMs as well and sort of the contrasting views on that side there. So we'll kind of dive into that as we go through. But you've obviously operated at every level so you know, from 0 to 1 and then you know, 100 million plus scale across B2B SaaS platforms infrastructure. If you're joining a new product org, what do you look for to know whether it's that company's and that org is truly set up to succeed?

I mean there's, there's many facets to that. The first thing I try to look for is just an understanding of where the product is and where you're trying to get it to. Because success or failure is so much in hindsight, right. You know, you might be trying to grow a particular metric or capture a particular audience, but if that's not what your leadership team thinks is supposed to be happening, then that's not quote unquote success. Right. So one is I just sort of try to articulate this is what I think success looks like. Two is I look for whether the powers that be agree with that version of events. Right. So for example, if you come in and think hey, the best thing I can do for this company is to drastically improve retention rates, but they actually believe it's incremental revenue, you know, you're not working in the same direction. So that's the second thing I would say in terms of other pieces of success. I try to understand where there's friction in the organization and how you might combat it. So if it's like, hey, we're not data driven enough, is there a belief and a buy in on introducing a more data driven culture, data engineering, data science, things like that. Right. Is what I also look for. And then the third is just trying to understand what kind of product operator they're looking for. Some people look more for a visionary storyteller. Some people focus on improving the craft of product building. Some product roles are really about the operations of eng product and design as a system. And so making sure that your skills line up with what is needed at that juncture is important. It's another way of saying I try to avoid replicating the same playbook in role after role because that's not really what's going to succeed.

That's interesting. I think I just want to focus on a particular time in your career. So when you're at amplitude, you mentioned obviously around sort of the center of this shift from a single product to a multi product. And this is a really fascinating concept. But what were some of the overlooked lessons product teams need to understand when trying to scale from single product to sort of a multi product organization?

Yeah, there's a lot, but a few I'll share with you. The first is I think there's this tendency to think of the different product areas you're in as discrete businesses. So for example, you might say, oh, you know, our original product is business A and then we're introducing this new product and it's business B. And when you talk about it as a business, you start comparing yourself to the market and the competition and standalone solutions. But the reality of being multi product is you're going to be sort of a mile wide and an inch deep, right? You're going to show up in a lot of different categories, but you're not going to have a full solution which sounds like a disadvantage. But on the flip side, you have to create an advantage by saying the pieces that we're going to choose to build from these different product categories are better together. Something that I call one plus one equals three. And so I think that's the trap a lot of companies fall into is they invest in a new product area, they look at best in class and then they try to replicate as much of that as they can. But that's just a me too product, right? And so you need to actually identify how you can layer in that product into the product you already have. Because you're not starting a new company trying to sell that product from scratch, you're layering it into your existing product and your existing go to market motion. That's number one. Number two is I think a lot of PMs specifically overlook the distribution and commercialization angles of it. So when a company is introducing a new product, it's not even you're starting from scratch, you're actually starting from a deficit. Because everybody has been trained to look for a particular type of account and a particular type of deal, particular set of differentiators, so they're hyper attuned to that core product. And so when you're introducing a new product, there's almost not enough brain cycles on everybody's part to understand how to sell this new thing. So you got to make it drop dead simple to identify, qualify and commercialize every opportunity. And I think the product leader actually has to be the one thinking through positioning, pricing, packaging, enablement. And a lot of times they don't, they think I just need to build a good product and the rest will sort itself out. And that's absolutely not a recipe for success. And then the third thing I would say is be very particular about the success metrics. Most new product endeavors are tagged with an incremental revenue number, but that's not always the right metric. I've built new products that have improved retention. I've built new products that have driven a free to paid conversion story. I've built new products that have improved margins or created pricing leverage. And so I think being really intentional about, hey, when we introduce this product, we expect to improve attach rate or retention or see new error and is very important versus just one metric to rule them all.

And when you think about your career, you've done a lot of sort of zero to one products as well. What is the year of your career? One product that really stands out for you and that could be maybe the impact, maybe the actual product itself, like the market you were in. And why does it stand out to you in particular of your career?

Yeah, I mean you can see it behind me on this bookshelf. This is one of the first Kindle Fire tablets off the factory floor. I was one of the product leads on that. That one really stands out to me. I mean it was a true 0 to 1. You know, it was the first tablet that Amazon introduced. The thing I really liked about it, it was a real solid exercise in strategic execution. So if you were sort of a company saying, hey, we're going to launch a tablet to compete with the iPad, you might get caught up in the hardware or even some of the feature set. But at Amazon we had certain advantages that we brought to bear. For example, we had a subscription service like prime and we're like, we're going to use that to give people access to digital content on day one. Right. So basically you don't have to buy or rent anything. You have a library that you can from. We had a prime piece of real estate on the Internet. The landing page on Amazon.com we're like, we're going to use this to sell it. Another advantage of the devices is integrated into all the digital stores. So there's a Kindle store, there's an Audible store, there's a music store, there's a video store. So you're buying it on an E commerce website and it's a vehicle for purchasing more digital commerce. And so it was like a flywheel connected to other flywheels. And it's interesting, you know, a lot of times people are starting from zero and trying to create momentum. And we took existing momentum and Actually stitched it together into one consumer electronics device. So I just, I thought it was a really interesting like MBA case study on how you can successfully launch a tablet and kind of go from a non entity to like a real player in the space very quickly.

Yeah, that's awesome. I think that the Kindle is one of the coolest products. I have so many friends that use it. So what is one trade off that, that you could say that people wouldn't know about, that you guys had to sort of make just one. That kind of comes to mind because I was fascinated by how these products could have come out differently. But why was it that you made the choices that you did to get it the way it came out?

Yeah, I mean, I'll share a trade off that was publicly talked a lot about, but it wasn't perceived as a trade off, it was perceived as a feature gap. So you know the Kindles for a long time and still don't have true page numbers like a book. Right. And one of the things that Barnes and Noble with their Nook was able to do was have page numbers for certain types of content. And we would get hit all the time with well, there's not real page numbers or there's not real page numbers. And sort of the reason we kind of ignored that feedback was we just had a strong belief that we were not replicating the book experience. We were creating a new type of reading experience. So while there absolutely was a segment of consumers who were like, well, I don't like the fact that there's not real page numbers. Their issue was not a Kindle vs. Nook vs. Kobo issue. Their issue was I don't understand digital reading. Right. Versus within the digital reading sphere. We're like, well, we've built a bunch of features like syncing across Kindles audio and digital reading syncing. And so we actually believed in differentiating in a completely different way and we just kind of ignored that feedback about page number.

That's interesting. Thank you. One thing, I saw a post recently about product sense and how it's ready mentioned in sort of job descriptions. It's very insightful to be honest with it. It's something that definitely isn't mentioned a lot, but it is obviously one of the most important skills. How have you developed your product sense over the years and what advice would you give to PMs looking to sharpen that intuition?

Yeah, the first thing I would say is don't beat yourself up too much. If you feel like your product sense, your product judgment, your product Intuition is not as sharp as it could be. Or if you're sort of envious of people who seem to have it really nailed down. I would say earlier in my career I fell into this trap of believing that some people, quote unquote, had it and others didn't. And then over time, what I realized was people with really good product judgment were just keen observers of user behavior and really collected breadcrumbs for some amount of time and then were able to share those insights later in a situation that mattered. Right? And so my advice to people who are like, I want to get better at product judgment is get better reps, higher quality reps, observing users in the wild, right? Take notes, connect ideas, validate them, ask questions. And you have to do it in a sort of Socratic, non biased way. But I think the more time you can spend on the ground observing real usage, the more your judgment is going to get sharper. Which is ironic because as you think about it, product leaders are the furthest away from spending time with direct users. And so they have to make a lot of decisions relying on product judgment, but they don't have firsthand experience. And what that really does is it puts them in a position where they have to make judgment calls about whose interpretation on the ground is more accurate. Is it the sales team? Is it the demo engineer? Is it customer success? Is it Support? Is it PMs? Is it researchers? Is it data scientists? And so I really believe, one, you got to hone that muscle for yourself. And two, you have to get good at understanding which of the myriad of sources of feedback are high quality versus low quality. And it takes a minute in every product or organization to figure out, oh, this signal is better and this signal is noisy.

I see. So it's kind of different depending on the company that you're in.

It absolutely is. I mean, there's some tried and true things. For example, your professional services, if you're in B2B products, will always have good ideas for how you can improve activation and adoption time because they're out there manually doing it, right? Your customer success team will always be able to answer the question on why don't you have more power users? And they'll quickly tell you, well, this workflow is broken, right? Your support team can always find IROI bugs for you to fix. So those things are always true. But then there's some noisier signals, right? Like an enterprise sales team can lead you on a wild goose chase if you over index on them. You know, you have analysts covering the space who sometimes are very good, sometimes maybe don't know the space as well. And so you kind of have to calibrate all the different feedback sources as you go through it.

Yeah. And I guess it's like a muscle memory that you build over time to sort of establish that you've obviously, as you know, we discussed that you've shipped so many products from 0 to 1 and led sort of large scale transformations. When you're assessing whether a product bet is like worth making, what signals do you look for and how do you sort of separate the noise from the actual insight? I think this is particularly relevant right now in the world that we're seeing right now with AI and there being a lot of noise. But how do you, what is that, that gap for you that where you're able to tell?

Yeah, you know, it's interesting. I prefer to look at it from a problem prioritization versus a feature prioritization lens. Because if somebody comes to you and says, should we make this bet? Yes or no? It's an artificially oversimplified question. What you should be looking at is what are the problems we think we need to solve? Which of those problems does this solve? And is this the highest leveraged version of a solution that I can come up with? Because saying yes to a bed, you might be saying yes to the second or third attempt to solve the same problem, when in fact you should be solving other problems. Right. You might be saying yes to a wild swing when you have a much more high viability idea. Right. Or you might be saying some yes to something that's very incremental and doesn't really move the needle. Right. And so I think you always have to contextualize the best to say which problem does it map to? What else am I trying around that problem? Is that a now problem or next problem or later problem? And is the bet coming up now because the solution path has materialized. So to your point about AI, I think a lot of those bets are interesting because it's like, is it solving well known problems and kind of just polishing the solution or is it allowing us to go solve problems that we historically couldn't? And I think that's the more interesting unlock is, hey, we historically thought this is a one month exercise, now we can do it in a day. Those are much more interesting than this is a beautiful part of our product and it becomes slightly more polished.

Right, Yeah, I see what you mean. And then if you were just looking at your time back at sort of box and amplitude, what was Some of the hardest product decisions you've had to make when balancing long term platform investments with near term sort of customer needs.

Yeah, I would say the hardest decision, you know, when it's like ideas that aren't grounded or random or distractions, it's actually easier to say no. It's harder to keep saying no because there's usually one person advocating for it. But those are not difficult no's, Those are not difficult decisions. They're difficult sort of implementations. Right. But I think the really difficult decisions are good ideas that haven't quite gotten traction. And then you really have to make a decision on how much do I keep going and throw good money after bad or it's time to pull the plug and you know, it's human nature. You want to believe one more quarter of pushing this might lead to some real results. And I've seen that happen. I've seen, you know, people are ready to call it quits and then you just give it a little bit more time and then it finds exit velocity. But then there's also plenty of examples of like, yeah, it kind of became a money pit. Right. I would say those are some of the hardest decisions on. This is not a zero. It has a real traction. There's a cohort of customers that really value this. But what is the opportunity cost relative to the other things we can do? Right. And what is the cost in terms of all the cross functional folks? Because you know, a lot of times a team will say, well, you know, we have enough staffing to build it and maintain it. It's like, but we have to position it, we have to price it, we have to enable around it, we have to train for it. There's a support cost to it. So you have to really think about that total cost of maintaining a feature and the ones where it's not a obvious zero, but it's like doesn't compete in the grand scheme of things. Those are quite painful because you're like, there's some, there's something here, but it hasn't fully materialized yet. And those are hard to kill.

And you've written and spoken a lot about the, the importance of narratives in product. How do you use storytelling to align teams, especially when you're introducing something new or controversial into the roadmap?

Yeah, you know, the first thing I do is, you know, I mentioned earlier, anytime there's a bet, I try to understand which problem does this solve. That's the beginning of my storytelling technique is this is a problem in the market, this is a problem that is worth solving for customer X at price point. Yes, for reasons Z. Right. So you've established that it's a problem. Yes or no? It's worth solving. Yes or no? Can we build a differentiated solution? Yes or no? And do we agree this is what that solution looks like? Yes or no? Right. So you're sort of. It's almost like Russian nested dolls of truth that you start to layer in. And I also believe in tell the story once and use it multiple times. So if you've gotten a really crisp problem on, if somebody's like, well, why are we building feature X? You're like, feature X solves problem Y for customer Z at price point A. And that matters to us. That narrative should be used with internally with engineering and design to get alignment internally with sales, to help them qualify accounts, externally with analysts and whoever's covering your space. It should show up on your marketing website at different altitudes with different verbiage. But like the core story stays the same. Where I think companies fall into trouble is they have one meaningfully different story internally to align people. One meaningfully different story for the go to market team. One meaningfully different story for the market. And eventually that Venn diagram of overlap but not quite bullseye will bite you because people will say, oh, I thought we built it for reasons X, but I'm selling it for reasons Y. And there's an expectation of reason Z. And then that sort of overlap but not quite tight fit is what really drowns product organizations.

It's interesting. Yeah, for sure. I think it just, it's kind of like the difficult part is getting that right and having that correct storyline internally when you know, we've done a lot of things around sort of internal developer platforms and then sort of external ecosystem plays as well. When is it worth building for extensibility and when is it just a distraction?

I'd say a couple of things. I mean, you know, my last decade has been focused on SaaS products. Extensibility is just a ground expectation of most SaaS products. Baseline extensibility, like hey, your reporting capabilities aren't going to be perfect. So I want to export to CSV and style it in my way. Hey, I'm going to sort of need to do some data processing at a non human scale. So I need an API to export certain things.

Right.

So there's like a baseline level of extensibility. The second thing is you got to decide whether you're going to go the last mile with your product or with an extensibility story. What I Mean by that is, hey, look, generally if your tech stack is ABC and your Personas are xyz, the product works. But if the tech stack is slightly different, or if you don't have all the change management agents we require or some of the bells and whistles in the product, well, then how do you close the gap? Is it partners? Is it professional services? Is it do it yourself? And that's where extensibility comes in. And so I always try to tell people, you gotta be self aware about between your product and a truly deployed customer. Is there a gap and are you gonna participate in filling that gap? Right. If not, people will build things around your system. And there's absolutely SaaS products, which is like extensibility is about network effects and not about closing the last mile. Like I think of something like Slack, like there's no debate about the product solves what it says it's gonna solve. Right. But most enterprise products, it's like you're expected to do some configuration because your workflow is just not consistent across enterprises. Right. And so that's what I think about extensibility. Now your question may be more around. It's the kind of thing that can give you a network effect advantage if people start building around your product. But how do you know when it's the right time to build versus you set up kind of a developer ecosystem and then nobody bites. Right? Because it is a cost to build and maintain. I don't know that there's a scientific answer. There's more art than science. If you see customers or the ecosystem attempting to do certain things and you see an opportunity where that can become part of your mode, I'm a big fan of trying it. Right. And seeing if there's sort of a mutually beneficial model that can be built around it. But it's the kind of thing where you can't really half asset, right. It's like you really have to believe and buy into it. So I think it requires a really keen understanding of are there builders in your product ecosystem who could take advantage of it? And that really comes down to knowing your Persona. Because if you're like, yeah, look, we have this amazing extensibility story, but there's no development skills in your target audience, that's not gonna work. But you know, in this day and age with no code really starting to come to fruition, I think extensibility is gonna become a core part of every SaaS product story.

That's awesome. Yeah, I think I'm excited to see that sort of trend go through when you think about, I'll go back to AI a little bit, but really around sort of augmentation for PMs. How do you approach AI as a problem solving tool rather than just kind of a shiny object? And what advice do you have for PMs trying to build in this space, but then also using it to enhance their own development for building?

Yeah, I mean, I go back to the comment I made earlier. If you deeply understand the job to be done, the workflow, and you can say, look, this is a piece of the workflow that could be automated or simplified or improved. Look at AI as one of many tools in the bag to do exactly that. I think where AI is interesting is what you may have considered historically. You know, this is a problem that we're not going to get traction on. It's worth revisiting that. And you know, so many products, people have lost the plot on the original thesis. They're like, they're deep down one solution path and so they can't really come up for air and be like, well, what is we're trying to solve? Because you start to believe the thing you're shipping now is that's the essence of it. And so I think one important exercise is to lay out the assumptions of this is why we built the product this way. And we may be one, two, five years into it and hundreds of millions in ARR into it, but it's worth revisiting all those assumptions and going back and saying, has something fundamentally changed? Because that's exactly where your competition is going to come from, is going to come from somebody who doesn't have that same sort of closed mindedness coming in and saying, oh, AI can help me just fundamentally do this. I mean, I'll give you an example. You know, one thing I've written about before is this idea that all SaaS products essentially skip a step. And until they show you that step can be skipped, everybody assumed the prevailing wisdom is it's not right. So for example, the example I always like to use is DocuSign. Until DocuSign came along, people were like, well, the way we do a transaction is I email you a file, you print it out, you sign it, then you scan it and then you send it back to me. And people are like, that's just how it has to be. And then somebody eventually was like, I actually think technologically you could digitally sign this, right? And save all that back and forth. And now people are like, obviously right. Or a simpler example is maybe you've used this screen recording product Called loom. Right. It kind of records as, it kind of shares as you record. For a long time it was, you would record, store, locally, upload and share. And then they just kind of were like, no, you can generate the shareable asset as you record. Right. With some technical wizardry. And so I think of AI as that, except its applications are much more numerous and broad than those simple innovations. So that's number one. The other thing is you mentioned shiny objects and you know, we all try to avoid chainings chasing shiny objects, but occasionally there are distribution benefits to shiny objects. So I'm not saying go build and chase a shiny object, but if your thing is shiny and it does use AI in a thoughtful way, why not use what's happening in the market to get on that gravy train? Right? So for example, if people, you will find buyers right now saying, we don't have budget to buy anything, but we have an AI budget, we've been told to be AI first. And so it is something you should position against at a minimum. Which is why every company is now claiming to be like an AI first solution.

Yeah, it's, you definitely see that a lot more now. But one what would be really good to understand is obviously you've coached a lot of PMs and also like heads of products and other product leaders. What's one misconception that you see strong product ICs carry with them when they step up into their first sort of product leadership role? There's obviously going to be a lot of people like that in the moment. What's one thing that you commonly see?

Yeah, I mean, my answer is it's consistent across any ic. Becoming a manager, which is your excellence at the individual craft is not going to make you a good manager. Right. And so I think that's a trap a lot of people fall into is they're like, I need to be the best PM across all the product work that everybody on my team is doing. And it's like, but A, no you don't and B, it's not going to work for you to try to scale to that degree. You can't go broad and deep on everything at the same time. Right? So that's anti pattern number one. Anti pattern number two is I think even smart people who intellectually understand that it doesn't prevent them from offering a lot of opinions and criticism of products and solutions that they don't understand. And it can be quite sort of counterproductive because what ends up happening is the people who really understand the ground truth. And are building thoughtful solutions then get whiplash. And it's like, okay, maybe we're not thinking about it correctly or maybe we need to sell it better. And then they start spending a lot of time on things that aren't just building the best product. Right. It's things like, okay, redundant storytelling or trying to convince the powers that be. And so I would say one is you're not expected to be an expert on everything anymore, and B is because you're not expected to be an expert on everything, you should consciously not chime in unless you have a strong, thoughtful point of view. And so, you know, every time I'm in a product leadership role, I try to make sure I'm like, be judicious about where you're going to put, but if you just kind of push constantly on everything, you're just going to burn people out.

Yeah, that's, that's really good insight around that. And I think just moving on, like, this is my final question for you. If you had one, one sort of lasting piece of advice for the next generation of PMs, you know, PMs, product leaders, what would it be and why? And this could be tied into the way you see the world moving, especially the tech world and the way we build.

Yeah, I guess my advice would be really about product learning. I think product people, more than any other function, tend to write, share and consume reflections around the craft of product building. So I mean, you know, my LinkedIn is littered with, well, here's how I'm building, here's how I'm shipping, here's how I'm researching, blah, blah, blah, and it's, I appreciate it. I mean, I've learned a lot from these things. But the thing I would advise people to sort of wake up out of is there's too much. This is how Company X does it. Company X is successful, therefore we should do it. I can guarantee you the people at Company X who are successful never sat around and said, I wonder how so. And so company does it. They solved it for themselves. And so I just find it kind of ironic that people who are very self starter and don't follow the rules and are willing to experiment and try things when it comes to building or scaling or operationalizing, they tend to go look for permission from other companies to be like, well, who else is doing this? How might I do it? And I'm not saying don't ask questions or try to learn from your network, but you cannot copy paste. And I think that's destroyed so many product works. Is People are like, well, this is what Google's doing, this is what Meta's doing. But it's like, but you're not there and you don't have those advantages and you don't have their disadvantages. So you should design and build something that is unique to you. I'm not saying you always have to reinvent the wheel, but you have to sort of look at the wheel and say, is this wheel going to fit on our road, on our car? Right. And I think too many leaders come in and sort of like copy paste playbooks and I just, I think it's death.

Abraham, this has been amazing. So I just want to thank you so much for joining me. There's so many cool insights for insights you shared also stories as well. So thank you so much. Where can people find you?

Uh, yeah, so I write a newsletter on substack called Run the Business so you can find me there. I actually have built a digital clone of myself that you can find at Lemonade app. So lemon and then aid not so it's misspelled on purpose. Lemonade app. Try out my digital clone. And then, you know, I. I'm pretty active on LinkedIn as well, so you can always find me there.

Awesome. Thank you so much. Been a pleasure.

Yeah, absolutely. Thanks for having me on.

Thank you so much for listening. If you enjoyed this episode, please make sure to follow the show and share it with someone building something great. We've got more incredible product leaders coming up. See you on the next one. And keep building.