EXPERT PRODUCT MANAGEMENT AND MARKETING INSIGHT

Robert Hansen

I like that answer. Taking a little bit of a step back, how would you describe the difference between a project manager, a product manager, a program manager? These are a lot of words that are thrown around.

Someone who's not necessarily in this industry may not know what any of that stuff is and how you would think about them, I’m just curious to get a little bit of help for the people listening.

Eric Wu

Product manager, in my opinion, is, as we mentioned, the voice of the customer. They're writing the requirements. They're understanding what the customer needs. They're working with the design team to develop the actual thing that you're going to be delivering. They're working with engineering to actually build it, as opposed to a project manager.

Project manager is making sure things are running on schedule. They're the person who is making sure everyone is doing their part and keeping you on task.

If you say that, “Hey, we're going to deliver this by the holiday season for Black Friday.” They're the ones who are constantly pushing to make sure that we're on track, or they're at least the voice back to the executive tier that says, “Hey, we're a little bit off track. You should know so that you can do your financial planning or something like that.”

Program managers, it differs from company to company. Some oversee project managers, some oversee product managers. Some act as product managers themselves, where you see these group program managers.

In general, the way I look at it is they're basically a hybrid. Their role is to oversee a suite of products. They're guiding the product teams while also making sure that you're on track for delivery of whatever timeline is set forth.

Then you have your TPMs, which are your technical program managers. A lot of times, they act a lot like project managers. But they're also able to run Scrum or work directly with the engineering team.

They're the type of people who also will work cross-functionally. So they will look at your own project and another project that's in the org and then tie the two dependencies together, identify what those are.

They have, I guess, the authority to basically go make some changes. Of course, they'll consult with the product managers and the rest of the organization. But they have some authority to, “Let's bring these two teams together. And let's have the engineering team to sort it out without product or design involved.”

Robert Hansen

I've seen some program management that is like resource management almost. It’s, “Well, we have a certain amount of humans able to put hands on keyboard over this period of time. We know these projects are approximately this big. And we know that we have XYZ holes in the roadmap that we can slot human beings into.”

“A certain amount of product managers are going to become available around this time. They have approximately the right skill set, slot them in. We have a couple of project managers. One operational project manager, one a normal project manager. Operations would be more launching. Then we have 30 devs that are going to come live that are the appropriate skill level for this particular thing, front-end devs, back-end or whatever is needed for this thing. And go.”

They have this big Tetris board. Everything slots into wherever and with as minimal amount of gaps as possible. They're not exactly project managers, but they're like meta project managers. They're like project managers of project managers.

Eric Wu

It's like the ops side of project management. Yeah, usually, those are larger organizations where they have PMOs. That's what the TPMs do at our company where they look at, “Okay, these are now available. Let's work with that.”

I would say the higher functioning companies I've been at, that's usually the product leadership team that's identifying that. Even at the current company I'm at, my peer group is amazing. We talk all the time. We understand what is happening throughout the organization.

I have a pretty good understanding, even though it's not my area of focus, of what's happening in a different area of the business and whether or not there's a deficiency.

We have the latitude to be able to pull resources and say, “Your stuff is more important. I'm going to defund my stuff to make sure that you're able to hit your timeline because it's more strategic.” I feel like that's where the higher functioning product management is happening.

Especially in larger organizations like Google or Amazon, you have the type of people where the infrastructure or the structure of your promotions are all structured around how big of a project you work on and how successful is that big project.

It's not so much the idea of, “Hey, we're all in this together.” It's a little bit more. Well, if I want to get promoted, I got to work on the bigger project. I need to have that outcome.

Whereas the smaller startups, everyone's in the same boat. Everyone's looking for the same type of outcome. You find more people who are more selfless that way and willing to shift where the most need is.

Robert Hansen

Yeah, I think I've seen project managers that can do both of those things. But I've also seen project managers who are very narrow in what they work on. They literally just take two or three high level things that need to be accomplished.

They, and I'm not even joking here, maybe write 10 sentences total called user stories. Then they fire them off, and that's it. That's their involvement. And the rest of everything is done by other teams, which is completely foreign to me.

I have worked in organizations like that, and it just boggles my mind. I'm like, “Is that it? Is that really all you need me to do? Because there's like 100 other things I think need to be done.”

The way I learned how to do project management originally was everything under the kitchen sink. It was finance, it was sales and marketing collateral, it was SWOT analysis, it was talking to customers, it was talking to Gartner analysts, it was talking to everybody.

You were the glue of the company. Every single organization somehow dotted line into you, which I think is the right way to do it if you really want to be good at this.

Eric Wu

I learned it from you, so I also agree. I've worked in different organizations where it threw me off when they're like, “Hey, you don't actually have to do the finance piece. You actually don't need to understand the P&L. You don't actually need to do any kind of projections of where this is going to go. We have a team that does that for you.”

I'm like, “I don't trust your team.” I would almost never talk to those people, the people who are doing the projections. I'm like, “So, what are your projections based on?” “Oh, well, we're just going to chart what happened last year.”

I’m like, “That doesn't incorporate any of the new features I'm building. The new features I'm building are going to affect these particular metrics, which then are leading inputs into the outputs that you're trying to forecast. So don't you need to know what inputs I'm going to change?”

It's mind boggling how companies think that. But I could also understand as a product manager, it's really tough to be asked to lead the engineering teams, work with the design team, do the forecasting.

You'll still see this. I see these at PMs at Discord, PMs at some of these high-flying startups, where all the PMs are like, “Man, I have no life. I am completely burned out. I'm working from when I wake up till the evening.” From my standpoint, I'm like, “That's how it should be.”

Robert Hansen

Well, because you are a mini CEO. It's exactly the same thing as actually running a very large company. You have to understand sales, you have to understand marketing, you have to understand what their P&L is. Profit and loss, for the people listening.

You have to understand how this product is going to affect customers and what kind of feedback you're getting from them. If you don't at least have a high level of understanding of all of those different attributes, your company is not going to do well, unless it's just luck.

You really do have to have your finger on the pulse of all of those different organizations, customer support engineering. If you don't understand what they're doing, what their jobs are, and what their pain points are, you're probably just setting them up to fail.

Eric Wu

I know I'd say a lot of product managers never get to that point, especially those who grew up in large orgs. Even where we worked, I never talked to customer support. I didn’t even know we had customer support. I don't even know if we did have customer support.

I never talked to our sales team. I'm pretty damn sure we had a sales team. Especially working at earlier stage startups, you had to do everything. There was no other team to create collateral for you.

The sales team needed something to sell, “Well, I've got to go jump on a call with the salesperson and talk to the client or the potential customer. What are we actually trying to build for them?”

I think that's especially one of your questions of, if you wanted to get into it, where would you start? I think some of those early stage startups, at least the ones that are super early, where I would say they have 30 to 50 people in the company is a good size, where you'll wear lots of hats.

That's what a product manager does. They have to wear lots of different hats or have different roles. But you'll get exposed to a lot more things like customer service and sales.

That makes you stronger because you'll be more in touch with how you're trying to get the product to market as well as how to sustain and retain your customers. You'll be able to have empathy when you're thinking about the whole product holistically.

Whereas, I see so many big companies where you ask the product manager, “Hey, when's the last time you talked to a customer?” Some will say they've never talked to a customer the whole time that they've worked there, and they could be working there for years.

That's just crazy to me, “Oh, we have a user research team that does that for us.” “Do you sit in on any of the user research?” “No, we just get the videos.”

Robert Hansen

Or maybe not even that.

Eric Wu

Exactly, where they may get the videos and may not even watch it. That's very common.

Robert Hansen

It's extremely common. It's frustrating to me because I think a lot of people, they'll just accept that the little feedback that eventually trickles down to them by the 14 different layers that gets through to finally reach their desk is the story.

It's not the story. It's not even part of the story. In fact, the customer doesn't even know the story. There are so many opportunities. I'll get to this in a little bit here.

There's so many opportunities to get ahead of where the customer's expectations are, as opposed to just doing what they want today. But we'll get to that in a minute.

I want to jump a little bit to something about marketing, since you are an expert in it. In my little world of security, one of the things that's very annoying to me personally is the people who understand security are maybe one or two people in your entire company.

Maybe you have 10, if it's a big company or 20 or something. But it's very few people, if any. What we haven't done is socialized a really good way of thinking about security product management.

