Why Product Discovery Matters w/ Wade Shearer, VP of Product and Design for Client Success

Hey everybody, this is Mike Belsito, co-founder of Product Collective, and we're here for another live product launch session. So hope everybody is enjoying your lunch break if you are actually on a lunch break, but thanks a lot for being here. I just wanted to give sort of a few quick remarks before we get into our interview today with Wade Sherwood, who I'm really excited is joining us. But for those of you that haven't been to a product launch session before, These, I think, are a lot of fun. Basically, it's a live Q&A chat. So we'll be talking today with Wade about product discovery, and we'll be getting in. I have a lot of questions for Wade, but if you do as well, you can absolutely ask in the questions section, and I'll be, you know, sort of reviewing that here and there. So I definitely like to pull in audience questions if I can. And so be sure to do that, you know, anytime. You don't have to wait till the end for that. Also, if you'd like, I do want to give a quick plug. We have, you know, of course, our conference is coming up, Industry, which happens in the fall. And yesterday we sent a note out to everybody in our group at Product Collective with a promo code, and that was— the code was growth. It helps save $50 off of your ticket. That's good for another 48 hours. So I figured I'll mention that here too. Might as well spread the word about that. Also, Wade is involved with another product conference. We'll hear about that at the end later on. That's pretty exciting too. I know it's a great one. A lot of people mentioned that it's, it's one of the other great product conferences that are out there. But I also, before we get into the conversation, want to mention a new program that we're introducing with other organizations, other product organizations called Friends of Industry. And it's really simple, but it's something that we just introduced this year to help spread the word about industry, but also for us to help put the spotlight on product organizations as well. So basically, if you have an organization, you know, that serves product people, maybe it's a podcast, maybe it's a newsletter, or even just a blog, and you want to help spread the word about industry and you'd like us to help spread the word about you, let us know. You, in fact, if you just went to IndSum, like for Industry Summit, IndSum.com/friends, You'll get a view of some of the organizations that are part of that. Includes some podcasts that are out there like 100 PM and Product Radio, which I was recently a guest on. We also have a podcast that is coming soon too. We have a few episodes recorded. We'll be launching that later this month. So more details on that. But anyway, check out that Friends Program. That should be another cool way to get involved with industry. Doesn't cost any money.

So check that out.

But with all of that said, I'd love to get into today's conversation with Wade. And Wade, thank you so much for joining us.

You're welcome. I'm excited to be here.

You're in Salt Lake City right now. Is that right?

That's right. Cool. I am.

I'm coming from Cleveland, Ohio. So I'm actually on campus at Case Western Reserve University at the Weatherhead School of Management. I teach a class here once a semester, or rather one class a semester. So Nice to be talking to you almost all the way across the country. I want to— I know that today, you know, we're going to talk a little bit about product discovery. And you actually wrote this post on Medium that was an awesome post. And it— I believe it really was like product owners versus product managers. And it went into detail about the differences. And you talked about that. And I remember one of the differences that you mentioned was, you know, product owners, they ship. You know, they're responsible for, for shipping products, for delivery, whereas product owners, you know, it's more about product— well, in a way, product discovery. You know, they have to figure out what is it that we're building and why should we build this in the first place. Can you talk about what you meant by product discovery in that context, though?

