Why product discovery matters

I had the privilege of being interviewed a month ago by Mike Belsito on the Product Lunch podcast. Product Lunch is a regular webinar series produced by Product Collective, a new initiative connecting product people from across the world. Product Collective also runs Industry, a multi-day Product Management Summit.

Unfortunately, most organizations are focused on output instead of outcomes. Roadmaps are defined by upper management and the entire organization must run the feature-race hamster wheel of shipping. But what good is delivering features fast if it doesn’t deliver value? What good is any of the work if you aren’t learning and incorporating that learning back into the product along the way?

Short on time? Here are six quick takeaways:

1. The best thing you can tell your customer is “no.” Don’t give into the pressure.
2. 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 don’t need much process. Don’t seek out a perfect process, methodology, or framework.
3. Toss out your roadmap (longer than 4–6 weeks). Replace it with a strong vision, strategic themes, and OKRs.
4. Discovery should be a continual process, not a step, that’s executed and consumed by the entire organization.
5. Set benchmarks and measure success against pre-established criteria for each project; otherwise, you’ll loose credibility and iterate indefinitely.
6. Spend time at the end of each day for a quick, personal retrospective and then report publically on what you accomplished, obstacles you encountered, and what you learned.

Full transcript

Mike Belsito: Wade, thank you so much for joining us.

Wade Shearer: You’re welcome. I’m exited to be here.

Mike: You’re in Salt Lake City right now, is that right?

Wade: That’s right.

Mike: Cool. I am coming from Cleavland, Ohio. I am on campus as 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 know that today we’re going to talk a little about product discovery. You actually wrote this post on Medium—that was an awesome post—and I believe it really [was] about product owners versus product managers, and it went into detail about the differences and you talked about that and I remember that one of the difference that you mentioned was [that] Product Owners ship. They’re responsible for shipping product—delivery. Whereas with Product Managers, it’s more about—well, in a way—product discovery. They have to figure out what is it that we’re building and why should we build it in the first place. Can you talk about what you meant by product discovery in that context?

Wade: Sure. Most organizations don’t spend enough time on discovery. They don’t have a good process for doing that. I’m timid on using the word “process” there beause 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 aren’t incentivized the right way to do it. We’ll probably get into this as we talk, but the outcomes you get are really based around how you incentivize and motivate your team.

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. If you’re a publicly-traded company, that’s what 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 with somebody who’s more innovative. So, the idea is that—for the most part here—is that for the past two or three decades, as software development has matured, we have been trying desperatly to try to find the right way to build software. We figured out that it was different from the Industrial Age—that’s where the whole agile [methodology] came from, where we realized [that].

And, it’s different from hardware manufacturing. In the software world we can be a little more nimble about it, but even the birth of agile was back when we shipped sofware on CDs, in shrink-wrapped boxes. Well, the internet came along and changed all of that, and it’s just really unfortunate that, in software, we missed one of the biggest opportunities we had in that we can change things in a moments notice. And that presents us with this green-field of opportunity to learn and to figure out what we’re doing.

Only recently—I feel like within the past couple 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 were not just doing this for ourselves. That we’re trying to figure 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 will ultimately circle back around and we will be wildly successful based off of them.

So, [does] that kind of answer your question?

Empower your teams

Mike: Yeah, no, I think that sets the table really well. It also partially answered another question on my mind, that was: for the organizations that are more focused on that delivery versus the outcomes and the learning, why is that? You kind of mention, part of it, [is] seamingly external factors. Is it that organizations, they see delivering 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?

Wade: The focus is just on control. People like to mitigate risk. 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. The answer’s just, “wait and see.”

It just kills me how many companies don’t have the grit to be able to tell customers no. The best thing you can tell your customer is, “just wait and see.” Don’t give into the pressure. You don’t have to tell them when it’s going to happen. It really is just that pressure of trying to mitigate risk, or trying to be consistent, and trying 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—which started actually right here in Utah, just twenty minutes from here, up at [Snowbird], that’s where the manefesto was penned—it’s intent and it’s 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 of 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 don’t need the process that a lot of these things try to employ. Then you can find that success. That’s why they slip into it.

You still need delivery. You can’t sell software without shipping it. One of the 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 it is when you hear “dual track,” because a lot of times I feel like people think Waterfall, where you do this, and then you do this, and then you do this, you do this, where you have these two tracks. Really, Dual Track is these two things that are going [concurrently], that you’re discovering and releasing and discovering and release. As long as you understand what Dual Track means, it’s a great concept.

The idea is that you’ve broken down the silos, you’re not throwing things over the wall, you’re discovering what you should build, you’re producing something in the smallest unit possible, [and] you’re validating it. You’re learning, and then you’re feeding that feedback loop. 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 saying that they’re not [the] silver bullet.