There are always the requirements that need to be in every single product requirements documents if it's hitting these different attributes. What is your feeling about marketing? Does it have a similar thing? Are people just not baking marketing into this thing? And what does that cost you when they aren't doing that properly?

Eric Wu

I think I recently read two books that come to mind that answer this question. One is Build by Tony Fadell, the guy who basically invented the iPhone and Nest Thermostat. Then another book called INSPIRED, which comes out of the Silicon Valley Product Group.

It's basically the product marketing team. If you don't do marketing well, it doesn't matter if you have an amazing product if nobody knows about it. The idea of a tree falls in the forest, and does it actually make a sound?

You need to get the word out. Getting the word out is very specific. I feel like a lot of people do it wrong. And maybe this is what's happening in the security space where the product team’s like, “We built it. Go market it. Go sell it.”

You're like, “No, we should have done this together.” Especially in this book INSPIRED, they really hone on this idea that I've seen in person of the marketing team tells you what the market looks like today. Where are the personas? What resonates with people? What do you actually need to build into the product to get adoption?

You can build an amazing feature set that solves this crazy pain point. But if you build in a way that person doesn't understand it, you will never get adoption. That's when you look at this concept of skeuomorphism.

Skeuomorphism is this concept where you're taking real world physical products and making them and digitizing them. If you look at your reminder app or your note taking app, it's got ruled lines.

There's no reason it has to have ruled lines. They make it look like a yellow ruled pad. But it's a way that's familiar to the end user. They're then able to like, “Oh, I understand what this is. Let me then use it.”

Then you can evolve the product over time based on that. But it has to start with something that is at least somewhat familiar to them. That's where a lot of product managers miss the boat.

They do the research, they understand what the pain point is, they understand what the true first principle need is for the customer. But the end result still ends up being something that never gets used.

Then the other thing that happens with marketing that is extremely valuable is just the idea that when you're bringing them early, they now know how to message what is going to market and they can understand the core principles that you care about.

A lot of times, if you look at some sales team and marketing team that don't work with the product team, the sales message is different than the marketing message, which doesn't even do anything that the product actually does. They've positioned it wrong.

I would say that's what we've done, at least well, at Honey, where we've worked with influencers like MrBeast. That comes out because his brand is all about giving back to the end user and giving away money, and he's known as being generous.

Our product is known for saving you money. So there's huge brand alignment there. Whereas, if you had marketing team and the product team separated, we would probably just be just spending money on coupon savings, mama bloggers and stuff like that, which sounds like it makes sense.

Yeah, we’d get traffic from there. But that's not where we really resonate and where the people and the customers are like, “Hey, this makes sense together.”

I always tell the story to a lot of my team as far as when they think about marketing and they think about branding. Everyone knows that Oprah gave away a car. “You get a car, you get a car, you get a car.” Do you remember what brand car Oprah gave away?

Robert Hansen

I definitely do not.

Eric Wu

Nobody does.

Robert Hansen

I think it was a red convertible maybe.

Eric Wu

It was a Pontiac.

Robert Hansen

Mustang or something. I don't know what it was.

Eric Wu

No one remembers the brand because Pontiac’s brand and Oprah's brand just don't match up. If it was something like a Prius, maybe you could position that a little bit better like, “Hey, this is helpful for the environment.” Oprah is helpful.

Then you could do something a little bit more that makes sense. But if you don't bring marketing in early enough, they won't understand what you're actually trying to sell. And marketing is sales effectively.

Robert Hansen

Yeah, a lot of people don't get that. They really don't get that, which I think is funny. Because an incredibly good marketer with the right product literally needs zero salespeople, but sales are happening. How does that work? So that's interesting.

This is one of the small areas that I really think product managers need to talk to one another. Most of the time, I think they stay siloed and probably don't even know each other exist.

If you get a really good product manager who really understands their area of expertise, they're really good at the back-end database and how that's all working and the infrastructure components of it and then somebody who’s really more front-end focused and they don't talk to each other at all, all kinds of weird things can happen.

It is worth having them in the same room. In this case, if you're launching a product with a website associated with it or something, you might want to talk to somebody in your team who understands SEO and say, “Well, how should you build this thing?”

If you don't build it right in the first place, you're just leaving a lot of backlinks on the table that you could have gotten. Or brand affinity because you're using the wrong words on here or whatever.

Eric Wu

The organization that I run now and in previous places, too, I've run basically a product growth organization. And it's this interesting hybrid between product management and marketing, where a good quarter percent of my time, my engineering and my product managers are spending building stuff for the marketing team and educating the marketing team what the product is.

The other part of the time is really around onboarding and reducing churn and the whole buyer's lifecycle of how do we bring them back and building the infrastructure and the experience around that.

If you don't get the marketing message right, then when the person comes to get onboarded, they don't have that right context. Or if you want to bring the person back and you send them a marketing email and the landing page or where you're putting them back into the product doesn't match up, then you basically have a broken experience.

That's why a product growth organization exists these days. A lot of times a product management team is thinking about, “What features can we build?” They're not really thinking about the whole customer journey loop from acquisition to retention.

When you have a product growth group that's thinking about it, retention is a huge power to any kind of organization. You spend so much money to bring somebody to your place of business.

If they don't stick around, then you've just wasted a lot of that money. So we spend a lot of time making sure that that first time experience is great and every single time we bring them back is great. It's just effectively being a good host.

Robert Hansen

It makes sense. I think the funnel is one place where marketing is really a data-driven thing, in large part. But there's a lot of things that are so obvious that people just get wrong.

If you ask for the zip code ahead of time, they don't need to answer what city they're in. Or if they're clicking on a link from an email, you don't need to ask them the email again. Or if they went through a registration flow, you don't have to ask them to log in again. You already have their password.

Little things like that that are just so obvious. Yet, almost every company gets it wrong. Even just looking at the funnel and just going through it a few times like, “This feels clunky. Why do I have to do this?”

You don't have to do it is the answer, and marketing can help. Marketing can help you with these little onboarding issues in the funnel and in monitoring user adoption and where they start abandoning. There's a lot of things that marketing can help with in that process that I think people just aren't taking advantage of. Or a lot of sites would be a lot nicer.

Eric Wu

I 100% agree. Also, at least with the examples that you're putting out there, I feel like a lot of that is also what I call me-too product managers. They see a big company like Facebook or Google or whatever have this design pattern or have this login pattern or whatever it is. And they're like, “Well, if the big guys do it, it must work because they've clearly tested it.”

Yeah, well, it probably works for them. It probably won't necessarily work for you because you're not addressing billions of people. One of the things I think I've shared with you in the past but I think is a poignant point is that when I worked for a flower company, it was a marketplace for florist.

In flowers, a lot of it is gift giving. Sometimes you buy flowers for yourself, and sometimes you buy it for other sympathy reasons. But a lot of times it's gift giving.

In e-commerce, the normal thing to do is to put the most difficult thing at the end of the checkout funnel because you want to get as much momentum as possible. You stick the most difficult thing at the end, which is typically the credit card.

Then you're like, “I've now captured that user. That's the best way to think about that conversion funnel.” What we looked at though, and this is coming from market research and understanding the user psychology, is that in gift giving, you usually have to write a note.

Writing a note is a free-form field. And it's really a tough thing. A lot of gift giving websites put that at the very end because they think that it's the most difficult thing.

If I got you to put your credit card number in, then you're going to write the note. That actually isn't the case. What we did was we put the note first. That sounds super counterintuitive because it's the most difficult thing. You haven't even asked for their phone number, their address, their email address. Write the note first. But what we're banking on was this idea of an emotional connection with-

Robert Hansen

Immediate.

Eric Wu

Exactly. The imagery that I like is there used to be this old Volkswagen commercial, where there's a person. They're looking at a Volkswagen. They really love it. They're on the phone, and they're telling the person on the phone how much they love it.

Then the camera pans over. You see two people and the salesperson coming out of the sales showroom walking to the car. The person by the car panics. What they do is they lock the door handle. And they're like, “I'm going to lick all the cookies and claim it.”

That person had already bought the car, in their mind, before they actually even drove it or purchased it. And what we wanted to do is we wanted to tell people, “That flower arrangement that you're sending, that's yours already.” You haven’t even bought it.

Gift giving, you don't even see the gift, especially in flowers. You're sending it halfway across the country or halfway across the world.

Robert Hansen