Sure. Most organizations don't spend enough time on discovery. And they, they don't have a good process for doing that. And I'm even timid on using the word process there because I'm very anti-process. But what I mean is that it's just not a priority. They don't have people that are specifically tasked with leading that, and they, they aren't incentivized the right way to do it. And we'll probably get into this as we talk, but really the outcomes that you get are really based around how you incentivize and motivate your team. And so, you know, the major difference here is that most companies are just focused on shipping, and you can't blame them for slipping into that because that's where the money comes from, right? That's what senior leadership's pushing for. Usually that's what the board's pushing for. That's what, you know, if you're a public traded company, that's what your investors want to see. But it's short-sighted. Usually, if you slide into that, then that's where companies stagnate, and eventually they get replaced by somebody else who's more innovative. So the idea, for the most part here, is that, you know, over the past 2 or 3 decades, as software development has matured, we have been trying desperately to try to figure out the right way to build software. You know, we figured out that it was different from the industrial age. That's where the whole agile came from, where we realized that, you know, it's different from hardware manufacturing, right? In the software world, we can be a little more nimble about it. But even the birth of agile was back when we ship software on CDs and in shrink-wrapped boxes, right? Well, the internet came along and changed all of that, and it was really unfortunate that in software we missed one of the biggest opportunities that we had with software, and that's that we can change things at a moment's notice. And that presents us with this green field of opportunity to learn and to figure out what we're doing And only recently, I feel like within the past couple of years, are organizations really starting to get good at that, at really figuring out what is it that we're trying to achieve. And coming outside of ourselves personally and as organizations, that we're not just doing this for ourselves, that we're trying to find out what is it that our customers actually need and what type of outcome What type of value? What is the job that they're trying to do? And if we deliver on that, it'll ultimately circle back around and we will be wildly successful based off of that. So that kind of answers your question.

Yeah, no, I think that sets the table really well. And it, it also partially answered, you know, another question was on my mind, which is okay for the organizations that were, that are more focused on that delivery versus the outcomes and the learning. Why is that? And you kind of mentioned, I mean, maybe part of it, which was, I mean, seemingly external factors. I mean, is it that organizations just, they see delivery associated with, hey, we need to make money and sell these products, so let's deliver, let's deliver, or otherwise, why is that typically the focus when the focus is more on that delivery?

The focus is just on control. People like to mitigate risk, right? What company Doesn't. You want to be able to mitigate risk. You want to be able to say, hey, this is when we're going to release this. Hey, this is when we're going to improve this particular thing. All customers want to know when you're going to ship, and the answer is just wait and see. It just kills me about how many companies don't have the grit to be able to tell customers no. It's the best thing you can ever tell your customer is just wait and see. And don't give in to the pressure. You don't have to tell them when it's going to happen. But it really is just that pressure of trying to mitigate risk, to try to be consistent, and try to improve the process. But what I would recommend to organizations is don't be so paranoid about trying to control everything, because that's where all of this goes. You know, even Agile, you know, that started actually right here in Utah, just which is 20 minutes from here up at Sundance, that's where the manifesto was penned. Its intent and its purpose was so noble, but the problem is that everyone takes that and bastardizes that. They take it and they try to put process around it, and all of a sudden you have certifications around it and people that can get certain levels and badges and letters put after their name of all of these processes. And now you've got all these people to manage it and trainers and things, and suddenly you're lost again. The whole idea here is that you need to empower your team and trust them and give them the ability to figure it out. If you build an organization that is working in small enough units, then they are— they don't need the process that a lot of these things try to employ. And then you can be— you know, you can find that success. So that's why they slip into it. You still need delivery. Delivery— you can't sell software without shipping it. One of the kind of buzzwords around product discovery right now is this concept of dual track. I struggle with the word dual track just a little, not that I personally have any problems with it, but I feel like people misunderstand what you hear or what it is when you hear dual track, because a lot of times I feel like people kind of think waterfall where you do this and then you do this and then you do this and you do this, where you've got these two tracks. Really, dual track is these two things that are going consistently that you're discovering and you're releasing and you're discovering and releasing. So as long as you understand what dual track means, It's a great concept. But the idea is that you've broken down the silos and you are not throwing things over the wall, that you are discovering what you should build, you're producing something in the smallest unit as possible, and then you're validating it. You're learning and then you're just feeding that feedback loop. It's, you know, honestly, the best advice that I could give everybody is don't seek out a perfect process. Don't seek out the perfect methodology. Don't seek out the framework. Am I saying that frameworks and methodologies are junk? No. But I'm also saying that there's not a silver bullet. The silver bullet is cross-functional, autonomous, empowered teams. That can go and figure out things and iterate on them and deploy them all the way to production completely on their own, and they can learn. That's the silver bullet, not the framework or the methodology flavor of the week.

