Esra Kucukciftci is a pricing and monetization strategy consultant that founded Pricing Innovations, a boutique product consultancy. Esra is the creator of Pricing Canvas™, and before founding Pricing Innovations, she worked in technology, e-commerce, and numerous SaaS businesses,
How I Work, Episode 25 with Esra Kucukciftci (Pricing Innovations)
Esra joins Josh Becerra in episode 25 of How I Work to explain why pricing doesn’t just mean “prices.” She talks pricing vs. pricing plans and further dives into the three components of pricing plans: structure, model, and window. Plus:
- Mistakes in testing: Focus groups, A/B tests, and Timing
- The Future of SaaS Pricing: Ecosystems and Recurring Revenue Models
- Creating models where they don’t exist: Systemic Transformations & Climate Action
Listen on Spotify and all podcast streaming platforms.
Learn more about Esra Kucukciftci and Pricing Innovations: https://www.pricinginnovations.com/
Explore more 100% free, curated content from leaders in the SaaS marketing community at https://augurian.com/saas-scoop. Or visit our blog or our podcast to find more digital marketing tips and ideas.
Want to learn more about Augurian? Listen to our core values or reach out to speak with an Augur today about your marketing strategy and digital advertising performance.
Transcription: How I Work, Episode 25 (Esra Kucukciftci, Pricing Innovations)
Josh Becerra: Hello everybody. This is Josh Becerra from Augurian. We’re filming How I Work. I’m super excited to have Esra Kucukciftci with me today. She is the Founder and Managing Principal of Pricing Innovations. Thanks for being here.
Esra Kucukciftci: Hey, good morning. Thanks for having me.
Josh: Yes, it’s awesome. When I think of pricing experts, you are the first person I think of. Can you tell the audience a bit about your story? How does someone get into pricing? Where does the passion come from?
Esra: That’s right. My journey to pricing was an indirect one, which I think what every pricing person would tell you is still not a major emphasis in any of the business curricula but well I actually started in chemical engineering.
Josh: Oh, wow. Okay.
Esra: Yes, and I did my time six, seven years in heavy industry manufacturing in various parts of the country. About 12 years ago now, I got my MBA here at Carlston School of Management at the University of Minnesota. During that time, I did my internship at Facebook. These were the early days of Facebook. It was really cool to be there at the time and that really shifted the trajectory. I was always in tech but it shifted to my trajectory into product and different kind of tech.
After MBA, I moved to Seattle, was the same product manager for Amazon for a short amount of time, and then after I came back again briefly, I did product marketing. In all of these product roles, there was something missing. A common thread was missing. The product people were figuring out what value to build and how to deliver that and engineering was developing that value, sales and marketing was communicating the value, and pricing is where it exchanges hands.
Josh: How you extract the value.
Esra: Exactly. Well, extract and also the delivery modes of that even. How is it going to be realized needs to be thought through. I realized that there is something missing and it was not generally or commonly understood. I really wanted to understand that and create some knowledge on that, so I founded Pricing Innovations about eight years ago. What’s really interesting to me about pricing is that it’s the most complete picture of any initiative, any solution, any offering. Because you have to understand the value that you’re developing, how differentiated it is, what it is solving, how your customers and buyers and users realize that value, where the gaps are in their perception of value.
You have to understand your microdynamics. You have to understand your competitors. You have to understand the domain. You have to understand where the future of the domain is going. You have to understand where your customers’ domains are going and you also need to understand your own FinOps, your BizOps your Sales Ops. It’s a very powerful truth if you get it right. It really tells you the full story because if people are not willing to pay for the value that you built, you didn’t really build it and it takes–
Josh: Right. You didn’t build it right, that’s for sure.
Esra: That’s right, and it really takes a lot to turn a good product into a good business, so pricing gives you that lens.
Josh: I think it’s super curious that you said this isn’t stuff that they really cover a lot of in MBA programs or in school, right?
Esra: Yes.
Josh: Because there aren’t a lot of pricing experts out there like you and I think that’s, now that I’m hearing you talk about it, it’s just like, man, why don’t people focus a little bit more on this because, in the end, success is determined by whether you get that right or not.
Esra: Very true.
Josh: You might be successful, I guess, you could potentially be successful at getting some value but are you maximizing that value?
Esra: That’s right.
Josh: I think that’s where the difference really probably is.
Esra: That really is, you put it really well.
Josh: Okay, so I feel like you’ve helped us define pricing a little bit and pricing strategy. Is there anything else? I heard some of that but is there anything else that you would say listeners should really be thinking about as a definition for pricing or pricing strategy?
Esra: Right. We get that question so often. I think the most important thing to emphasize or understand is pricing doesn’t mean prices.
Josh: I see.
Esra: Pricing is not about prices. When people talk about pricing or price testing, it’s like, “Oh, do I charge $39 or $49?” That’s not what we should think about when we think about pricing. Pricing, at the highest level, has three components. A pricing plan has three components. There’s pricing structure, pricing model, and then pricing window. The $39 versus $49 is what we call the pricing level.
A pricing plan has three components. The pricing structure determines what value or what feature sets, what benefit sets you’re going to offer for home. It’s really about aligning your offering with different types of buyers and users. Your pricing structure determines what the offering is, how it’s going to be packaged, structured, and how it’s going to be aligned with different types of buyers and users.
Pricing model determines your metric, in what ways the values is going to be realized. It’s in what ways that value scales. Is it a per user, is it per usage, is it per service level [unintelligible 00:06:39] type, whatever the case may be?
Josh: I’m just trying to make sure I’m getting this straight. The first one is you could say you have your first tier, second tier enterprise. The second is how many seats are available. Am I getting that right or am I–?
Esra: Yes, so–
Josh: This is complex- [crosstalk]
Esra: Yes, you knew it.
Josh: -so I’m just trying to make sure I’m getting it right.
Esra: Let’s dive in. I think the example that you’re going with is a good one. Let’s think individual, team, and enterprise. It’s three options, right, and it’s so relevant because everybody’s all about product-led and enterprise these days, so it’s a good one. The pricing structure would determine how many of those tiers you would have, to begin with, and the differences between your individual users, your team users, and enterprise users.
Josh: Got it.
Esra: One of the things that your pricing structure would do is, for example, you would determine what an individual user needs, how they use it, how much of those benefits they will need, and what needs to happen before they can invite their teams to collaborate so that they can all move into the team plan. The key here is that an individual user shouldn’t need to upgrade to the team plan to use more of what they need as an individual. That’s one of the mistakes that we see.
“Oh, if you want to use more of this individual plan, upgrade to the team plan.” Well, what if the person needs more of the benefits but doesn’t need the team features or collaborative features? What if it’s a developer who just needs more resources in that individual plan, right?
Josh: Yes.
Esra: Your pricing structure determines who needs these benefits differently, how much of them, and the delivery mode of those benefits.
Josh: Got it.
Esra: If your team uses this solution together collaboratively, the way that they would need the solution is different. Your pricing structure defines those differences between how an individual would need the solution versus a team would need the solution, and put the fences between those two plans. In general, we refer to them as caps, fences, and triggers.
Caps determine how much or what the entitlements are for each level. Fences determine what is different between the two and when a person moves from the other, or a user moves from the other. Then triggers are the features in your platform product solution that actually are a surface for the behavior to take place.
Josh: Got it.
Esra: In digital, nothing happens without a trigger. To wrap the structure bit towards the enterprise side, so your pricing structure also determines how that scaling happens, the scaling of benefits happens. Moving from individual to team, and then how teams move into an enterprise level usage are all determined by what’s included in all of them, and how that moment is going to happen. Your pricing model determines the metric of monetization. If it is individual, team, and enterprise, your first hunch would be, “Oh, then it’s for per person.” Well, it’s not that obvious, actually.
Josh: It doesn’t have to be.
Esra: It doesn’t have to be. It could be usage, it could be consumption of resources, it could a metric that goes with one of the features or feature sets. The pricing model determines how that is going to scale across your plans. Then finally, your pricing windows determines how each of those plans will align with willingness to pay of those users.
Like, for example, let’s say team plan, there are five people teams and there are 500 people teams. How is that going to be scaled? Is it a pricing model question? Finding their willingness to pay for different sizes of teams and how those teams collaborate, and how much they benefit from it, all of that is a question for the pricing window. Just to wrap it up, when we say pricing, we’re talking about a lot of different things, and the pricing level or price point of an offering usually is the least important bit.
Josh: It is amazing to hear you talk about pricing. Again, I come at this from like, wow, maybe we should charge $10 more, and now I’m understanding the level of complexity. When you are first engaging with a client, or maybe you’ve finally done your due diligence with a client and maybe the industry, are you someone who is an advocate for testing different strategies? What does testing pricing strategies look like for you?
Esra: You have to test and validate. How else would you know, right? Some of the pricing mistakes can be fairly public. I mean, HubSpot had a major snafu last year, they had to publicly pull back their pricing, which I thought was amazing that they did that publicly.
Josh: They recognized that–
Esra: They recognized, they said, hey, what’s up, and we’re retrieving it back to the old plan, and then we’re going to keep working on it and let’s work together, which is the right way of pricing communications, honestly, but some of these pricing mistakes can be fair to the public. You want to avoid that if you can, that’s why you want to test it. The best thing about price testing is that you can test pretty much anything and everything about pricing before writing a single line of code. Because the pricing, you’re testing the value, you’re testing the perceived value, you’re testing how users and buyers think at the point of decision. Those are the things that you’re testing.
You’re testing their relative thinking in relation to all the other references they’re thinking when they’re making this decision. Those are the things that you’re testing and you can do that without necessarily having a product, before having a product. You can test it with concepts, you can test it with mocks.
Josh: Is that like focus group testing or is that like AB testing? Send part of your traffic to a website page that says this is how much it costs and the other, like, how does that actually look in the real world then?
Esra: Thanks for asking that. Absolutely no on focus groups because–
Josh: Because people will tell you what you want to hear or?
Esra: Yes, if you believe what people will say, they’ll do, you’ll end up building their own company. We say that fairly often. When you think about how you acquire a solution or try a solution or buy a solution, you don’t do that in a group setting. It makes no sense to introduce that solution to you in a group setting. You could be influenced by other people’s value stories and then that will shift your thinking, but when it comes to you making that decision, purchase decision, or trial behavior on your own, you’re thinking within your own context. Sharing context with others in a testing environment for pricing makes no sense.
Josh: Bad, bad idea. Bad idea.
Esra: Bad idea, so we don’t do that. The other bit that we don’t highly recommend which is probably the most common way of testing prices is AB testing. I have so many issues with that. I’ll just pick two.
Josh: I feel like every entrepreneur I’ve talked to and SaaS marketers are like, “Hey, let’s test this. We can do this AB test stuff,” so I want to hear, I want to hear this.
Esra: Right. One, in most cases, it’s flat-out illegal to sell the same thing-
Josh: At different prices.
Esra: -exact same thing at different prices randomly, or even worse, selectively. Like, “Hey, you’re a bigger account, let me quote you–” Enterprise deals so much goes into that negotiations. Enterprise deals are significantly more prone to like that pricing exercise, but AB testing, we’re not talking that– we’re literally talking about offering different prices– [crosstalk]
Josh: Users, yes, individual users, thing like that.
Esra: Amazon got into big trouble about that about a decade ago. They were charging different prices for the same thing to different people, and so on and so forth. AB testing, there’s that reason. There is that public, like every time you come back to a site if you’re being offered something else, it’s just a bad customer experience. The other part that I take issue with with AB testing I think is coming from my engineering background. I was a Lean Sigma engineer for long years and when Lean enterprise borrowed a lot of those productivity and quality fundamentals from manufacturing and lean, they skipped a step, which is the design of experiments.
They went from all those fundamentals of Lean and then skipped entire testing, which is design of experiments, and they landed on AB testing. AB testing is something that you use to refine things, not to test things. You already know what you need to know and you’re basically refining it for like literally cherry on top. Pricing, testing, or price testing needs to happen in a lot more sophisticated way with a full design of experiment where multiple attributes contribute to your decision and you see the effect of those attributes individually and together.
It’s a lot more complex how we make these decisions and purchase decisions and your testing needs to reflect that. AB testing tests one attribute at a time and it limits your learning quite significantly. What we advocate for is doing price testing offline and using a quantitative method. It could be a pair-wise choice testing, it could be conjoined, it could be these good choice simulations, it could be max stiff but in all cases, you actually want to understand not only the decision but also what drives that decision. Only in a more sophisticated quant method you get to do that. AB testing doesn’t really give you enough information about that.
Josh: That’s all very new information to me. I feel like I’ve definitely been on the like, hey, we can test that, like AB test that. We use data, of course, to help us understand which of those two things is outperforming but I do understand that you’re like only testing one variable at a time and that it’s more complex than that.
Esra: Very true. Very true. I’ll give you an example of how a more sophisticated method works. Conjoin is a good example. In a conjoin setting, you are first gathering information about that user. Those are usually the determinants of the user type, the segment type, or the benefits stack that a user aligns with or best aligns with. You’re learning a little bit about the user and then you are exposing the user to these tasks. There could be anywhere between 10 to 20 tasks, and for every single task, user is making a choice, their best option out of the options that they’re presented with. What this simulates is a real-world decision-making process that we deploy in our heads when we’re making this decision.
The way that those tasks are built is, every option has different set of features, different set of benefits, different levels of benefits at a price point. Every time you are making a decision, you are making that decision at that price point in relation to all the other options. This is very close to real-world decision-making for buyers and users. When you have enough presentations, when you have say 100, 150 people, you actually get to test 80 to 150 different things. Because of your design of experiment because of how balanced it is. Not only you’re learning a lot more attributes and their levels, you’re able to simulate, if I do this feature set, who would buy it, what percentage.
You can simulate the adoption levels per user type, per segment, per feature set. It just gives you this really, really rich way that a market is likely to adopt or how that market is going to receive that offering. It gives you a really clear understanding of who it is for, who it is not for, and what is likely to happen for each segment if they were presented with these options at this particular price point, and the price point is always presented as a window, so you can still test within that window, like–
Josh: Sure. 39, 49, yes.
Esra: That’s right. That’s what the AB test is for, and still, you want to do that offline, but you can do that at that point, but like the real simulation of that purchase behavior is a more complex process. It’s very similar to testing a full design process, rather than, like you should treat it like your testing, your design iterations, in a more complex and sophisticated way.
Josh: Cool, so we’ve talked about like no to focus groups. We’ve heard why AB testing is insufficient when it comes to pricing. Any other big red flags or mistakes that you see people making when they’re doing the testing?
Esra: Yes. I guess the biggest mistake is testing too late. Because what happens is that, hey, we built this feature, we built this product or solution, we’re about to go to market, we don’t know what to price, too late. What happens is that, and this happened multiple times with our former clients, when we test, we find out that perhaps another metric might work better.
For example, if you built for perceived usage and you realize that the adoption levels might be a lot higher for usage because let’s say users’ usage is cyclical or unpredictable, or variable for different reasons, right, that is an entire different product backend. That is like the way that you build for perceived versus per usage is your product analytics, your attribution, your metering, your cap expenses, and triggers, all of those things have to change so it’s a full reconfiguration of your stack. You don’t want to find that out too late. You actually want to build for that.
I think that when the processing happens is really critical and we call that monetization first product development, like build where you can monetize, but build in that way. For example, if you figured out your metrics skills in a certain way, you want to think of your plans and your benefits and your roadmap in that way. One of our clients, this wasn’t a pricing test, this was a full transformation, but so this enterprise software that we worked with a few years ago, they built this amazing new feature which enabled them to have single sign-on across tons of different integrations in an enterprise integration platform setting.
Their primary pricing metric up to that point had been per connection. Well, this single sign-on bypassed that entire thing. All of a sudden, you have to reconfigure with a different type of metric. What is it? Is it per usage? Is it resource consumption? Is it a data package? Is it a stream? What is it? First, you need to figure that out but they had like 500 pages of help documentation so this is major. You’d want to figure that out before you build that feature. You want to anticipate these types of things so the timing of testing is really, really important.
Josh: Okay, so timing of testing sounds like it’s also a big, important thing to consider. We have SaaS entrepreneurs and marketers here as an audience mostly and so where does the product market fit, come into the timing of that? It’s like, do we need to really think about pricing before we even get to product market fit? Do we get product market fit and then we do more of our pricing strategy? From a timing perspective, where do you see pricing being most valuable to engage in this type of testing?
Esra: Yes. Thanks for that question, that is a really important one. Where we stand is as early as possible from the concept because the only way to– Let me say this, your users and buyers differ more in how they need a benefit, how they buy a benefit, how they utilize and how much they benefit from it is a lot more so than any other segmentation criteria like per vertical, per company size, per you name it.
Josh: Sure.
Esra: You want to figure out what we call value stacks of different users as early as possible.
Josh: Got it.
Esra: That bit is really value research, not so much pricing research, but it’s value research. You want to figure out how the value that you’re going to deliver aligns with the needs of those different types of users and what their value stacks look like and how they’re different from one another. Let’s say you’re doing a proof of concept for an individual user, let’s say in a product-led setting, even if you’re building for one user, initially, if your vision is to scale it all the way to enterprise, you want to have an idea about that.
I’m not saying that you should know that from the get-go, it usually takes a decade or more to get to an enterprise play if you ever. However, you still want to have an idea of how value scales horizontally and vertically. What we mean by horizontal and vertical is horizontal scale is how benefits scale when users’ portfolio adoption grows. From one feature to the other, from one plan to the other, you want to have an articulation of that and you want to have that in the back of your head so that your roadmap reflects that like we were talking about reconfiguring the whole stack.
You want to know how value scales horizontally. You also want to know how value scales vertically, meaning, as you have more users in a single organization and more functions and more business units using the same solution, the way that they’re going to need the solution, adopt the solution, will be different, and how you will scale for that.
Think of Zoom and Slack, how they figured this out. They’re poster childs and everybody talks about them, yes, but the way that they figured it out was absolutely amazing. Going from that individual value into team value and then enterprise value, and now they’re doing amazing things with their developer platforms. Now, they really figured it out. They can monetize it so granular levels because now they have all the developer tools and such. You can do whatever with their platform.
Josh: The reason for that is because it was somewhat, premeditated is probably the wrong word, but they thought about it.
Esra: That’s exactly, yes.
Josh: They were thinking about like, “Where’s this going? Where do we want this to go? What do we want this to look like? Let’s try to project that so that we know that we can get there.”
Esra: That’s right. I’m sure they didn’t estimate that there would be a pandemic and things would scale at such level. I’m sure responding to emergent growth opportunity is as important as knowing that, but at least the building blocks of your solution is envisioned the right way so that you can keep expanding horizontally and vertically. To answer your question in a really long way, you just want to do it as early as possible, and you don’t really need a solution built to know that.
Josh: Sure.
Esra: You can do that through value research and early, and then you can build on that.
Josh: Awesome. Like I mentioned before, the audience here is a lot of SaaS. I think there’s a lot of different things happening in pricing for software-as-a-service companies right now. What do you think has changed? I guess I’m looking for what have you seen in, particularly, SaaS pricing that has either changed or where do you see the future of SaaS pricing going. I think that would be super valuable here.
Esra: It’s really interesting. What we’re seeing, in the last couple of years, at least, the change is happening on two ends of the spectrum, the product-led versus enterprise. People are starting to understand enterprise differently, as they should, because enterprise plays now what our ecosystem plays, and there’s a difference between an enterprise play and an ecosystem play. Enterprise play generally is a matter of scale, whereas ecosystem is integration and how your solution plays with others. How do you consume other solutions, how do you make sense, how do you play with them, and then how do you enhance other solutions for customers’ business process?
Making your products stack, technology stack, and your pricing work with how the ecosystem works is a really interesting problem to solve. That is really a big question that most companies are working on. On the other end of the spectrum, all these enterprise software companies are trying to get into the product-led game. They’re trying to see all the successes of small scale and then grow into the enterprise. They’re like, “Oh, we’ve been missing it on market.”
Josh: Let’s build the other way.
Esra: Yes, we’ve been missing all along so how can we make our product work for that single developer, for that single user for that single engineer, you name it? Those are two really interesting big shifts that are happening. Again, as we touched on earlier, these are not just how you structure your plan, this is how you structure your business. Because when you– Like one of our clients created this product-led platform that worked entirely differently but their sales team didn’t know how to sell that. They didn’t know how to, when to engage a user that continues to engage and utilize the solution to sell them to the next package, the next level.
It’s a big business transformation. It’s your products at back end, it’s your sales, it’s even your FinOps, your billing and payments infrastructure. What do you need to move on either direction? I think those are the things that are really interesting from a pricing perspective in SaaS businesses these days.
Josh: Got it. Anything around the future, like, is there anything that you see coming, either in SaaS or just generally from a pricing perspective?
Esra: I mean, I think this whole ecosystem idea is a really interesting one because when we talked about the dependency of product backend on metrics, what if there were dynamic metrics? What if your metrics needed to change depending on which ecosystem you’re playing with or are playing in? That’s a really interesting one. Usage-based pricing is evolving really fast. The way that we define usage is changing quite a bit. The way that we’re defining those benefits is changing quite a bit.
Another one is these service businesses, the professional service businesses are increasingly adopting recurring revenue models. They are really interesting to explore because service always had been relational. You’ve benefited for the duration of the service and when the duration–
Josh: Project base.
Esra: Project base, right, so how can you be a true partner for companies to rely on, on an ongoing basis? How do those entitlements change? How does your relationship need to change? How do you serve more proactively incorporating technology into your services increasingly so that you can offer those recurring models, so on and so forth? There’s a really big shift happening in service industry in terms of adopting recurring revenue models. Everything is turning into recurring revenue models and everybody’s trying to figure out from your dentist to from your managed service provider, everybody’s trying to figure it out. It’s really interesting.
Josh: Well, at Augurian, we do have recurring revenue model retainers that are just paid. Really, it’s about in the end, for us, it’s about value. It’s not like, how many hours is this buying us? It’s like, can we demonstrate that there’s a positive return on investment and that you’re getting value from this? That’s benefited us and I think our clients in a lot of ways.
Esra: Yes, I think you’ve touched on something really, really important which is somewhat overlooked. There are four fundamentals in recurring revenue pricing models. The very first one fundamental is what you just said, customers continue to pay as they continue to benefit. Sometimes the benefit is not a recurring benefit. As long as the benefit is a recurring benefit, you can actually use a recurring revenue model.
What’s really critical in SaaS is articulating the value of that benefit and sometimes customers can’t do that on their own. That’s why SaaS business models innovated customer success. Like they really have people to tell the customer how they’ve benefited, how much they’ve benefited and what the value is, and continue to encourage them to continue to pay for that value and even make the case for even more value, right?
You’re right, we actually have to articulate how much value a customer got from our solution and how they will continue to value if they stick with us. In some businesses, in some solutions, and there are these solutions where the majority of benefits happen in the very early stage. Let’s say an optimization software, right? Once you optimize your process, then you’re like, well, [crosstalk] water savings?
Now I optimize my process to save all this like water resource usage, right? Great. Do I keep paying? Well, so isn’t that an interesting question? What is your solution, what does your solution need to do so that this benefit is either recurring or maintained or improved or enhanced by integrating with other parts of the business or process or operation, right?
Josh: Yes, or the ecosystem.
Esra: Those are really interesting questions. Or the ecosystem, right, so really interesting questions to ask of ourselves, but you’re right, value is the key, and articulating that value often is really important for providers.
Josh: We’ve been talking about the future, right, the future of pricing. I know you’re working on some really cool stuff yourself. Tell us a little bit about where you see your future and your company’s future.
Esra: Absolutely. There are really a couple of really exciting things that are happening for us as well, speaking of future. In the past few years, we’ve been looking at our work and basically, we’re working on creating models where models don’t exist or creating new models where models break. When we ask that question, we clearly see that there are a lot of spaces, domains, and work that need new models.
We’ve been applying some of our work and learning on the child welfare system and wellness, wellbeing, systemic transformations in climate action because climate action cannot happen fast enough. What models do we need to scale these solutions that we already have? With systemic injustices, unless the beneficiaries change, these systemic injustices won’t change. We need to create new models which shift who benefits from these models.
We are really shifting our work into systemic transformations and climate action. For any of your listeners, whoever is working on these spaces, we’re doing all of that work for free, and we are happy to support that kind of work because it simply cannot happen fast enough. We’re really excited about applying all the things that we learned about creating models that work in spaces that matter and for which we need solutions really fast.
Josh: That’s amazing and inspiring. Thank you for doing that work. If there is anybody out there listening, definitely make sure you’re finding Esra.
Esra: Absolutely.
Josh: Well, that’s awesome. This has been an amazing conversation and I’m sure we could go on for hours and hours about this, but I feel like that’s probably what we have time for today. I have one last question which I ask of all my guests, which is just you’re a very smart person, you must be listening to or reading other very smart people. Can you tell us a little bit about those podcasts or books that are inspiring you today?
Esra: Yes. Well, thank you. I geek out on neuroscience a lot. I’m just fascinated by further understanding how we think, how we click, how we play, and I feel like once we understand humans, we might have a better shot at understanding how life works a bit better. I geek out on neuroscience books and podcasts quite a bit just to keep up to date with the rest of the world, I love Ezra Klein’s show. I love his perspective. I like 10% happier by Dan Harris and I sometimes listen to Tim Ferris, to his conversations and the way he asks questions is really, really smart. I find that really inspiring, trying to learn from him on that. Those are a few that come to mind.
Josh: Awesome. Well, I want to thank you again for being here. This has been an awesome conversation but that’s going to do it for today. Thanks, Esra.
Esra: Thank you so much for having me. Great conversation. Thank you.