You have a vague notion of what this thing looks like.

Eric Wu

Right. We wanted people to have that feeling, “I own this.” even before they checked out. And what we saw was, yeah, you're going to get drop-off from people not completing the whole card note.

But after that point, 99% of the people completed their checkout. You now have a strong emotional attachment to this product. No one's ever going to abandon it.

Robert Hansen

They definitely don't want to write that note twice.

Eric Wu

Exactly.

Robert Hansen

That was already hard.

Eric Wu

Exactly.

Robert Hansen

I like that. I see there being a lot of chances to abandon in a lot of these scenarios. But if you design a really clever flow like that, why would you? You're so committed.

Also, I think a lot of people are confused by websites because websites are confusing and they work differently, where they really feel like if they walk away from their computer, something's going to timeout. It's going to go to a different page and say, “Oh, sorry. We just lost what you just did.”

If they're not fully committed right there and then, there's a strong possibility whatever work they just did is gone forever, which is a massive problem with the way websites in general have been architected throughout the ages. But it is what it is. You can use that to your advantage as a marketer.

If you had to pick one, would you pick Agile or Waterfall? You only get one for the rest of your life.

Eric Wu

I would pick Kanban. Neither. The funny thing is, I would say most people like, of course, Agile. There's no way that you would ever pick Waterfall. Waterfall is old. Why would you ever do it that way? I see some value in Waterfall.

I feel like certain products, the way that they're built or the way they’re designed especially when you're talking about physical goods not digital goods, look at the success of the iPhone.

You need to make sure that thing is pretty damn polished. Of course, it's got problems. Everything has problems on the first run. But they've done such a good job. I'm sure there's some Agile process, where they're building prototypes, and you can call it Agile.

For the most part, you got to really plan out what the end product is well ahead of time. It's not like this, “Oh, we're going to just try it today. A/B test it, and we're going to pivot into whatever the outcome is.” You just don't have that same opportunity.

Even in some digital products, that's the case I've seen where you have such a large audience and you don't want to alienate that audience. I've seen in some products where the community is so powerful even when you give them something better, they go from effectively Craigslist looking things to a new, shiny startup with the latest widgets, technology and everything.

The community hates it because they don't like change. And in those cases, something like a Waterfall process makes a whole lot more sense where you're taking a lot more time to really understand the customer, what their pain points are, and how to transition those people over.

Robert Hansen

It's funny that you are talking about this because what you were talking about earlier, where you had multivariate testing and A/B testing, I think that that is one way where you can get the best of both worlds.

You can have this really stodgy, old product that takes forever to launch or whatever. But you don't have to do it, just launch it and be done with it. I think everyone's a little afraid of Waterfall because it's either on or it's off. But that's not true.

There's ways to roll it out progressively to some percentage of the traffic or only turn it on for certain users that you know are the more advanced users or more vocal users who are more likely to cause problems.

I remember at eBay, it's a little bit different story but along the same lines, we were changing everything from old default Netscape gray color to new Internet Explorer 5 white background color.

Everyone was really freaked out by this because even if some small fraction of 150 million users calls up and says, “Hey, what's going on with my eBay?” you have just exploded your customer support team. So that is not acceptable.

Instead, what they did is, every single day for the last month, they changed it one shade closer to perfectly white. And they call it white Christmas. So over the process of a month, no one noticed. Literally, not a single person called eBay and complained.

I think there's ways that you can do all the things that you like about Agile. One of the things I wouldn't say that’s wrong with Agile but hides, the Agile allows bad product managers to hide.

I don't like that because you end up with bad product. But it comes down to user stories because I think user stories are very powerful and very useful, especially if you're trying to have somebody with zero empathy to understand customers because a lot of product managers have a little Aspergery sometimes.

It's good if you have them write down what the customer is specifically asking for. That's true. But if they're not translating that into what the customer actually technically needs, not just what’s their user experiences, but the underlying what this thing's supposed to do on the back end, you're basically just making the engineering team do product management.

You're asking an engineering team to understand the customers and do all that work and understand how things should be colored and where things should be on the page. Effectively, the product manager’s like, “You figure it out. I'm not going to do that.”

In that way, I think you could take the best of both worlds, which I know I didn't give you this answer. So I know I'm sliding in the middle answer here. But I think you could take the user stories out of Agile, put them in Waterfall, and get a lot of the same value. Or vice versa.

You could take an old timey product requirements document. It's very technical and dense and has a lot of things going on to it and slide it underneath each one of the user stories like, “Well, here's what I mean by this.”

I actually did this at WhiteHat. I took user stories. Boring, old, one-sentence user stories that are, in my point of view, almost next to useless. Then I’d write underneath those user stories, effectively, the product requirements document. I’d write, “Here's what I actually want you to do.”

I remember the engineering team came up to me on two different occasions. They're like, “This is the most well-written product requirements document that I've ever seen come out of this company.”

I'm like, “Well, yeah, that's because it's written like a real product manager would write these things, not just throwing some user stories out there, which to me seems more like something that would come from customer support.”

As a customer, here's what customers want. I understand customer support writing those. But a product manager needs to flush that out and turn it into better requirements.

Eric Wu

Yeah. The point on user stories, I've seen user stories not even like, “Hey, you've got to write all the other stuff with it.” I've seen these bad user stories where the whole user story is supposed to be, whoever the actor is, “As a customer, I want this.” And whatever you're going to measure.

I've now adopted what is this idea of a job story. There's this concept called jobs to be done. It comes from this gentleman named Clayton Christensen. It ends up being, really, what's the true reason why you're doing something? What is the situation that you're in? And what's the emotional state that you're in?

I've asked my team more and more to basically write job stories, which effectively states, given this is happening, when this is happening, then, “As a person, I want to do this.”

Then you now give context. It really opens up a whole new thing of, “Hey, I don't want to just do this thing when I'm in a rush and my kid’s screaming in the background.” It changes the action that you're actually doing or the implementation of that action.

It resonates more with also the engineering and design teams because they're like, “Oh, I actually understand the context.” I have seen though, interestingly enough, this trend where you see, “I've interviewed some people. I'm in product management.”

I’m like, “Cool. Tell me how you write your product requirements or your stories.” They're like, “I don’t write any of the stories.” I’m like, “What? What do you mean you don’t write stories?” “The engineers write it.”

Robert Hansen

What do you do exactly? What do you say you do?

Eric Wu

“What exactly do you do here?” “I'm a people person.” Literally, that's what they are like, “I'm a people person. I talk to the customer.” I'm like, “What? The engineers figured it out?” They're like, “Yeah. It's great, right?” I'm like, “I guess. You only do half your job. Of course, that's great.”

Robert Hansen

You don't get blamed when it goes terribly wrong.

Eric Wu

Right. It's like, “Oh, well, the engineer decided what that was.” I’m like, “That’s crazy to me.” But I feel like there's this trend that's happening. I don't fully understand it. And part of me feels like I'm getting old or something, like I'm disconnected. It’s true.

Robert Hansen

I hate to tell you, but we’re all getting up there. This might be the most contentious question I ask you, but I think I know the answer. Do you think that product managers should be technical in whatever field? I know a lot of people can get very angry about this very specific question. Do you think that they should be technical in whatever area it is?

Let's say it's login, should I be a good security person? Let's say it's a new blog or something, should they be good at marketing? Or whatever. Do you think they should be technically accurate enough to go down to the engineering, where they can almost put their hands on keyboard and do it themselves? Maybe not with that level of sophistication but just shy there.

Eric Wu

That's an excellent question because that's a question I ask people I interview.

Robert Hansen

Oh, really?

Eric Wu

Yeah.

Robert Hansen

Okay.

Eric Wu

Especially myself, coming from an engineering background and then learning a lot of back-end and lower level type of stuff from yourself, I've always leaned on being more technical.

You look at the Googles of the world and the Metas of the world where, honestly, a lot of their product managers are ex engineers. And there's this whole mythology around you have to be strongly technical to be a good product manager.

While I agree, for the most part, I would say, there's definitely a lot of roles where it is way better to be technical. Not even just, “Hey, I could do it myself.” But it does build so much credibility when you're working with an engineer.

If I can pull up Terminal and show him like, “Hey, I know bash scripts.” Or, “I know how to use Vim.” which basically you forced me to learn, it helps with that. I understand where you're coming from.

Robert Hansen

You’re welcome.

Eric Wu