Well, I want to, I want to talk about one thing that is sort of synonymous with process. You mentioned process a few times, but first, before I do that, I noticed a couple people that might be having issues seeing the stream. Maybe mention in the chat if you are seeing and hearing us just fine. It'll make me feel better if I see you mention in the chat. Otherwise, all right, so it is working good for most of the people, it seems. So that's great. But just a reminder for everybody, you can watch the whole live stream immediately right afterwards. So there were issues, you came in late, know that everything is recorded and you'll be able to see that right away. But going back to what you had said, Wade, you know, you mentioned process and there isn't going to be this perfect process. But one thing that is sort of synonymous with process when it comes to product is the creation of roadmaps. And I also read you say something that, you know, maybe might not be, you know, the commonly accepted, you know, thing, if you will, might be a little controversial, maybe not. But is that roadmaps actually for the most part or in certain situations at least they can be counterproductive. Can you talk more about that and just a little bit more of your take on that?

Well, and I wouldn't say that just slightly controversial. I'd say that there's a lot of controversy and I've definitely ruffled a lot of feathers with making some bold statements there. For the most part, I think roadmaps are junk and there's a lot of PMs that that really bugs them to hear or scares them, I should say, because they spend half their day grooming backlogs. But I would say if you're spending half your day grooming backlogs, you're wasting your time and you're being undervalued, and there is so much more that you could be doing. So am I saying that you shouldn't have any sort of a plan? Absolutely not. But if you have a year's worth of stuff in Jira, it's— you're never going to look at it, and it's an absolute waste of time prioritizing something that's that far out because there is so much that will change between now and then that you— it's all whatever you assume is true now is not going to be true by the time that you get there. So stop wasting your time working on that. So, you know, do I recommend you work with a roadmap? Do I have one right now? I don't use the word roadmap as often as other people do, but do I have a plan? Absolutely. I believe in like 4 to 6 week roadmaps. Roadmaps. And I believe that anything farther out than that is untrue. It's that you're kidding yourself. So now people say, well, you got to be kidding me. Like, how is the business supposed to plan anything farther than that if I'm only looking 4 weeks into the future? Are you suggesting that we don't even look farther in the future than that? No. And this is where somebody might say, well, potato, you know, potato to me. But I think there is a difference because I am a big believer in having a strong company vision. I'm a big believer in strategic themes and I'm a big believer in OKRs. So I believe that there's this hierarchy that you start with a clear company vision, that this is, this is who we are. This is our North Star. This is what we're trying to achieve. You know, it's like Elon Musk is trying to bring energy independence to the world, right? It's what is this thing that we are trying to solve? And then below that, you know, you need strategic themes that carry you through, through years, maybe a year or two. It's the big company goals that you're trying to achieve. And then I'm, as I said, a big advocate of OKRs, where you have quarterly objectives that you're trying to achieve. So if you want to call that a roadmap, I'm totally fine with that. Call that a roadmap. But what it shouldn't be is it shouldn't be individual line items and bugs and things that are sitting in Jira that is just ticket after ticket after ticket after ticket. Take it. So what I'd recommend to everybody, and this makes some people just absolutely uncomfortable and would freak out, because they say, where do I even begin? I'd say take it and delete it all. And most people can't do that. So okay, if you can't do that, archive it. But seriously, archive all of that and start with a fresh slate. Because you know what, if those bugs are truly important, and if those priorities to you are really things that your customers need, as you're doing your customer discovery calls and you're doing your research, they're going to come back. And so if it really is important, it's not like this golden nugget of insights that you— that's going to be lost forever. If it's really that important, it's going to come back and you're going to hear it again. So start with a fresh slate and bring a team together and figure out What is the most important thing that we're going to be working on? And then, and how does that align to the objectives that we have as a company for this quarter and for this year? And then let's go and let's validate that or invalidate that and then figure out what we're doing next.