The silver bullet is cross-functional, autonomous, empowered teams that can go and figure out things and interate 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 frameowork or methodology flavor-of-the-week.

Toss out your roadmap

Mike: You mention process and how there isn’t going to be this perfect process. One thing that is synonymous with process when it comes to product is the creation of roadmaps. I also read you say something that may not be the most commonly accepted thing, and you know, might be a little controversial—maybe not—but that’s that roadmaps are for the most part, or in certain situations at least, can be counter-productive. Can you talk more about that and [give] us a little more of your take on that?

Wade: Well, I wouldn’t say that they’re just slightly controversial. There’s a lot of controversy. I probably ruffled a lot of features making some bold statements there. For the most part, I think roadmaps are junk. There’s a lot of PMs that that really bugs them to hear [that], or scares them I should say, because they spend half their day grooming backlogs. But I would say [that] 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 you could be doing.

So, am I saying you shouldn’t have any sort of a plan? Absolutely not. But if you have a year’s worth of stuff in Jira, you’re never going to look at it. It’s an absolute waste of time prioritizing something that’s that far out. There is so much that will change between now and then, that whatever you assume is true now, isn’t going to be true by the time you get there. Stop wasting your time working on that.

Do I recommend that you work with a roadmap? Do I have one right now? I don’t use the term roadmap as often as other people do, but do I have a plan? Absolutely. I believe in four-to-six week roadmaps and I believe anything farther out than that is untrue. You’re kidding yourself.

Now, people say, “you’ve got to be kidding me. How’s the business supposed to plan if I’m only looking four weeks into the future? Are you suggesting that we don’t even look farther into the future than that?” No, and this is where somebody can say “po-tay-to po-tah-to” 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 beliver in strategic themes; and I’m a big believer in OKRs.

I believe that there’s this hierarchy that you start with a clear company vision—this is who we are, this is our North Star, this is what we’re trying to achieve. It’s like [how] Elon Musk is trying to bring energy independance to the world. What is this thing we are trying to solve? Below that, you need strategic themes that [reach] through years. Maybe, a year or two. It’s the big company goals that you’re trying to achieve. And then, as I said, I’m a big advocate of OKRs, where you have quarterly objectives that you’re trying to achieve.

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] individual line-items and bugs and things that are sitting in JIRA that is just ticket after ticket after ticket after ticket after ticket. What I’d recommend to everybody—this makes some people absolutely uncomfortable and would freak out, because they say where would I even begin—I’d say, “take it and delete it all.”

Most people can’t do that [though], so okay, if you can’t do that, archive it. But seriously, archive all of that and start with a fresh slate. If those bugs are truly important and those priorities 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. If it really is important, it’s not like this golden nugget of insights 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, bring a team together, and figure out what is the most important thing that we’re going to be working on, and how does that aling 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.

Introduce discovery through visibility

Mike: Now, we actually had a past Product Lunch session on getting executive buy-in, which might be relevant now because, I was going to ask you: let’s say you’re a product person (in the chat, I see a lot of people virtually nodding their heads to this) [and] you’re in an organization that 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 this product discovery thing isn’t just something that we do during one part of the product process. [The we] shouldn’t just be focused on delivery. Any advice or thoughts on that?

Wade: Yeah. I love this question. I actually get this question a lot. My first answer is, “go get a new job.” I love that one and everyone just smiles. The market is so hot right now and I like putting the heat on the companies. They deserve it. If companies are not willing to get serious about delivering value to customers, as the first and foremost priority, then go find another because a lot of them are. It is a very hot market for PMs and UX designers.

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. Here’s the answer that you’re actually looking for: visibility. Just do it. Don’t ask for permission, just start doing it, and visibilty. Here’s what it comes down to: when it comes to executives [and] the board, all they want is results. They want to see that something is working and then they’ll trust you. The visibility is where it happens and you know what? they can’t argue with data.

One of the big mistakes that people make—great PMs and great designers—they’re out doing this research and they’re talking to customers. The problem is that executives aren’t. So, invite them to come with you. If you can’t get them to come with you, broadcast it all over the office, so much that nobody can not hear it and be effected by it. If your company is not holding a Town Hall weekly or bi-weekly, do it yourself.

I was also having a conversation 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—maybe that’s hard for you with IT—but maybe you can 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 to use your product and having trouble doing that.

You should be holding a regular company Town Hall where you team gets up and showcases the things that are happening. A lot of companies make it so 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 that. Here’s what we learned and here’s what we’re going to do about it. And, we’ll see you next week to show you what we learned. Just bring visibility to that loop and executives—most CEOs—they’re going to listen. You show them that you’re actually moving the needle—that there’s the benchmark and you’ve now increased conversion or increased the usage rates or increase 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.

Don’t ask for permission. Don’t bother wasting time with that. Just go and do it and take the results to them and show them. Honestly, in corporate scenarios, it’s all about the numbers. They just need to see it. So don’t be afraid of that. Learn what the key metrics are for your industry and for your product and if you take that to them, they’ll get behind you.