It builds that rapport that nothing else can build. It just instantly gives you credibility, and then you build that relationship with the engineering team. Then when it comes to certain things, especially with security or accessibility or some of these more nuanced things like login, login and identity is always the most interesting thing.

You get some CEOs like, “I just slap a login on that.” And I'm like, “You realize that's a lot of work? You got to send the email. Do you want magic links? You have password reset. What are the other requirements around that?”

Robert Hansen

Do you want to stop brute force or not?

Eric Wu

Exactly.

Robert Hansen

There’s quite a few versions of that as well.

Eric Wu

Being technical is extremely valuable. But I would say, myself being very technical has held me back quite a bit, having worked with a lot of different founders, especially Honey.

I met the founder six years ago. I didn't join the company until about two and a half years ago. Every six months, the founder would come like, “Hey, Eric, would you like to join the company?” They exited for $4 billion. If I had joined back then-

Robert Hansen

You wouldn't be here.

Eric Wu

-I wouldn't be wearing this. I'd be wearing something completely different.

Robert Hansen

But you'd still be here.

Eric Wu

Exactly. I’d still be here. Of course. But it wouldn't be an Apple Watch. It would be a Rolex with an Apple Watch on this arm. If you're super technical, what I find is that it holds you back in the sense that your mind goes to, “Is this possible? Is this actually feasible? Does this fit with all the engineering tech stack that we currently have?” which is extremely valuable in a lot of cases.

When you're trying to think of something from zero to one and invent something completely new that the industry has never seen before, you need the people who basically don't have any boundaries.

It's the idea of, how does a bumblebee fly aerodynamically? It can. I don't know if that's true or not, but then no one's told it that it can't. So it does. That's what you find with a lot of these founders who, quite frankly, I’m like, “That is the stupidest idea I've ever heard.”

As a person who's learned, I'm like, “Cool. That's a dumb idea. I'm going to follow you off that cliff. Let's do it.” When it ends up working, you're just so amazed that you're like, “I don't get how this works. But it does.”

I wish that part of me was less technical because of those things because I can't see those innovative things that really are, in a lot of ways, changing the world. The current joke of Mark Zuckerberg saying, “Hey, we got legs now for our VR product.” is hilarious.

In the very early days, I tried the first Oculus. They're like, “There are no hands.” “Why are there no hands?” “Well, we couldn't get the latency down where your hands are moving at the same speed of what you're seeing visually. So people would throw up all the time.” Then you're like, “Oh, yeah, I don't want to throw up.”

Just having hands was a breakthrough. So when people clown on the stuff that's happening where like, “Hey, I got legs.” The way I look at it is, that might actually be super important. You just don't know. And all the other people who are clowning on it, are basically like me.

You're just like, "Oh, that's so obvious." Or like, "Why does that even matter?" Or, "Hey, no one cares about that." In reality, it might be the feature that makes that product actually mainstream.

To this day, I still don't use VR stuff. Even though it looks interesting, I consider myself somewhat of early adopter but it just doesn't make sense to me as far as either being practical or even as entertainment. I'd rather watch YouTube or Netflix or something else.

Robert Hansen

The RSNAKE Show

Eric Wu

Or the RSnake Show, of course. But those are the things where if you are not technical, and I know Zuckerberg is probably technical, but some of the people that are Pio ideating these things, they are at least able, if they are technical, they have a superpower where they can put that aside.

Put that on the table over here and say like, "Hey, I'm going to put the technical over here and think crazy." It is something that I've learned to do over time. This idea of like, how do you do 10X thinking, 100X thinking?

Even 10X thinking, now that I've been into it, I'm like, "10X thinking isn't enough." You actually need to think 600 times, 1,000 times X. Which sounds crazy, but that's what products have done. That's what the mobile phone has done. That's what chips have done over time.

Thinking that far, and if you're letting technology constrain you, then you're never going to be able to change the world. I feel like that's kind of, at least personally, I want to have more of an impact on the world in a meaningful way, not just in an incremental way.

I feel like that's where people in product management, if you're technical, great. But also learn how to kind of put that aside. If you're not technical, don't rush to necessarily be technical. There are advantages of not being technical.

Robert Hansen

I actually came up with a little thing that I do just to allow my brain to relax, because I too, I'm quite technical. I find that I can be a little rigid in my thinking sometimes, and I don't like that. I like to be more flexible.

So, what I'll do is I'll take two completely random things. Just like the beach since we're here down on the beach and Jameson, since I'm looking at a mini-bar with Jameson. They're not paying me by the way. I'll think, well how are those two things related? Off the cuff, they aren't at all.

But then I'll spend the next couple hours just saying like, "Well, people could drink Jameson on the beach." Maybe Jamison doesn't work well on the beach because it's a kind of open bottle and they're not going to allow it.

You have to have plastic bottles and just start letting your brain relax and think of Jameson and beach at the same time and don't be rigid about it. Then think like, "Well, why doesn't Jameson come up with a brand for the beach. A beach branded Jameson and kind of just keep going and just let it happen.

What you'll find the more you do, I don't do it this exercise very much anymore because I've kind of gotten over the point where I can do this pretty easily, but when I got started it was really difficult. I was like, "These things aren't related. They really aren't related."

But then, maybe they're not directly related, but there's like one degree of separation and I can create that little linkage.

Actually, sort of, they are kind of related. I was doing this at some point, I think with Karim Hijazi, on his Podcast. I was like, "Taxes and cell phones." How are those things related? Well, they're not.

But actually it turns out you can tell someone's tax bracket more likely by which phones they have. Maybe you could tell which states they're in and then tax them differently because it turns out they're in California Nexus and all kinds of stuff.

Then it becomes they're very related. You can do these weird things in your brain and just let yourself open up.

Eric Wu

I think that's a great exercise.

Robert Hansen

It's kind of fun anyway.

Eric Wu

Yeah. I'm definitely going to try to do that.

Robert Hansen

It is fun to play on somebody else where you are the one who comes up with it, that way it's not their brain and now their brain has to deal with this weird thing you just said.

I mean, ultimately I agree with you. I think being very rigid in your thinking is a trap. I think thinking of what is current and what is possible with today's technology is a trap.

You always have to be on the lookout for, "Well, I heard this one guy is working on this one thing, this one place. It's not quite there, but it's close. Maybe you could take a look at their technology. It's not what we want to do, but it might be some directionally inspirational. We should go take that guy out to lunch." You can get pretty far along even with a technical mind. I promise you.

Eric Wu

At least like for myself, what I've learned to do is drill things down to the first principles. Just like, "What is a core thing that makes this thing tick?" Effectively build it back up, but build it back up in a way of saying like, "I wish it did this."

If you just keep on saying like, "I wish it did this." You're like, "Well, it's never going to do that." Then you ask yourself like, "Well, why couldn't it never do that?" Then how might we basically make it do that thing that you wish it could do."

Robert Hansen

But that's way too expensive but maybe it's worth it. Maybe we should do that. That is one area that I think a lot of people get constrained by. It's like, "Well that's a lot of work." That's why we're going to need some engineers and some money.

I am firmly in the camp that being more technical is better. I am firmly in that camp. Not to say that there isn't room for non-technical product managers, I think there is. I mean, I think a lot of CEOs are exactly that, right? They're non-technical product managers telling other people what to go do. But it's still very valuable to know how it all works.

Not necessarily the bits and bytes of the underpinnings and whatever, but even that sometimes quite useful. I've definitely been in meetings before where engineering, they're pulling their hair out, they're like, "I don't know how to do this." I'm like, "Well, let's get on a whiteboard and let's figure it out together."

We get there. Ultimately they have to code it. They're the ones doing the hands on keyboard but it's iterative. It's working with them and if I literally gave it to them to solve, I'm not sure it ever would've gotten solved.

Eric Wu

I've definitely been in those situations. I would say what's nice about the industry that's changed a lot is the QA department is very much not manual QA anymore. You have STATS, you have real developers doing effectively doing QA.

I find those people are the most interesting people to talk about the product with, especially when you get into these weird conundrums of technically is it possible or not? They're kind of in that position where they need to very much understand how the product works from end to end and do all the integration tests.

But they also understand how the technology works at the same time. So, if you're not technical, those are great people to kind of lean on.

But I usually try to make friends with the STATS as much as possible because I'll take them to lunch and we'll just like go back and forth and they'll reveal stuff to me. I'm like, "I never thought of that." I'll reveal stuff about the customer that they're like, "Oh yeah, we should do that."