Now, we actually had a past product launch session on getting executive buy-in, which might be relevant now because what I was going to ask you is what if you have— let's just say you're a product person and I mean, in the chat, I see a lot of people, they're virtually nodding their heads to this, but what if they're in an organization where, you know, it has been traditionally focused on delivery at the very highest levels? Do you have advice for how product people might be able to work with the executive team to understand that, hey, this product discovery thing, like, this is not— this isn't just something we do during one part of the product process. Like, this should be ingrained we shouldn't just be focused on delivery. Just any advice or thoughts on that?

Yeah, I love this question. I actually get it a lot, and my, my first answer is go get a new job. And I love that one, and everyone just smiles. But you know what, the market is so hot right now, and I, I love putting the heat on the companies, and they, they, they deserve it. That if these, you know, if companies are not willing to get serious about delivering value to customers as the first and foremost priority, then, you know, there are— then go find another one because there are a lot of them are. And, and it is a very hot market for PMs and for UXs. Now, that said, if you're willing to stay and you can't move at the moment, there's actually a lot that you can do. So here's the answer that you're actually looking for, and that is visibility. Just do it. Don't ask for permission. Just start doing it. And visibility— because here's what it comes down to. When it comes down to executives and when it comes down to the board, all they want is results. They want to see that something is working, and they want to trust you. So the visibility is where it happens. And you know what? They can't just argue with data. And so one of the big mistakes that people make is great PMs and great designers is they're out doing this research and they're talking to customers. The problem is a lot of times the executives aren't. So invite them to come with you, and if you can't get them to come with you, broadcast it all over the office so much that nobody can not hear this and be affected by it. If your company is not holding a town hall weekly or biweekly, do it yourself. I was also having a conversation with somebody the other day about putting this kind of information up where it's most visible as well. So if you can put up a TV— I don't know, maybe that's hard for you with IT, but maybe you could talk IT into it, or maybe somehow you can get an old display— go put it in the company break room or the company kitchen and put recorded sessions that you've done on there for people to see. So they can see the customer struggling with your product and having trouble doing that. But you should be holding a regular company town hall where your team gets up and showcases the things that are happening. Now, a lot of companies make it so that it's just show-and-tell day where the dev team and engineering team gets up and shows off new things they've built and shipped. That's a good start, but that's not good enough. What you need to do is show the company the things that you've learned. Here's our assumptions. Here's the hypothesis that we had. Here's how we went out to validate that or invalidate. Here's what we learned, and here's what we're going to do about it, and we'll see you next week and show you what, uh, show you what, what we learned. Just bring visibility to that loop, and most executives, most CEOs, they're going to listen. And if you show them that you're actually moving the needle because there's this benchmark and that you've now increased conversion or increased daily usage rates or increased, you know, whatever, whatever that one key metric is for your organization. If you can show them that you're moving it, they will get behind you and they will support it. So don't ask for permission. Don't bother wasting time with that. Just go do it and take the results to them and show them, you know, honestly, in In corporate scenarios, it's all about the numbers and they just need to see it. And so don't be afraid of that. You've got to learn, you know, what the key metrics are for your industry and for your product. And if you take that to them, they'll get behind you.

That's awesome. And, you know, it's— I've definitely been in scenarios where, you know, we put our— you know, they're sort of like the key metrics are all in front of everybody, but I've never been in a situation where It's like there's video looping, you know, video feeds of our customers struggling with our product or, you know, key learnings. Like, that's what everybody really should be understanding too. So I think that's, that's awesome advice for sure.

There's one more thing that I'll tell you along the lines there is we live in this digital world where we, I think we use it as a crutch and we get lazy. We assume that everybody's looking at our, our Jira or our product repository or wherever our roadmap is or wherever we're dumping our learnings, whether it's Dropbox or Evernote or whatever. You know what? Something that Intercom said that I'm a big believer in: just because we're working in a digital space and we're creating software, that doesn't mean software is necessarily the best tool to get there. And in fact, analog is one of the best mediums to get software built. Using whiteboards or printing things out And so don't assume just because you've documented all of these learnings and documented your plan, the people are looking at it because you know what, probably no one's looking at it. So print it out, go down to the local print shop and print out a huge poster and put it on the wall in a public place so that people see it.

