Introduction to Modern Product Discovery - Teresa Torres

Hi, everybody. I want to clear up a misunderstanding. Don't worry, it's not about brainstorming. A number of people have asked me why I have a Portuguese name. So let's just talk about that for a minute. As you can tell, probably from how I speak English, I'm an American. In the United States, a lot of us are mutts. I don't know if you're familiar with that term, but we come from multiple ethnicities. My father is both of Spanish descent and Mexican descent. Hence, I say my name is Teresa Torres, which is maybe the most American way to pronounce this name. So if you come up to me and speak Portuguese, I might try to understand what you're saying, but mostly I'll say I'm sorry. So now that we've gotten that cleared up, let's talk about modern product discovery. So I work as a product discovery coach, and so naturally that means the most common question I get is, what's that? How many of you guys are familiar with the term product discovery? Some of you. Okay, good. So don't worry. No knowledge is required. We're going to start at the very beginning. We're going to do a little walk through history, and we're going to take a look at the very end at what's coming next so that as these things start to come into your world, you have a way of making sense of all of the rapid changes that are happening in the world of developing products. So the best way to think about product discovery is to think about it in relation to product delivery. Now if you build products you do both of these things. It's not possible to build a product without doing both discovery and delivery. So discovery encompasses all the activities that we do to decide what to build, right? It's all the decisions around what should we build next. Whereas delivery is all the activities that we're doing to write code, package things into releases, ship product. It's how we're delivering the value that we're creating to our customers. Now, the benefit of distinguishing discovery from delivery is that most companies overemphasize delivery and underemphasize discovery. And when we separate these two things, it allows us to say, how are we doing in each? Are we any good at discovery? Are we any good at delivery? And if we look over the last 15 or so years, especially on the delivery side, we've seen a lot of progress. And we have a really clear yardstick. Probably every single one of us in this room would agree that on the delivery side, our goal is to ship value as quickly as possible. So once we've decided what to build, our goal as a product team is to get it out the door as fast as possible. And we've seen this in our delivery practices. They've evolved rapidly over the last decade and a half. And we've seen teams go from releasing once a year to releasing every quarter, to releasing every month, to releasing every week. And many teams are now releasing software as soon as their software developers are done writing it. They're releasing many, many, many times a day, and they're getting value to their customers as fast as humanly possible. Now, what's great, no matter, some of you might be looking at this and say, wow, there's no way we'll ever release every day. And that's fine, right? What's good about this clear yardstick of how can we ship faster is that no matter where we are as a company, we know what good looks like. We can look to the future and say, eventually, we want to ship, we want to get faster and faster. And as we're evaluating our delivery practices, we can evaluate them based on how fast are our release cycles. And we all know what good looks like. So when I started to think about this, I naturally asked, what's the equivalent for product discovery? What's our goal? And how do we know if we're any good at this? And given that so many of us do product discovery differently, how do we know if we're doing a good job? So when I started to ask this question, I looked back over time, and I was actually pleasantly surprised to see that product discovery has actually had a very similar evolution to product delivery. and around the same time period. So I want to walk through the last 15 years briefly and talk about what have we seen in the world of product discovery. And then I want to use that to help you put all of those trends into context and to know what to use when, so that we're not just guessing about what tool in our toolbox to use at any moment in time. So I want to go all the way back to the year 2000 when Windows launched Windows Me. Now, I have no idea if this product even made it to Europe. because it was a complete flop. This was one of Microsoft's worst products. It was their follow-up to Windows 98. It was launched in June of 2000. By 2004, Microsoft was already announcing they didn't want to support it anymore. And by 2006, they ended support for it. Now, what led to this failure? Let's think about what product management looked like during this time period. Now, I've never worked with Microsoft, I've never been a client of mine, I have no inside knowledge about how this product was built. So, at this point, I'm gonna describe how many companies worked during this time period, and I'm gonna assume this is what things look like at Microsoft. A product manager, or a number of product managers, probably spent months gathering requirements from internal business stakeholders. They documented it in a really long product requirements document. They sent it off to their engineering team who spent months if not years building to that document. When they were done, they stamped their software onto a CD. They packaged it in a shrink wrap box that looked a lot like this. They sent it to stores and only when it still sat on the store shelves later did they realize nobody wanted their product. So if we look at this model of how do we decide what to build, it's really clear now, 16 years later, to say, wow, this is not a very effective model. Maybe we should learn before we ship our product to stores that nobody wants it. How can we avoid flops long before we finish building the whole thing? And it's this type of question that is really driving the evolution of product discovery. So fortunately, even at the time that this product was launched, there was a lot of people in the software community who were already frustrated with this way of building products. Nobody wants to spend years working on a product only to learn at the end that nobody wants it. And so a bunch of people came together, they started sharing what they were doing, they started asking what could we do differently, and a lot of this frustration culminated in 2001 with the release of the Agile Manifesto. Now, the Agile mindset gives us a lot of value. There's a whole lot of things that Agile helps us with. I want to highlight one thing in particular on this road to the evolution of discovery that I think is a really important part of the story. So in the waterfall method, we often spent months, if not years, building a product, and we would periodically tell our business stakeholders how things were going. We would often learn that we were on the wrong track. We weren't building what they wanted, because product requirements documents are a pretty terrible way to communicate. Language is very vague. we misunderstood the requirements, and we got further and further away from what our business stakeholders wanted. And for those of us that have switched to Agile or even early in our Agile transformation, what we start to see is one of the great things that Agile encourages us to do is two things. To one, develop in much smaller batch sizes, so don't write code for months and months and months, write code for a couple of weeks, and then show it to people and see if you're on the right track. Now for many of us when we first started with agile show it to people meant our internal business stakeholders So we started to ask the question earlier in the process. Are we building what our business wants? This was a good step forward But at around the same exact time period we saw another trend a trend that was pushing on another dimension asking a different question and that question was not Do are we building what our stakeholders want? But are we building products that our customers know how to use? So right around the same time that people started pushing on Agile, we started seeing the rise of user experience design and design thinking. And we started to see, so if we think back to the early 2000s, we started to see teams were starting to hire interaction designers. The design world was debating about information architecture versus interaction design versus user experience design. Good times. And we also saw the popularity of design thinking, and we started talking about building empathy for our customers. And it was no longer just about building for our stakeholders, and we got a lot more focused on building for our customers. This was phenomenal. These two trends together, I think, helped us take a giant step forward in informing how we decide what to build. Recently, about five years ago, we saw another giant step forward. And this step forward, actually, a number of people contributed to this movement, but I think one, the release of a specific book really propelled us forward. Many of you may guess what it was, but about five years ago, Eric Ries launched the Lean Startup. And the Lean Startup was really informed by Steve Blank's work, so I want to make sure that we give him credit as well. And this is where we didn't just ask, are we building something that customers can use? But we started to ask, are we building things that our customers want? Now, user experience designers, of course, also started asking this question. I'm going to give a simple narrative to walk through our history here. But this is where we started to ask an even deeper question. Do customers want our solutions? And what's great is both Steve Blank and Eric Reese started to give us a lot of tools for how to answer those questions, right? We started to learn about MVPs. We ran through the build, measure, learn cycle really quickly. We're learning earlier in the process. And then more recently, we're starting to see the popularity of yet another tool, and that's the jobs to be done framework. And again, the jobs to be done framework was popularized recently by Clayton Christensen, but it's based on a lot of work that was done by Anthony Ulwick. And basically, what we're seeing now is we're starting to ask a different question. We're not just asking, do customers want our solutions, but are we solving the right problems for our customers? So I can create a solution to a problem that you have, but it's not as compelling as a solution to a much bigger problem that you have. Right? So we've moved from just focusing on solutions to starting to ask, are we solving important problems? Now, this evolution is not stopping, right? We're still going to see new tools, new frameworks. In fact, even in the last 12 months, we've seen a giant push in popularity of two new methodologies. One is the design sprint. So this book came out earlier this year. It's a five-day process where on Monday, a team starts with a big meaty challenge they have no idea how to solve. And by Friday, they've prototyped a solution and tested it with real customers. And it's a fantastic way of introducing human-centered, experiment-driven product management to a team. And I suspect many of us are just starting to think about how do we use this tool. The second trend that has really risen in popularity this year, thanks to Google, building on work by Intel, is the use of objectives and key results, or OKRs. And if you aren't familiar with them, that's fine. What matters right now is not the details of all of these methodologies. It's just that our practices continue to get better. And OKRs are a way for us to think about how do we focus on outcomes and how do we align everybody in our organization around the same outcomes. In the world of product management, this is really important because we get obsessed with features, and we shouldn't be obsessed with features, we should be obsessed with what outcomes are we creating for our customers and for our businesses. And this is where something like OKRs are really helping product teams focus on what's the outcome that I'm driving. And so I started to look at all these trends over the last 15 or 16 years, and I thought, Wow, it's been a good couple of decades for product discovery. This is awesome. But here's the thing. Most teams that I talk to have no idea what product discovery is. They know these tools, but they don't know what to use when. They don't know... People are dogmatic. They say, the only way to build products is with lean startup. Or they say, the only way to undercover users' needs is to use the jobs-to-be-done framework. This is doing us a disservice. A lot of these methods come from the exact same underlying principles. And it's not about one's the best and another one is no good. It's not about design thinking versus lean. It's not about agile versus, well, it is kind of about agile versus waterfall. But really, here's the idea. We have all these tools and frameworks because all of us are pushing to get better and we're pushing together really fast. And so we're seeing a lot of different methodologies that have a lot of overlap. And so when I look across all these methodologies, the question I ask is, how do we know if these are helping us? And how do we know what to use when? And as a product team being constantly inundated with all these methodologies, how do I decide which ones are right for my team? And how do I know what to use when? So I want to go back to the original question, which is for product discovery, what's our goal? Our goal is to learn fast. Instead of learning after we ship our product that nobody wants it, we want to learn as quickly as possible if what we think we should build is the right thing to build. And every single time we learn about a new tool or a new technique, we want to ask ourselves, what does this help me learn quicker than what I was doing before? If we look at this same history, we can see that with each technology, with each methodology, we're starting to answer different questions earlier in the process. So one of the big questions we start to answer when going from waterfall to agile that we can answer much quicker is, are we meeting our stakeholders' needs? Right? We don't wait six months before we say, here's what I built. We say every two weeks, I built a little bit more. What do you think? So this is great. It really helps us move that learning earlier in the process. What we get from user experience design is a different question. If we build in usability testing early in our development cycle, we're able to answer, can customers use it? And we can answer this long before we ship any product, which gives us time to fix it if the answer is no. Now, in 2016, a lot of this now sounds obvious. But for those of us that were building products in the late 90s and early 2000s, we used to have to fight to run usability studies, right? So being able to answer this question really early is phenomenal. And then thanks to people like Steve Blank and Eric Ries, we're now asking an even more important question much earlier in the process, which is do customers want our solution, right? We're not just assuming this is the best thing in the world. We're leaving some room for humility and doubt. and we're saying we might be wrong. How can we learn that earlier in the process? And then again, with jobs to be done and with other opportunity finding methods, we're now asking much earlier in the process, are we solving a problem customers care about? So in jobs to be done, they're asking, what job is your customer hiring your product to do? What problem is so important to them? What problem or challenge or opportunity is so important to them? that they're willing to hire your product? And how do you make sure your product really meets that need? So this is a great deep question that we're now asking much earlier in the process. And if I look across all of these questions, and if I mix and match these methods, and I really learn all of this early on, long before I spent months building something, really what I'm able to do is I'm able to answer the most important question, which is, are we driving towards a desired outcome? As a product team, my goal is to increase engagement, to reduce churn, to increase revenue, to increase customer satisfaction, to make my NPS score go up, right? It's not to just build feature A, B, and C. And what's great is if I look over this exact same progression of 15 years, what I see in these questions is we're shifting from a focus on output, am I meeting my stakeholders' needs, to a focus on outcomes? Am I having an impact on my customers' lives? Am I improving the value of my business? And what's great about making this shift is now we all can look at what good looks like. We now have a yardstick for what good looks like. No matter where you are in this process, if you're just new to usability testing, if you're just new to experimenting, you know that your goal is, how do I learn fast? How do I learn faster than I did last time? And so no matter where you are in this list of questions, even if you're only answering some of them or you're answering all of them, you can take stock and look at where you are and say, OK, I may not have confidence that I'm solving the right problems, but at least I know that people want my solution. And that's good. And I now know what the next step is. So no matter where you are in your product discovery process, you now have a yardstick for what good looks like. And this is really powerful. I think we've been missing this for a really long time. But now as an industry, we're starting to realize learning and learning quickly is the most important thing. Now, I work as a product coach. And so what that means is I work with a product team, usually between for three to five months. And I'm working with them week over week in the context of their own work. And when I first started doing this, what I was teaching teams was how to conduct good customer interviews. how to run sound experiments, how to draw good conclusions from those research activities. And I would get really good feedback, but I would always also get the same question over and over again. What my teams would say to me is, Theresa, we love that you're helping us do interviews, and we love that you're helping us run experiments, but we still don't know what to use when. You always have to tell us what to do next. How are you doing that? How do you know when to talk to a customer versus when to run an experiment versus when you're ready to go ahead and move forward with your product? And I started to think about this question, and it seemed really intuitive to me. And I said, well, if I'm doing this intuitively, how am I supposed to teach another team how to do this? And fortunately, at the same time that I was asking this question, I was reading a book called Peak. Peek was written by Anders Ericsson. He's a researcher who for most of his academic career has studied expertise. And he looked at what makes experts stand out from novices. And a big part of his research has found that experts rely on stronger mental representations that novices don't have. So a mental representation is what's a structure that you have internally in your head that's helping you organize information, that's helping you make sense of the world around you and helping you make decisions quicker and easier. And so I started to ask, am I using a mental representation to guide my teams through this messy land of product discovery? And it turns out, I do. And I started to play with it, I started to whiteboard it. This became my design challenge. And for the last five or six months, I've been using it with my product teams. And of all the things that I've ever taught, this visual structure has had a bigger impact on improving the quality of product decisions of anything else that I've ever seen. And it's because it's a critical thinking aid. It helps people see their thinking, examine the connections, and really question, are we building the right thing? And so I want to share it with you today. It's called the Opportunity Solution Tree. This is not rocket science, if you're familiar with decision trees. It's really just a decision tree that helps you make sense of this messy world of product discovery. And when I started to play with this visual structure, I realized there's a huge gap in the discovery world that we're just now starting to fill. So the top of the tree is the blue box, and the blue box is a clear desire to outcome. Now this sounds obvious. How are we supposed to build a product that drives the outcome if we don't know what the outcome is? But I can't tell you how many product teams I meet that have no idea what their desired outcome is. They say things like, we're just trying to make the user experience better. How are we measuring that? How are we going to know when we've done that? So one of the things I love about the popularity of OKRs, and OKR is a qualitative objective, combined with quantitative key results. So my objective might be to have the easiest diagramming tool, but my key results force me to say, how will I know if I'm making progress towards that objective? And I have to come up with a quantitative measure. Now this is really important. The root of this tree needs to be a quantitative measure, because by the time we get to the very bottom and we're running experiments, we're going to evaluate our experiments based on that quantitative measure. So if our goal is to increase engagement by 10%, every experiment we run while searching for what will drive that desired outcome is going to be measured by how much it impacts engagement. OK. So first, step one, define a really clear desired outcome. It sounds simple. We all know we should do it. Sometimes I spend weeks with teams on this. Because if you don't have a metrics-driven culture, you're not going to agree. And it's going to take some time. But if you don't have a clear desired outcome, you're not going to drive a desired outcome. The second step is the one that I see missing on 98% of product teams. And I think jobs to be done is going to help us fix this. But the second step is we need to discover the opportunities that are going to drive that desired outcome. And so what I mean by opportunities, it's a little bit jargon. It's because I'm trying to appease people who have problems with the word problem. So if we think about this from a problem-solving lens, we have to define the problem before we can solve it. If you're familiar with the Einstein quote, if I had an hour to solve a problem, I would spend 55 minutes first defining the problem and the last five minutes solving it. That's this idea. I mentioned it earlier in the panel. How we frame the problem has a really big influence on the types and quality of solutions we can generate. But as product teams, we often skip this step. Somebody says to us your goal is to go increase engagement and we start brainstorming solutions I promised I wouldn't talk about brainstorming we start generating solutions, right? And the challenge here is we have no way of evaluating solutions if we don't know what problem we're trying to solve Now the reason why I call them opportunities and not problems is because not Problems encourages us to fix things and sometimes things aren't broken. We can just make them better Right? So think of an opportunity as a pain point. It's a need. Sometimes it's just a want or a desire. Right? Like Elon Musk really wants to go to Mars? That's not really a pain point. I mean, he might say it is because he thinks Earth is done. But right? Like there's these aspirational things that we want and need that aren't necessarily problems. We just want them. So opportunity is just a little bit more inclusive. And it's really getting clarity around what's going to drive our desired outcome? So if my desired outcome is to increase engagement, I want to know two things. One, what prevents people from engaging today? This is the problem mindset. What are the obstacles? What are the barriers? I have opportunities to remove them. Then the other side of it is the really positive, sort of appreciative, queer inquiry answer question, which is, for my customers who are engaging today, why are they doing it? What problems? am I solving for them? Or in the jobs to be done language, what job does my service or product do for them? And if I can uncover that, I can reach out to everybody else in the world and say, hey, the job that you should use my product for is this. And I can use what I learned here to go find more customers. So what makes me sad about the fact that most people skip this step is I believe that the opportunity space is where product strategy happens. The opportunities we choose to go after what differentiates us in our market. Two companies in the exact same space are gonna pick different opportunities. So I really encourage teams to take time to explore the opportunity space, to assess which opportunities are most likely gonna drive their desired outcome, and to use their company's mission, vision, and strategy as a filter. Because Google's gonna choose one opportunity and Apple's gonna choose a different opportunity. It's not because one opportunity is bigger than the other, it's that those companies have completely different DNAs. And so they're gonna filter opportunities differently. This is where I think the heart of product strategy lives and most of us are skipping it. And then finally, once we discover opportunities, we need to make sure that we discover solutions that deliver on those opportunities. And what we don't have time to talk about today is the links between all the links on this visual. It's the links that help us as a critical thinking aid. We really want to ask this question. In fact, our experiments should help us ask, one, is this solution viable? But then it should help us test the link. Does this solution deliver on the opportunity? And again, that sounds so obvious, but we build all sorts of solutions that don't actually deliver on the opportunity we're targeting. And then finally, we have to ask, does the solution deliver on the opportunity in a way that drives our desired outcome? Because even if we solve the problem for the customer, but it doesn't increase their engagement, we didn't actually create value for our business. So what this structure does is it helps teams remember what's our goal, what's the outcome we're driving, and as they do all these research activities, they can track it. This becomes their discovery roadmap. This is how they communicate to the rest of their company. I have no idea how I'm going to increase engagement. That's scary, I know. But here's the opportunities that I see. These are the solutions that I'm exploring that will deliver on those opportunities. And these are the sets of experiments that I'm running that will tell me if I'm going to reach my desired outcome. And what's great about this is it helps us put all of our tools into context. So if I think about this, OKRs are helping me set a desired outcome. Now my whole team knows What's our end goal? What are we trying to accomplish together? Where it's jobs to be done and even design thinking. Design thinking is really good at helping us with opportunity finding because we're doing empathy interviews and we're doing observations and we're co-creating with our customers. We're learning how to live in their world. And that's helping us see, for example, why are they engaging or what's keeping them from engaging? So these tools, we get dogmatic about them, we argue about them, but they're helping us do the exact same thing. They're helping us discover the opportunities that will drive our desired outcome. And then if we go down one level, when we look at usability testing, when we look at the lean startup, when we look at MVPs, what is this helping us do? It's helping us test. Do our solutions deliver on our desired outcomes? So here's the thing. I know I went through this history pretty quickly. it doesn't matter. These specific tools are awesome. If you're not familiar with them, I recommend you learn about them. But here's the more important message. Five years from now, there's going to be 10 new books that I could have included here. Our world is changing really fast. Right now, we're talking about design sprints and jobs to be done. Five years from now, we're going to be talking about two completely new methods. It can feel really overwhelming. But here's the thing to remember. Our goal is not to write good user stories or to do good user story mapping. Our goal is to drive a desired outcome for our customers that creates value for our business. And the structure of this tree five years from now, I don't think it's going to look any different. We're still going to be trying to drive desired outcomes. We're still going to have to discover opportunities that deliver on that outcome. And we're still going to have to discover solutions that deliver on those opportunities. So our tools might change, but what we're trying to do I don't think is going to change. And the reason why I don't think that is that we have a hundred years of research on good decision making, good problem solving, and good critical thinking. And it's all consistent with this idea of start with an outcome, explore the problem space. and use the problem space as a way to expand the solution space. And as you explore solutions, it feeds back into your understanding of the problem. This is the heart of problem solving and decision making. So this to me is the stable part of what we do. And I find that it's really helpful for putting all of our tools into context. So when you read that next article about whatever comes next, all I would ask is that you take a step back and you say, okay. Here's what I need to ask myself to know if I should use this tool and when I should use my tool use this tool first Does it help me learn something faster? If the answer is yes, you want to adopt it Second, what does it help me learn faster? Does it help me set a desired outcome? Does it help me discover opportunities? Or does it help me discover solutions? And that helps you understand what to use when now I want to end by looking towards the future And one thing that I love, there's a quote that I love by William Gibson, a science fiction author, who basically said, the future is already here, it's just unevenly distributed. And I see that with the teams that I work with. So I want to talk about a concept that may sound really foreign to you, but teams are already doing this. It's happening today. And I believe this is the future of product management. And it's this idea of continuous product discovery. So a lot of product discovery, especially these recent trends, grew up in this big project mindset. Let's go off and interview a dozen customers. We're going to synthesize what we learn. We're going to put it in a research report. And we're going to give it to our product team and hope they use it to inform their product decisions. And what we find is that doesn't always happen because the people doing the work are too far away from the research. And so what I teach teams to do I work with a product manager, a user experience designer, and a tech lead, and I coach them on how to do continuous discovery. So what that means is instead of doing big research, they're talking to a customer every single week. They're doing a prototype test every single week. They're running a big experiment every single week. And by big experiment, it could be a landing page test from the Lean Startup. It could be a simulation of experience in person with the customer. But here's the goal. The goal is to do smaller research activities every single week by the team building the product. So that at any point in time when they need to make a product decision, they can stop and take stock and have multiple data points from multiple research activities that very week and say, based on what I know right now, what's the best decision I can make? This to me is really important because in the product world, we're running experiments like 18th century scientists. We run one experiment, we decide its truth, and we make a decision based on it. The example that I use with my product teams is I ask them, how many of you have read an article in the newspaper that tells you that coffee is good for you? And everybody's read one of those articles. Then I say, how many of you read an article that says coffee's bad for you? And almost everybody has read one of those articles. And the reason why is because a journalist is finding one study that says coffee's good for you. And then they're finding another, and then a different journalist is finding another study that says coffee's bad for you. And they're each writing their own articles. But that's not how we learn. That's not how research works. What we do, the way to know if coffee's good for you, we have to look at the whole set of studies that have ever been done on coffee. and do a meta-analysis and say, based on everything that we know today, what's the best decision we can make about drinking coffee? And here's the thing. A year from now, that answer might change because during that year, more studies are gonna be done and the data might start to look a little bit different. The same is true with product decisions. So we don't wanna make a decision based on one AD test. We don't wanna make a decision based on one customer interview. We wanna make our product decisions based on sets of data, sets of research activities. And so in order to do that continuously, we need to make sure that we're continuously adding to our bank of interviews and to our bank of experiments. And so part of this is we have to develop good knowledge management techniques. We have to be able to document all the experiments that we're running. We have to be able to capture interview snapshots and archive them so that when we remember I interviewed this person who had this exact problem. I want to go back and find all the interviews where this came up. We have a way of doing that. And this may sound like it's impossible to do, but I can tell you I work with some really big companies in the United States in old industries like banking and insurance, and they are doing this, and they're doing it really well. So I just want to leave all of you with we've made a ton of progress in the last 16 years. And I really believe that five years from now, most of us are going to be talking about smaller size research done week over week by the team building the product. And our products are going to get significantly better. So here's what I want to leave you with. I am online and very easy to find. Please, if you have questions, if you want to keep the conversation going, I think about this literally all day, every day. And I would love to talk to you about it. Thank you very much.

Teresa Torres’ keynote on “An Introduction to Modern Product Discovery Practices” took place on the final day of the Productized Conference 2016. The keynote was designed to explain to the audience some of the changes seen in the last 5 years in the world of Product Management. Teresa spoke about understanding the latest trends in the field and picking and choosing these methods to form a coherent strategy that ultimately leads to a better product.
---
✔About Productized Conference 2023
Join Europe’s #1 Product Conference this fall in Lisbon and:
🤝 Meet 300+ product players from around the globe
💃 Actual business practices from 30+ speakers (including Melissa Perri, Tami Reiss, Radhika Dutt, and many more)
🍹 Have fun at our epic afterparty!

SAVE THE DATE * OCT 11-12, 2023* 
👉https://www.productized.co/

📰 Follow us:
Website: https://productized.co/
LinkedIn: https://www.linkedin.com/school/productized/
Meetup: https://www.meetup.com/Productized/
Subscribe to our newsletter 👉https://buff.ly/2GSFBZB