They are empowered to be able to then work with the engineering team to make certain changes. But yes, having that technical background really does unlock certain things.

Robert Hansen

I firmly am in that camp. Also because I've seen a lot of very bad product launch by people who if they had just been even slightly more technical, they would've seen this coming. It's like, that was never going to work. Never in a million years.

Never ever going to work. You just don't have the mind for how technology in general works. Not even programming language, just in general. I think that this is not taught anywhere.

I gave this one class this one time it was a security product management PLA class. I gave it twice, only twice, both to the same company. It was a government contractor and it was four hours class and it was a war game. One half of the class, they're the product managers.

They were building product and they got I think 100 points for every flow that they created. You get 100 points for if you make registration, log in, send a friend functionality, forgot password flow. Every one of those flows gives them 100 points. They're heavily incented to launch product.

The other team, they're the hackers and they're just heavily incented. I think they get up to 100 points for every percentage of data that they exfiltrate out of the system per round, and five-minute rounds. My role as the proctor, was I'm two things.

I am the most overbearing boss in the world who will deduct points for every thousand dollars that they spend to build the thing. They get one point deducted above and beyond the engineering staff.

If you have to put a firewall in there, if it's a $50,000 firewall, minus 50 points. That kind of thing. If you have the hire staff and they're $ 100,000 a year, minus 100 points. You know what I mean? Whatever thousands of dollars, you get points abducted.

I'm also the world's worst engineer. I don't mean not capable, I'm the most capable engineer. I'm just the laziest engineer. If you say build a login page, I will build a page with a username and a button that says log in and doesn't even have a database on the backend. You click the button no matter what you do there, it'll just take you to the next page.

Everyone hates those team-sport-type of training. Everyone hates it. They always hate it until the second round. When they realized how bad developer I was, I was the real threat, not the hackers. It was me. They were having to work around me.

By the end of this thing, it was frantic. By the end it was real close. Both the times I did it really, really close score. One time, the other time the other one won. It was pretty even.

They both won in weird ways as you'd expect. They were kind of hacking each other, trying to figure out ways to game the game, which was great. It was all fun, everyone having a good time.

But there was three gigantic whiteboards. I mean, these are 20 feet wide each, five foot tall. All of them were completely covered with my writing, basically showing you said. "Hackers wants to do X and here's what's going to happen and why."

So, every time the hacker tried something, I'm like, "Yap, it worked because you didn't put these controls in place. Because you never told me to put these controls in place." Then they tell me to put the controls in place. I'm like, "Yeah, but you didn't tell me in what way to do it so I did it in the dumb way."

I'd give them all these terrible... They're really fighting me and I was the real enemy if you really think about it. After the whole thing's over, I gave three questions.

I'm like, "Okay, first of all, is there anyone in this room who thinks, with three gigantic whiteboards full of security things that you think you've built, does anyone here think that I can't break into this website as it's currently designed?" Of course, no one raised their hand.

I'm like, "Okay, well here's the three ways I do it just off the top of my head." I'm like, "Okay, second question." I mean, these are massive whiteboards. These are huge. I mean, the biggest ones I've ever seen kind of thing. The three of them. Two on one wall and one on another.

You're looking around, "Does anyone here think that you've ever seen a website that is as well designed with as many security features as this website is?"

Everyone's like shaking their head no, because I mean, this is an insane amount of work. It's four hours of them thinking through security, product management. Designing the most important critical flows that every website has.

The third question is, "How do you think the adversary's thinking about your websites right now. Do you think that they're as secure as this?"

They're just running back to the desk. They're like, "Oh my God, I got to get back there." This is the thing. I don't think people are actually being trained like this. Clearly they're not. Otherwise I would've heard the story from somebody else.

But what does it take to get them past the point at which they're vaguely interested in product, maybe they're interested in security tangentially or marketing or whatever it is to like, "I'm going to jump onto my chair and go fix this stuff."

Now, I've got a much better sense of what my customer, in this case hackers. But it could be the good guys as well think about my application and make it work for them.

Eric Wu

Yeah. I'm not exactly sure what the question is.

Robert Hansen

How do you get that in the head of these product managers? I think they're so behind that me sitting there in four hours completely changed the way they thought about it. How do we get them to start thinking, "Well, I got to actually understand how this stuff works."

Eric Wu

It's both. The way I think about it, it's not just the product managers, but also you as a terrible engineer. The terrible engineer is not very uncommon. Like, "Well, it wasn't in the spec, so we didn't do it. You're like, "What the hell?"

What you're describing a lot of times ends up being in organizations that are very much tops-down of like, "Hey, we want these features." Or "We want login." They don't actually state the problem that the user has. The stated problem was more that, "Hey, we've got your grandma's data behind here and we want to make sure your grandma feels safe about logging in."

It changes the perception of what people are trying to do and it's attaching that emotion to the actual product outcomes that you're trying to look for. These are things that I've presented to engineering teams.

As you go through certain companies, you get attrition and people start leaving. I've gotten in a situation where I don't have enough product managers to actually help the engineers build. They're like, "Well, what do you want us to do?"

I've worked in functional places where the engineers know what to do because you set a goal of, "This is what we actually want the user to feel. This is what we want the outcome to be, and go figure it out."

They end up spending the time to iterate over all the different possible attack vectors in this case and say like, "Well, what's the most common thing? Let's patch those holes first. What is the next most uncommon thing?"

They get to a point where like, "Okay, it doesn't make any more sense to keep on going. Let's release the thing and see what happens." I feel like it's really driven from that kind of that emotional attachment of, what is the feeling that you're trying to get across with this product as opposed to what are the features of the product.

Robert Hansen

Well, you as often say, security, product management or marketing, product management or whatever type of product management, you're a mini-CEO. Now you are an investor as well.

You're a mentor. You're helping these companies out. How do you communicate the value of product management externally into these companies? How do you infuse good product design or whatever into these companies from the outside?

Eric Wu

I mean, a lot of it is kind of what we're talking about. It's no real different than when I am mentoring a direct report or a one-on-one. In some ways it's different because you don't get to spend a lot of time with those people, especially as an investor.

You're hopefully smart money where they ask you for certain advice. It's really about packaging down to like, what are some of those few guidelines that they can lean on when they're in a tough spot.

A lot of those guidelines is, put the customer first. Really think about what problem you're solving for the customer. I tell people to break it down. As we talked about a little bit earlier, painkiller and vitamin, but it's more than just painkiller and vitamin.

There's also placebo and there's also candy. People are like, "What's placebo and candy?" Well, painkiller is very, very straightforward. You're solving the problem and you're trying to alleviate it. Vitamin, it's preventative.

But what a lot of people don't actually think about is you can get adoption of your products by just kind of this idea of one candy. What is the actual user's desire?

There's a lot of things that people want to do that aren't necessarily good for them or solving a pain point. They just want to be entertained or they want to experience some sort of pleasure.

Robert Hansen

Or waste time.

Eric Wu

Or waste time. That's candy. That's not helpful to them. In shopping that I work in, people just want a window shop for entertainment. They want to look at that Louis Vuitton bag, put it in their cart, kind of see how much discount I can get on it.

They're not going to buy it. We want to encourage some of those things because we want those users to feel trust in what we're doing, even if it's a candy-type of activity.

Then there's like placebo activities where you can actually build trust or build rapport with your customer. One of the classics is, I think it was like Travelocity or Hipmunk or whatever, those things where, "Hey, we're searching across the internet."

There's like a little bar that's like, "Hey, we're all these places." "They've got all that stuff in their database. What the hell? Why is it taking so long? Three seconds to search across the internet? You're not doing it real time." But what they found was that, that placebo effect of, I'm actually doing the work, users...

Robert Hansen

You don't want to do this. We got this.

Eric Wu

Right. So, users feel like, "Oh, it's trying hard. Even if it takes three seconds, which is kind of slow, but it's trying and that adds value.

Those are the things that I'll tell some of the founders of these companies, like, "Don't just think about these two things, painkiller and vitamins.

Also consider those other things, even though it sounds silly." It feels like it's wasteful, like, "Why should I waste people's time." While you waste people's time, because their mental perception is that, that's value to them.

I do a lot of reading around Dan Arielli who he writes this book called Predictably Irrational. People are not rational. They're not logical. We think we're logical.