I love that. I love that idea for sure. One thing I did want to make sure I asked you was, you know, product discovery, it's not a— I mean, and you mentioned this, it's not a process or it shouldn't be or I shouldn't say it's not a piece of the process, it's not a step that you take, it should be ingrained in everything that you do. Can you talk a little bit more about that and what the difference really is?

Yeah, absolutely. And that's a place where most companies have struggled. They've either outsourced it to a consultant to go do their ethnography research and to put together this perfect package and come back with all of these reports and everything and saying, okay, here's your target market, here's the opportunity, here's your personas. You know, here are these things. The problem is, is that if the team hasn't actually done it themselves, then they don't truly have that empathy. Once you've done the research and you've developed those things, most companies put them on the shelf and they don't look back at them for a couple of years. And then also the simple fact is, is that so many things can change between when you learn something and then when you're delivering, you're you're delivering and shipping that. Especially in today's day and age, the market changes so fast. Another competitor has released a new feature. There's been an update to an operating system that now does something differently. All of this, you have to be learning, learning as a continual process. And it has to be something that is done by the entire team. So you need somebody who's responsible for keeping the cadence and making sure that it's happening. But it can't be something that they do alone and that they pass off. You don't do research, make a plan, hand it over to the designer who designs it, hands it over to the engineer who codes it. Right? I mean, and hopefully none of this stuff that I'm saying is new to you. We've been beating this drum for so many years that Hopefully it's really starting to stick. But the idea is that everyone on the team— your PM, your designer, your researcher, your engineer, even a marketer— a lot of people are putting marketing in the mix now as well. This little team needs to be responsible for all of this and it needs to be continually part of it. So just like the, you know, You need to be learning all of this. The way that you do, and this is the part where I am the biggest fan of, is I recommend doing as much as you can in production. So you certainly can be prototyping, you can be testing these things. There's a lot of low-fidelity, smoke and mirrors, Wizard of Oz types of tests that you can do. But I believe that the absolute best learning that can be had is right in productions. So you should be working with DevOps, you should have an agile team that is completely empowered to build these things with feature flags and to roll all of this out to production, testing it in labs, doing product discovery calls where you're walking customers through all of these things. And then after every single moment, you're pausing as a team to talk about what have we learned and what are we going to do tomorrow. So just to give you an example of how my team has been working this past week, On Tuesdays and Thursdays, we've had customer discovery calls. We've had 2 that day. After that, we get together. This is a couple engineers, PM, we're doing the design. We get together, we review the notes with a recording of the call. We talk about what we've learned and about how did that change our assumptions. Do we need to pivot? Do we keep moving forward? Then the engineers go and they implement some changes into the product. They tweak something, we put it back out on our test server. Thursday, we get back on a call with another customer. We walk them through it. And there's part of it is an interview type of a process. Another part is them actually using the prototype and talking us through what's going on. We're documenting all of our learnings. We're sharing that out with the rest of the team. We're then making a decision on that. We're tweaking that in the product, in the actual code. We're rolling that back out to test so that we can then do it again. And these are things that you can do right in production behind feature flags so that it's not affecting your entire user base. But the learnings are so real and so, so, you know, they're raw, they're real because the customer is actually working with their real data. That's how you learn. And that's how you create great products because you need that tight feedback loop.

Yeah, I like that. And I want to make sure that we— we're almost at the end of our time, but I want to make sure I could go to at least an audience question or two, and one of them is, it's pretty timely, and it has to do with, you know, hey, for product managers, product owners, we're going through this process, continually learning, but how do we know when we should find more data versus accept it and say, hey, this is sufficient, and we push the product through? Like, how do you, how do you set that acceptance criteria? What, do you have any good advice for that?