Matt: That’s awesome. I’ve definitely been in scenarios where the key metrics are all in front of everybody, but I’ve never been in a situation where there’s video looping of our customers struggling with our product or key learnings. That’s what everybody should be understanding to, so that’s awesome advice for sure.

Wade: There’s one more thing that I’ll tell you along the lines there. We live in this digital world where I think we use it as a crutch and get a bit lazy. We assume that everyone is looking at JIRA or our product repository or wherever our roadmap is or wherever we’re dumping our learnings—whether it’s Dropbox or Evernote or wherever. You know what? Something that [Paul Adams at] Intercom said that that I’m a big believer in [is] just because we’re working in a digital space and building software, that doens’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. Don’t assume that because you documented all of these learnings and documented your plan that people are looking at it, because you know what? probably no one’s looking at it. So print it out. Go to the local copy shop and print out a huge poster and put it on the wall in a public place so that people see it.

Not a step, a culture

Matt: I love that. I love that idea. For sure. One thing I did want to make sure I asked you was, Product Discovery, it’s not a piece of the process, it’s not a step that you take, it should be engrained in everything you do. Can you talk a little bit more about that and what the difference really is?

Wade: Yeah; absolutely. That’s the place where most companies have struggled. They’ve ether outsourced it to a consultant to do their ethnography research and to put together this perfect package and come back with all of these reports and everything and saying, “here’s your target market, here’s the opportunity, here’s your personas, and here are these things.” The problem 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 don’t look back at them for a couple years. The simple fact is that so many things can change between when you learn something and then when 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 as a continual process. And it has to be something that is done by the entire team. You need someone who’s responsible for keeping the cadance and making sure that it’s happening, but it can’t be something that they do alone and that they pass off.

You can’t do research, make a plan, hand it over to the designer who designs it, hand it over to the engineer who codes it—and hopefully none of this stuff that I’m saying is new to anybody. We’ve been beating this drum for so many years that hopefully it’s really starting to stick. 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.

I recommend doing as much of this as you can in production. 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 in production. You should be working with DevOps, you should have an Agile team that’s completely empowered to build these things with feature flags that can roll all of this out to production, test it in labs, doing product discovery calls where you’re walking your customers through all of these things, and then after every single moment, you’re pausing with the team to talk about what we have learned and what we’re going to do tomorrow.

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 two [each] day. After that, we get together. This is a couple engineers and the PM. We review the design. We get together and review the notes. We listen to a recording of the call. We talk about what we have learned and about how that changed our assumptions.

Do we need to pivot? Do we keep moving forward? Then the engineers go and implement some changes into the product. They tweek something. We put it back out on our test server. Thursday, we get back on another call with a customer. We walk them through it. Part of it is an interview process. Part of it 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 and tweaking that in the actual code. We then roll that back out to [a] test [server]. And then do it again. These are things you can do right in product behind feature flags so that it’s not effecting your entire user base, but the learnings are so real, so raw, because the customer’s actually working with their real data.

That’s how you learn. That’s how you create great products. You need that tight feedback loop.

Measuring success

Matt: Yeah. I like that. We’re almost to the end of our time and I want to make sure we go to an audience question or two and one of them is pretty timely and it has to do with, “hey, for product manages and 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 saying this is sufficient and we push the product through.” How do you set that acceptance criteria? Do you have any good advice for that?

Wade: My first thought is sooner than you’d think. Most people hang on a lot longer than they need to. I’ll offer this to see if this helps. We set different criteria for three different phases that we have and it’s really, “is this breaking or not?”

We have a prototype that we’ll use during the initial product discovery calls. It can be completely broken. Meaning, they might be clicking on things; that it doesn’t even work. The forms don’t even submit. That’s good enough to learn there. We’ll work through that, working out major usability issues and making sure that they actually get what they’re doing and that they can achieve it.

Then, we’ll move it into Labs where they can opt-in to participate in this (it’s on production, but it’s in Labs). To get there, it needs to be at least semi-functional. There can’t be major problems.

Then, once we get past Labs and we’ve worked out all the kinks, and we’ve figured out that it’s delivering the actual value, that’s when we move to a phased release. We’ll force it on customers instead of opting in. We’ll force it on, rolling out 5%, 10%, 20%, 50%. If everything’s good—no red flags, no problems—then release it to general release.

The questions is that I think they’re asking, is when do you go from Labs to [forced release]? The best advice that I can give you is it is something you need to have determined ahead of time. Because if you get that far into it, you can cycle forever. You’re getting heat from an executive to release. You’re getting push-back from the team saying it’s not perfect—beause we never want to release our baby. We always can see how it could be better and things we could fix. And especially when 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 iterating.