Robert Hansen

We heard the markets would be a lot.

Eric Wu

Exactly. You have to be able to put yourself in those positions where the person's not going to make the logical decision, and you have to anticipate what that non-logical decision is.

Robert Hansen

All right. So, this might be a completely throwaway question and we can always edit it out if it sucks. But I'm kind of curious, curious if you have any sort of big battle scars or whatever.

I mean, you've worked for some enormous companies now. Some of the biggest companies in the world. Any sort of big picture crazy stories that around product management that might be interesting for the kids and some people coming up and worth knowing.

I mean, you've seen a lot of things. You've been to a lot of these companies. I was just going through like Rent Cars, Edmunds, Snapchat, TripAdvisor, Pinterest, Uber, Connie Nast. I mean, those are enormous companies. Anything stand out that would be worth talking about?

Eric Wu

Like a battle store war story?

Robert Hansen

Yeah. From your copious amount of product management. We can always cut this if you don't like the question. I'm just kind to curious.

Eric Wu

I'm just trying to think of a good example. I mean, some of it is not really necessarily product management. Well, I'm thinking about just bad nasty situations that I've been in.

I guess some of it is product management in the sense of it's more from a product leadership standpoint. Which is different than actually thinking about the customer, but thinking about your organization.

When I was at SpinMedia it used to be called BuzzMedia. We ran a bunch of website properties, spin.com, vibe.com, we ran all the Kardashian websites. We ran some of the most popular pop culture and music sites on the internet.

That was one of the craziest companies I've ever worked at because when we got in there, the CEO and the CTO were doing some really shady things. The CFO too. Where you're like, "Hey, let's go see the data center." The dude who runs the data center pulls up in a Bentley. You're like, "That's a little weird. I've never seen no DevOps guy pull up in Bentley before. Okay, let's go see the wreck."

It's like one cage, three or four server. You're like, "Where's the rest of this? Where's the money going?" It became one of those situations where every single day from a business perspective you're finding you're uncovering more bodies and more bodies. And you're like, "There can't be more." And there are more.

Trying to make sure that your team is encouraged and they're understanding what we're trying to do for the audience and the people that you're serving. A lot of that was really difficult times because you've got changeover of management, you've got changeover of your investors, you went from, "Hey, we're going to be doing amazing to, oh my God, this place is burning down around us."

We didn't even realize it. A lot of that was basically building trust. Building trust with the core product team and the engineering team. Making sure that they understood the mission that we're on, first and foremost of providing the best entertainment for the customers who are coming.

Then, secondarily just trust in one another that, "Hey, no matter what's happening we have the best interests of your own career." If people needed to move on, people needed to move on but we're doing it from a standpoint of like, "Hey, this is going to be way better for you."

That was a tough situation where I actually had to lay off my own friends. Where there are people you bring in and a year and a half, two years later you're like, "I'm sorry, we got to lay you off." Because we don't either have the money or whatnot.

But we did it in a really great way because we built that trust. I've worked with people who were like, "Oh, we're like a family." I'm like, "Never say that to me." We are a team, just like any kind of sports team. While we should be working well together, you can get traded. I may not be able to pay you your salary, you got to go someplace else.

But as long as you have that mutual respect and you treat people with respect, and you treat what you're doing together as a teamwork activity, then I feel those are the best outcomes. A lot of my friends who I had made and I had to let go I worked with, again two or three companies later.

Because we knew that when hits the fan that we still have respect for each other and that we're going to basically work this out in a way that makes the most sense for each individual as well as the company.

Again, thinking of it as a sports team. You have fans, you have people that you need to serve, but at the same time, we're not a family and because you can't fire family. At least that stands out as more of one of those crazier war stories.

Robert Hansen

I know some people family has been fired, but yeah. But a not similar story, but a war story that I've got which I think is kind of relevant to this is, when eBay was buying Skype.

I'm just looking at this thing, I'm like, "Why is eBay buying Skype?" I just don't get it at all. There's just no synergy there whatsoever. They brought me in and they're like, "Okay Robert, we're going to unveil our big idea that we've come up with.

I'm like, "Okay, what is it?" I'm excited. I'm one of the very first people who gets to see this big idea they've gotten. I'm like, "It's Skype Bay." And I'm like, "What? What's going to happen?" They can actually get their friends together and they can auction off their things to their friends."

I'm like, "But they can do that on eBay and way more people. Why are they going to want to be doing that to their friends? Who's going to do that anyway even if you do support that feature?"

They're looking at me like, "You don't think it's a good idea?" I'm like, "No, I know it's not a good idea. Wait, is that the whole idea." They're like, "Yeah, that's the whole idea." I'm like, "Oh, how much did you spend that?" “A billion dollar.”

So, if you don't have a product manager in the room who actually is thinking like the customer and actually is kind of called the threat model. What's the contrary viewpoint of this decision. What else could happen? You can make some really insane bets.

Eric Wu

I can't share this story.

Robert Hansen

You got a story you can't share. Can you change the details?

Eric Wu

I'm trying to think about it. Very similar, where company that worked, that got acquired. The acquiring company was like, "Hey, there's these great synergies that we can do together." We're like, "Yeah, there's definitely alignment." More alignment than Skype Bay for sure.

Robert Hansen

Sound zero.

Eric Wu

But their point of view was kind of, "Hey, you need to convert all your customers to be our branded customers." This is a natural thing where the company's like, "Hey, we want to be one brand." But the mental process was very much for what is the benefit to the company and not to the user.

Even like when you propose the idea of like, "Hey, I've got this billion dollar idea." Literally I'm like, "We can make you a billion dollars, but it'll be on a current user base that's the big company's branded user. We don't want it." "What do you mean you don't want the revenue?" "Well, we want customers who really committed to our brand."

I'm like, "We can move those people over. We can get the billion dollars and we can add value to the customers." They're just so hardheaded about the way that they think. They're not thinking about the end user. They're not thinking about the end benefit of the user.

Like in your Skype Bay kind of proposal. It's just like, "How do we just make more of what we currently do?" And they think of it from that lens. I don't fault companies like that. The acquiring company is very much like a SaaS-based company, whereas you're acquiring consumer-based company and they don't know how to thank consumer.

When all you've known is SaaS and you've all you've known is basically enterprise SaaS. It's really, really hard to change your mental model to think consumer.

Especially when the acquired company is much smaller, they're like, "Hey, this is how you think about consumer. This is how you should approach consumers."

I don't necessarily fault that, but it definitely one of those things where the product culture, if you don't have good product culture and you don't have good product thinking of first principles of really what we're trying to solve, then yeah, you're basically just going to continue to think like, "I've got to hammer everything is a nail."

Robert Hansen

All right. We've talked about a lot here. I'm always in a weird position when it comes to product because I don't trust the customer. Just like I don't trust engineers and I don't trust marketing people. I really don't trust anybody. I think trust is a generally a not a great idea.

You could maybe trust but verify. Generally speaking, I think that most people have bad ideas. The world is full of bad ideas. Maybe good intentions and maybe there's a nugget in there that's good.

But I generally try to avoid letting my brain get infected by other people's ideas whenever possible because there's so many of them, so many bad ideas.

Generally the worst place to get ideas, I find is from my own customers. I like them a lot, but they're just thinking about today, they're thinking about their problem right this second. I just keep thinking the Henry Ford, faster horses. "I just want a faster horse."

I'm like, "There's better ways to do this. Much better ways to do this." Not everybody is innovative. I don't think this is the right recipe for the average product manager, but I do think it's substantially better if you can think ahead of the customer instead of thinking where they are.

Skate where the puck is going, not where it is currently. Stop trying to listen to the customer's direct demands. Take them under advisement. Maybe it's a list of things that you're already working on and you want to know how to prioritize them. Fine, there's definitely room for that.

Certainly there's certain types of platforms where there isn't a lot of innovation. It's the same thing over and over again. There might be some innovation in how you structure the website, like you were saying, move pages around to make the flow different or whatever.

But anytime you ask a customer, they're not going to say, "What I really want is to move this page over here." They're never going to give you that advice. They're never going to think of it because they're thinking, "I just want to send more flowers to my sick grandmother."

How do you reconcile that? I mean, you've talked a lot about talking to customers and I too talk to customers. But how do you reconcile that?

Eric Wu