My first thought is sooner than you'd think. Most people hang on a lot longer than they, than they need to. I guess I'll offer this to see if this helps. We set different criteria for 3 different phases that we have, and it's really kind of, is this breaking or not? So we have a prototype that we'll use during the initial product discovery calls, and it can be completely broken. Meaning they might be clicking on things that it doesn't even work, the forms don't even submit, and that's good enough to learn there. And we'll work through that, working out major usability issues and making sure they actually get what they're doing and they can kind of achieve it. Then we'll move it into labs where our customers can opt in to participate in this, but it's on production, but it's in labs. Once to get there, they need— it needs to at least be semi-functional, you know, there can't be major, major problems. And then once we get past labs where we've worked out all of the kinks and we figure out that it's delivering the actual value, that's when we move to a phased release. So then we will force it upon customers instead of opting in, we'll force it on rolling out 5%, 10%, 20%, 50%. If everything's good, everything's just, you know, no red flags, no problems, we'll then release it to general release. But the question is, I think that they're asking is when do you go How do you go, you know, in our scenario, from labs to production? The best advice that I can give you is it is something that you need to have determined ahead of time. Because if you get that far into it, you could cycle forever because you're getting heat from an executive to release this. You're getting pushback from the team of saying it's not perfect because we never want to release our baby because we always can see how it could be better and what we could fix. And especially if you have that tight feedback loop with your customers and you're learning more and more, you could continue on forever. You could just keep iterating and keep iterating, keep iterating. So the best thing that you can do is before you start a particular project or a particular, particular phase is sit down and say, what is it that we're trying to achieve here? And I'm a big advocate of the jobs-to-be-done theory. If you're not familiar with that, it's worth your time. Go and invest in that and figure that out. But in your project brief, you should specifically be stating what it is that we're trying to achieve. This is the job. Keep it simple, but this is what we're trying to achieve. We're trying to allow the customer to do this, or this is the outcome that they're trying to achieve. And that's the answer. That's when you roll it out of labs and into production, is the moment they can do that. And so you— and another key that you need to know, though, is how do you know if that's happening? And once again, you can be watching things, but the company to buy in, they, they don't want just the touchy-feely. So you need to have some measurable type of benchmark that you can, you can base that on. It's kind of like with OKRs, if you're familiar with that. Your objective should be, should be warm and inspiring, but your key results should be very clear and very measurable. They should absolutely, absolutely be quality quantitative, that you can measure those and you can prove that you've met that objective. So what's your hypothesis? Well, this is what we want to do. Here's the benchmark. Here's how it is today. And then here, this is the result that we're going to see. We're going to see this in the market. We're going to see this type of activity from the customer and see this change in behavior. And once we see that, that will be an answer to us that we know that we've achieved that. And so that's where we hit that, when we have something in labs, the moment they can do that, and then we start rolling it out.

Yeah, well, thank you for that. And Wade, it's crazy, but like time's flown by. We're pretty much at the end of our time now, so I know we could continue talking, but actually—

yeah, I wish we were. I'd love to keep going.

Well, all right, tell you what, maybe I'll ask one last audience question for you if you don't mind, and then I definitely want to, um, I definitely want to know you know, how people can like keep tabs on what you're doing. Because I know you write often, I know there's other work that you do as well. But I will ask one other question. This has to do with what you did, or what you had mentioned in the past about, hey, having everything up there, like physically up in front of people, like that could be a good thing. What about for people that work remote though? And everybody's working from home. Have you seen the best ways to do that for teams like that?