The best thing you can do is because you start a particular project or particular phase, is to sit down and say, “what is it we’re trying to achieve here?” 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. In your project brief, you should be specifically stating what it is that you’re trying to achieve. What is the Job? Keep it simple: this is what we’re trying to achieve. We’re trying to help the customer do this. Or, this is the outcome their trying to achieve. And that’s the answer. That’s when you roll it out of labs and into production: the moment they can do that.

Another key that you need to know though is, “how do you know if that’s happening?” Once again, you can be watching things, but for the company to buy in, they don’t want just the touchy-feely. So you need to have some measurable type of benchmark that you can base that off of. It’s kind of like OKRs if you’re familiar with that. Your objectives should be warm and inspiring, but your Key Results should be very clear and very measurable. They should absolutely be quantitative, that you can measure those and prove that you met that Objective.

What’s your hypothesis? This is what we want to do. Here’s the benchmark. Here’s how it is today. And then here’s the result. This is the result we’re going to see in the market. We’re going to see this type of activity from the customer. We’re going to 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. That’s where we hit that, when we have something in Labs—the moment they can do that, then we start rolling it out.

Colocation, collaboration, and retrospectives

Matt: Thank you for that. Wade, it’s crazy, but time has flown by. We’re pretty much at the end of our time now. I know we could continue talking, but actually…

Wade: Yeah, I wish we weren’t. I’d like to keep going.

Matt: Well, I’ll tell you what. I’ll ask once last audience question for you, if you don’t mind, and then I definitely want to know how people can keep tabs on what you’re doing. I know you write often and there’s other work you do as well.

I will ask this other question and it has to do with what you had mentioned in the past about having everything up there, physically up, in front of people like that. 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?

Wade: First off, I’m not a big advocate of working from home. I’ll throw that out there. I’m sorry if I offend any of the viewers. I understand that sometimes it’s the way they go and it’s hard, but throughout my career I just cannot deny the effectiveness of in-person conversations and people sitting at a whiteboard. There’s just no way around that.

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, 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 by documenting things. What I would recommend is having a central repository where you log all of your [project] briefs, you log your research schedule, you log all of your learnings, and you need to synthesize the learnings down into bite-size piecess so that people can consume it.

People are never, on their own, going to go where you keep this information as a team and just browse it. Everyone is too busy. Your CEO’s not going to do it, senior leader’s not going to do it, unless you trickle that, drop that into their face. I still have not found a better tool than a wiki—an ugly, old-fashioned wiki. It doesn’t need to be pretty; it needs to be accessible by everyone. 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 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. You can click into the current project (or maybe something like Confluence—someone just mentioned that in the [chat]—that would work), but you need to have a list of here’s all of the current things we’re working on, be able to click in and see the project brief: here’s our hypothesis, here’s our benchmarks, here’s what we want to learn, here’s our product discovery schedule. If you’re recording your sessions with your customers, don’t send people links to an hour-long recording, there are tools that help you go in and find one or two twenty-second clips and then share those.

I’ll also give a shout-out to something called Dailies. I assume most everyone’s using Slack. There’s this really cool thing that I learned from a team here locally, Pluralsight (credit to Nate Walkingshaw and Jacob Burdis). They started this channel in [Slack] 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? And don’t spend too much time on it, just a couple minutes and crank out a couple of sentences, a paragraph for each of those.

That kind of retrospective about 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. 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 coworkers or your boss can happen based off of that little report that you gave.

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 I encountered. Here’s what I learned. 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 make it better.

Matt: I can totally see if you start doing that it can be infections. Other people start doing that and that’s just better for the organization too.

Wade: Oh, yeah. Absolutely.

Conclusion

Matt: Well, Wade, thank you for taking the time with us. I thought that this was a great session. Could you let everyone know how to keep tabs on your work and what you’re doing?

Wade: Absolutely. My website is wadeshearer.com. If you want to get in touch with me, on that website, I list events that I’m involved in and running, different places I’m speaking and whatnot, and then my contact information. I’m also on Medium: Wade Shearer. And then on LinkedIn. Several different ways to get ahold of me.

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

Wade: Thank you. I wish I could tell the audience to come get tickets, but unfortunately, we’re sold out. Definitely keep an eye out for future though. To put in a plug—selfish if I may—we aren’t announcing this until next week, so this is a sneak peak. You guys are getting the information early. Our UX and Product Management Two-day Bootcamp that we run in Park City, Utah, the dates for that are 4–5 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 four track, two-day bootcamp. It’s going to be incredible. The website is frontutah.com and if you come back next week, we’ll have our new website up with all of the details and tracks and everything. Thanks for the plug there; we’d love to have you out at that event.

Matt: Awesome. Well, I like breaking news here on Product Lunch. Thanks a lot for that, Wade. Thanks for joining us and we’ll see everybody next time.

Wade: Thanks for having me.