Two things come to mind. One is this idea of called predotyping. It's different from prototyping and it comes from this guy named Alberto Savoy. I think he used to work at Microsoft and he talks about the original PalmPilot.

Hardware is always been hard to build. Back then, even more so, extremely costly. The original idea of the PalmPilot, pre-iPhone, for anybody who's watching, like, "What the hell's a PalmPilot?" Basically, a digital calendar, effectively.

What prototyping does is they're like, "Let's pretend that this thing exists." What they would do is like, "Hey, here, customer, pretend that this is actually a working device, carry it with you." Basically, they would just like carve a piece of wood and carry it with you.

Whenever you feel like opening up your calendar or checking your calendar, pull it out and then interact with it. Give us feedback that way. So, there's certain things where you can kind of have customers pretend that it's real as opposed to listening to what their opinions are.

Then actually observing what they actually do because there's this idea in this book called Thinking Fast, Thinking Slow.

When you ask the customer a question, a lot of times it's the thinking slow. They've had a lot of time to think and then they've like, "What's the logical answer?" Even though, as we talked about earlier, most people are irrational.

They don't do what they actually say they do. If you can get something in front of them, without doing a whole lot of investment, you can kind of actually see what the user will actually do.

That's one approach or one strategy. In that book that he talks about, he talks about this idea of like, if you wanted to open up a bookstore, you would say like, "Oh, cool." You would go to a friend like, "Hey, I'm going to open a bookstore."

People will say, "That's a great idea. I buy books all the time." then when you actually open a bookstore, they never walk in. So, the alternative is basically, you put a sign on the street says like, "Hey, bookstore coming soon." You find an abandoned building, "Bookstores coming."

Soon as people walk by, you stop. I'm like, "Hey, did you see this bookstore's coming soon?" Like, "Oh yeah." You see whether or not people are actually truly interested or not.

Some of this falls further where stuff that I've done in the past where you basically can build some of these predototypes where for me, especially in e-commerce, it doesn't count. Your intent doesn't count unless you're willing to pull out a credit card.

So, we'll build like, kind of like a shell of a product. Say like, "Hey, you can get this product, it's only 9.99. Sign up now." When they go to check out, you don't hook up any of the Stripe or in the credit card. You just have an error messages like, "Oh, sorry, we're all sold out." Or "Hey, there's an error. Come back soon."

Robert Hansen

"We're actually out of stock but we added you to the list."

Eric Wu

You can actually collect whether or not that person's truly has that intent or not. A second way of doing, especially when you're doing all these customer interviews, we're actually talking to the customer.

Where product teams go wrong is, they ask kind of direct questions. Another book that I'm reading right now, which kind of resonates a lot, is from this lady named Teresa Torres. She has this idea of continuous discovery.

In it, there is this example of like, when you buy your suit jacket or when you buy a new suit, what's the thing that matters to you the most? People say fit or quality. Then if it's fit or quality, then why did you buy your suit off of Amazon? You didn't try it on ahead of time.

The behavior that they actually did versus what they say is different. A lot of times when you're asking questions, you want to ask things that are situational.

Instead of saying, "Hey, what do you care about in what you're purchasing? Tell me that last time you bought a suit." "Well I bought it on Amazon." "Oh, that's interesting. Why'd you choose to buy it on Amazon?"

Then you can kind of unfurl what they're truly doing. They won't know that they're revealing their true intents but because it's now situational and you have them recall the time that they did something, then that really gives you the actual context.

Then you can actually also ask them for kind of exceptions to that rule. "When was the last time you bought a suit but it didn't fit right. What did you do?" Then those are things that can pull out the true information so you know what to build.

Those kind of two type of tactics can really unveil a lot. Will it be 100%perfect of what you're doing? Of course not.

But it'll eliminate a lot of the kind of rabbit holes and tangents that you end up getting into just by one person's opinion over another and you end up spending time running an A/B test when you really don't need to resolve that opinion difference.

You can actually look at the core problem that's happening, and again go back to first principles of, what is the actual problem that we're solving now? Now we have a better solution. You're whittling down the potential solutions that you can have for the customer.

Robert Hansen

In product management, w you kind of have a work wife, work husband, which is your project manager. I am sure just like I have you've encountered all kinds because there really are all kinds.

What do you think makes a good or bad project manager? What have you seen that makes them easy to work with? Because that's your counterpart. That's who's going to have to take your idea and actually make it go and do all this heavy lifting of making sure engineering is off actually doing the work

Eric Wu

It's really honestly very simple. It's actually understanding the product. There's so many project managers that I've worked with that they're so intent on building their Gantt chart and their resourcing and all their spreadsheets being able to report and building the perfect reporting structure. That I'm like, "Do you actually understand what we're building? What are the tradeoffs?"

Because if they understand what you're actually building and the intent, then they'll understand and they'll be able to voice because like they're going to be in more meanings than you are.

They're going to be able to voice, "Hey, like, I don't think that's going to take us in the right direction." They may not necessarily be able to tell the team what direction they should go instead, but they at least can know like, "Hey, that doesn't fit."

They're basically the trip planner and they're like, "That's going off. Hey, it's okay if we skip this particular part of our trip because that's not necessarily core to the destination that we're getting to." It's really as simple as that.

The ones that are great at it, just truly ask those real questions of like, "How does this work?" That's where also I see product managers fail. Where they're like, "Oh my God, the project manager is asking me so many questions." Like, "Yeah."

Robert Hansen

Good.

Eric Wu

Exactly. You need to tell them.

Robert Hansen

I've found that there's two types of project managers. That's a good answer by the way. The first bucket is actually two groups of people. One is the super type A, shows up meeting with five cups of coffee in them. Everything's really buttoned up. Every second of every meeting is really written down.

You don't want to mess with them and no one wants to mess with them. If you are off by one millisecond by what time you said that thing's going to get done, they're going to be at your desk. Like, "Why isn't this done? You said it was going to get done." No one wants that to happen because this person's definitely about to snap.

It's great they get stuff done and they're very actually easy to work with strangely, despite all of that. The other is just sit back and relax and they've got their Gantt chart or whatever crazy thing that they're doing, but they don't follow it.

They don't care. Everyone's kind of doing their thing. No one wants to mess with that guy. He's probably high right now.

He's the cool guy in the room and everyone just kind of wants to let the cool guy do the cool guy thing. He is like, "Hey, so you said you're going to do it on Tuesday? Did I say that right?" "Yeah, Tuesday." Then everyone does it because they don't want to mess with that guy. It's great and it works perfect and stuff gets done.

The ones I find that are not effective are the ones who have agendas in their meeting invites. I don't know what it is. Every single time this happens. Every time I get a project manager with and they send out an agenda ahead of time, I know I'm just going to end up getting in conflicts with this person. Every time.

Not like sometimes, every single time. I think the reason is they assume that things aren't going to happen in the meeting. That every meeting is just following whatever needs to be done in that very specific agenda.

But in reality, just like life, things come up in the meeting. You're like, "Okay, whoa, we got to stop here. We need to take a way divergent path." I realize you want your thing to get done by the end of this meeting, but that ain't going to happen. We got like a bunch of really hard things to work through first.

They're trying to interrupt you, trying to get to the next part of the meeting. You're like, "No, no, no. This is the meeting. You can just leave if you need to because this is what's happening." I definitely get in conflict with those types of project managers.

Eric Wu

I definitely agree. I've experienced that a lot more recently where, "No, we got to address the issue. Why do you want to move on." "Well, we got to move on the agenda." Like, "Who cares about that agenda. Let's address the elephant in the room."

I also feel it's part of that other part where the person doesn't understand our product. They're just like, "Oh, okay, let's move on." I'm like, "No, this is core to the product. What are you doing?"

Robert Hansen

They understand their job. They just don't understand what we're doing and that's a big problem. Usually I get so frustrated with people like this.

I'm like, "Okay, we are all going to leave and have this meeting that needs to happen. You can sit here. I just need this to happen." "I need you to come with me. Well, should I come because I'm the project manager?" "No, no. I'll be fine."

Eric Wu

Some of the people I feel bad for because it is misaligned incentives for themselves. This is not true for every company. But honestly I've run it to almost every company that has a formal PMO. Where they have a group that's the PMO and the PMO does a lot more than they should be.

Where it's almost the Org is run by the PMO and not the product team or the engineering team. In those cases, the leaders in that are very much, "I need a Gantt chart."

Robert Hansen

I need metrics.