So first off, I'm not a big advocate of working from home. I'll just throw that out there. Sorry if I offend any of the viewers. I understand that sometimes it's, it's, it's the way they go and it's, it's hard. But I have, you know, throughout my career, I just cannot deny the effectiveness of in-person conversations and two people sitting at a whiteboard. It— there's just no way around that. So I don't think that a company needs to have their entire company in one location, but I do believe that individual product teams should be co-located and that they should spend time physically in the same place. I'll just set the stage there. Beyond that, you have to work really hard to communicate. You have to absolutely over-communicate, documenting things. What I would recommend is having a central repository where you log all of your product briefs, you log your research schedule, you log all of your learnings, and you need to synthesize the learnings down into bite-sized pieces so that people can consume it. So there's— people are never going— like I said, people are never going on their own. They're never going to go wherever you keep this information as a team and just browse it. Everybody's too busy. Your CEO is never going to do it. Senior leadership's not, unless you trickle that and drop that into their face. So I still have not found a better tool than a wiki, just an ugly old-fashioned wiki, because it doesn't need to be pretty. It needs to be accessible by everyone, editable. Now I know a lot of teams that use Dropbox Paper or Evernote or Basecamp. Basecamp's probably a good option too. Google Docs. The problem is with a lot of these is you get there and there's no way to find the current project, and it's just a mess of all these files everywhere. I like a wiki where it has a home page that just lists out all of the current projects, and you can click into the current project. Or maybe something like Confluence. Someone just mentioned that in the message. That would work. But you need to have a list of here's all the comp— the current things we're working on and be able to click in and see all the— to see the project brief. Here's our hypothesis, here's our benchmark, here's what we're going to learn, here's our product discovery schedule. And if you're recording your sessions with your customers, don't send people links to an hour-long recording session. There are tools that help you to go in and find one or two, you know, 20-second little clips and then share those. I'll also give a shout out to something called dailies. I assume most everybody's using Slack, and there's this really cool thing that I, I learned from a team here locally at Pluralsight, that they started this channel in Pluralsight called dailies where every member of the team at the end of the day takes a few minutes to report on what I accomplished, What obstacles did I encounter? And what did I learn? Don't spend too much time on it, just a couple of minutes and just crank out a pair, you know, just a couple of sentences, a paragraph for each of those. And that kind of retrospective inside of yourself and that kind of visibility and transparency with the team is incredible. It is so valuable to share those learnings with the team to help them know what's going on. And, you know, if you have senior leadership that are watching things like that, it's a great way to start a conversation, especially with the threading that they do in Slack now. You post your little daily, and then all of a sudden this little conversation with some coworkers or your, or your boss can happen based off of that little report that you gave. Don't ask somebody— don't wait for somebody to ask you for the report. Just start offering that information. Here's what I did today. Here's the obstacles that I encountered. Here's what I learned in there. I talked to this customer and I learned that this is what they need, or this particular feature isn't working, and here's what I'm going to try tomorrow to, to make it better.

I, and I can totally see if you start doing that, other people could be infectious. Other people start doing that. That's just better for the organization too.

Oh yeah, absolutely.

Awesome. Well, Wade, thank you for taking the time to talk with us. I thought this was a great session. Uh, could you let everybody know just how we could keep tabs on, you know, your work and what you're doing?

Absolutely. My website is wadeshearer.com if you want to get in touch with me. That's— on that website, I list events that I'm involved in and I'm running, different places I'm speaking and whatnot, and then my contact information. I'm also on Medium @WadeShearer and then on LinkedIn. So several different ways to get ahold of me.

Awesome. And I know you have your Front Conference coming up next week, so especially in light of that taking place next week, good luck with that, and I hope everything goes well with it.

Thank you. I wish I could tell the audience to come get tickets, but unfortunately we're sold out. So definitely keep an eye out for future events though. Just to put a plug— selfish if I may— we aren't announcing this until next week, so this is our Just a sneak peek here. You guys are getting the information early. Our UX and product management 2-day boot camp that we run in Park City, Utah, the dates for that are the 4th and the 5th of January 2018. And we're holding it at the Utah Olympic Park, which is the site of the 2002 Winter Olympics in Salt Lake. It's a 4-track 2-day boot camp. It's going to be incredible. The website is frontutah.com, and if you come back next week, we'll have a new website up with all the details and the, the tracks and everything. So thanks for the plug there. Uh, we'd love to have you out of that event.

That's awesome. Well, I like breaking news here on Product Launch, so thanks a lot for that, Wade. Uh, thanks for joining us, and we'll see everybody next time. Actually, we have the founder of Balsamic, Peldi, with us next time, and I'm really excited for that session as well. That'll be in 2 weeks on the 17th. So until then, I'll see everybody later, and, uh, thanks for joining us at Product Launch.

Thanks for having me.