Eric Wu

Yeah. I need to know when things are launching on exactly what date and I need to have regular reporting every single money at this time. The executives honestly don't care.

If you actually go ask one of these executives, they're like, "Well, why would we do that?" They're just oblivious. The lead of the PMO is like, "No, no, we got to stay on the schedule." Everyone's like, "That's how you guys want to do the process." Where it's not helping. So, definitely been in that situation.

Robert Hansen

I've gamed PMOs heavily before because it turns out that they, again, as you said, they probably doing more than they should be doing oftentimes. But you can game them.

It's like, "Well, what are escalations? What happens to your organization when I put escalations on the board?" Well, they got this big Tetris board and it's all very frantic. They're like, "Well, we have this whole side channel for escalations." "Great, I'm going to fill that up."

I'm going to put everything through escalations because there's nothing stopping me. I mean, there's no one around me saying you can't. Great. Everything goes in escalations. I remember a business unit, they're like, "Robert, we're so sorry we sending you all these escalations. We can start giving them. "No, no, no." Every one of them has got to be P1.

So, I think the whole baking things in versus not baking things in. I think that's something I want to spend a little bit more time on since I have you here.

If you're going to tell these people that you're investing in, or whatever, here are the top 10 things I would do, or five things or three things or whatever from a marketing perspective to sort of bake it into the product.

As opposed to, "Well we have a product now, hire a team to come in and do the marketing components on top of it. Now add some keywords and metatags"

Are there things where you just like, "Here are the four or five sort of rote things like use WordPress with Yost on it." You got to do these low-hanging fruit, otherwise you're just not going to rank or you're not going to have a good marketing campaigns

Eric Wu

I think honestly it's very situational, but I think it's situational based on kind of the stage of the company and then what type of company they are. If it's something like e-commerce and if they're early stage, I'm like "Shopify all the way."

Even though from a marketing standpoint, not great, an SEO standpoint, not the best. But from a user delivery and logistics standpoint solves so many pain points and it's like whatever makes them go faster where they need to go faster.

Like seed stage, early stage, they haven't reached product market fit. When you haven't reached product market fit, you honestly don't need that much marketing. You need a little bit, you need to understand your kind of, your positioning and your messaging, but you don't need to spin up tons of marketing.

You just need to be able to experiment and understand what marketing will do when you get to scale or when you need to start scaling. But if you haven't reached product market fit, all those marketing things that you would do are going to exacerbate the things that are painful right now that you haven't figured out.

I mean, having been in technology for so long now. It doesn't matter. Everyone says we're going to build this so that it's going to last for like five or six years. That this is kind to like the platform that we're always going to use and let's invest in it.

That is complete bullshit. Everyone wants to re-platform every single year. New fancy technology comes out. Engineers are always like, "That's super cool. I want to work on that. Because also it builds their resume." It gives them job mobility.

I've come to the point where like, it really doesn't matter what platform you're picking. Most of the time it's like, "Pick the right tool for the job at the moment."

Robert Hansen

Okay. Well, a follow up question is, so let's say you are about to make an investment as I know you do some investing and you're taking a look at a company.

Is there something about product management your marketing background that would make you say that's going to be a good fit or that's going to have a lot of problems? How does it sort of inform your investing strategy when you're taking a look at these companies?

Eric Wu

Yeah. Especially for myself, I'm doing more angel investments. They're really early stage companies. I rarely get a chance to work at or invest in a company that is later stage.

In those cases, it really comes down to those founders and whether or not they think in first principles. Do they know actually how to solve the problem and actually figure out the customer. Can they think in marketing terms? Can they bring the product to market?

Robert Hansen

It's the people. It's not the tech.

Eric Wu

It's 100% the people. I think there's a part of it is the tech. One of the companies I've consulted with is Goat. They have this really cool marketplace that sells high end sneakers. They didn't start that way. I even forgot what they started as. It had nothing to do with sneakers.

Robert Hansen

It was goats.

Eric Wu

They got to a point in their company's career where they were just like, "Shoot." They went to their investors and were like, "We want to give you the rest of the money that we have back because we know that this is a dead end project."

Investors went to them and said, "Look, we don't want to need the money back. Go do what you think the thing that you're most interested in." They're like, "Well, we really like sneakers."

They built a marketplace on sneakers. The thing is they're smart people, first and foremost. They understood what they really, truly liked. That's the thing that I'm looking for too is like, are you a founder or are you a company that is doing the thing that you think that will help you raise money? Or do you truly, honestly believe and like the thing that you're working with?

That's where like I'll help certain companies versus others. Even though like Honey, I looked at the company and I was like, "It's a fucking Chrome extension. This thing's not going to be big at all. It'll make some money, but it's a Chrome extension. This is not going to be a billion dollar company."

They sell for $4 billion. They're $4 billion company. It was because when you looked at the founders, they truly believed in the mission that they were doing.

The story of George was that he grew up poor and he had this thought of, "Hey, it sucks. My mom's sitting there cutting coupons. Why is it that we have to cut coupons because we're poor? That's unfair."

The funny thing is they call them coupon king when he sold the company. But his whole goal was to eliminate coupons all together. He doesn't want a single coupon to exist. If you think forward to where he was thinking way back.

Then, he's like, "Look, if the Chrome extension is installed in everybody's computer or 80% of the computers and it's auto applying coupons for everybody, the whole idea of coupons completely is negated."

Coupons are designed for attribution, incentivizing certain segments to get them to complete the conversion and then collect data. If everyone's the same, I'm just discounting all my products all the time. There's no value.

Especially the technology we have is like, we're brute forcing every single coupon that we've ever seen. The user doesn't even know what coupon we're using, we're just maximizing the savings for them. It's that thought process, that foresight that he had of like, "Look, I'm really passionate about this space."

He had that vision of where it could be as opposed to, “How do I make a billion dollar business?” Or "How do I be in the next Mark Zuckerberg?" I find a lot of founders that way. They're in it for this false celebrityhood as opposed to truly what problem are you solving for the customer.

Robert Hansen

So, I hate to tell you, but you're back in couponing. That's how where I first met you. You were doing a lot of couponing stuff. Realtor had a couponing. I can't even remember the name of it.

Eric Wu

Welcome Wagon.

Eric Wu

Yeah. I think Welcome Wagon. How is that different? I mean there's two products, 15 years apart both giving out coupons. Why did one turn into a billion dollar company? We can't even remember the name of it anymore.

Eric Wu

It was very much welcome Wagon, was this idea of how do we use this for attribution? How do we use this to generate leads? It was the wrong way of thinking coupons. Where when you think about what Honey does, it's thinking about the user first. Whereas welcome wagon's thinking about the business.

How do I generate a lead for the business? How do I sell this to a merchant? How do I sell this? How do I get merchants to fund this? Where Honey was just like, "Customers want to save money and they don't want to search the internet for coupons, so we're going to give them all the coupons."

It's that fundamental shift of what's best for the customer as opposed to what's best for the business and they're able to build a much bigger business because you've put the customer first.

Robert Hansen

That's cool. All right. Well, thank you for doing this. I know it's kind of too a little late at night here in this hotel here in the beautiful California, Southern California here. I appreciate you coming down. How do people get a hold of you, find out more, get in touch with you, ask you for help for their companies?

Eric Wu

The best way is usually Twitter. My handle is @eywu, and then of course on LinkedIn. Those are usually the two places that I hang out at least socially.

If there are times where people want to just kind of bad ideas around either product or growth, I'm always game. Especially for startup founders who are struggling because there's a lot of bad information out there.

Robert Hansen

Sure is.

Eric Wu

You know it in the scariest space, I know it in the SEO space, right?

Robert Hansen

It's quite similar.

Eric Wu

Really in the end, I would say like in my stage of my career now, it's the kind of the famous Jack Ma thing of like, "Hey, early on you kind of grow your career."

Second part of your career is kind of maximizing what your knowledge is and then there's a latter part of your career where you're giving back and sharing that knowledge.

Starting that earlier, and I've been doing that over the past decade. Those are things that really end up not only selfishly like having a good benefit of where I feel good, but it's opened up our opportunities for me to also make money and help other people make money just like Honey.

If anyone's out there who needs help, I'm always willing to geek out on product and growth stuff.

Robert Hansen

Love it. Well, thanks again for doing this. Really appreciate it, and good seeing you again.

Eric Wu

Same.