Hacker News Reader

Agreed. There's nothing like being in the field with real users.

Ideally, you don't just talk to them. You watch them work. Observe, and gather clues about what will serve their needs. And when people tell you what they think they want, don't assume that's the product spec; treat that also as an opportunity to listen to clues that will help you understand their needs.

The best products are designed around how people work, not necessarily what people say about how they work.

> The best products are designed around how people work, not necessarily what people say about how they work.

This reflects a lot my experience: People actions >>>> People words.

i’m an in-house recruiter and discovered steve banks’ advice on my own. why would i be in an office where everyone who i might hire is outside of that building?

while there are problems with that assertion, hiring is largely serendipity. as an extrovert, serendipity for me is found while out and about.

On a related note, it's really important to hire a solid PM and keep them on for the life of the product, or at the very least through major releases. I worked on a product where the PM got changed several times and it caused total havoc and pretty much killed the project dead as basically each new PM thought the previous direction was wrong.

Agreed. But would add: as a developer my least favourite thing has been Product Managers who keep the customers exclusively to themselves. Requirements inevitably have a technical component to them, and getting the end users and developers together in a room and talking to each other directly is invaluable. It's so important that it's actually a key requirement to taking a job for me.

Very true! Aside from all other benefits, bringing the Dev team to meet customers is highly motivating to everyone, including the customer

I have alternatively heard this distinguished as:

- UX Product Managers (close to users)

- Technical Product Managers (close to developers)

I've written about this a little bit here for the curious: https://alexpetralia.com/posts/2019/10/14/product-management...

> Technical Product Managers (close to developers)

In my humble experience, I think the real value of a TPM is being the interface between management and technology. They're able to frame technical jargon in a way that the business can understand. i.e. Why we have to do this refactor? If we don't it will cost the company money. (contrive but you get the point)

"Getting out of the building" in metmorphical send might give you view from people / customers you can visit. This is likely to be a biased sample, and unrepresentative of the true customer.

Running A/B tests is IMO, a good proxy, to understand customers unbiased binary views on feature changes, and objectively better.

Talking to users lets you know what the problems are.

A/B tests let you know if you've solved the problem.

True!

A/B tests work only for features you've built. You don't get insight into what customers say they want, you only can observe if they like what you built or not.

There is a use case for both.

I agree but how do you keep abreast of this best practice in times of COVID? Product Analytics might just be the life saver.

Product analytics may tell you what is happening, but they won't tell you why it's happening. To your question, I don't really have a good answer. From a B2B SaaS perspective, we try to complement analytics with a lot of video calls but that's not nearly as good as sitting next to people while they do the work.

Definitely not a replacement for watching people do their work but we've been using Cohere (https://cohere.so) to help us watch what our users are doing and how they're working.

It tells you what is happening that is easy enough to track and measure. Most empiricism in the business world is poser empiricism, people want to say they are "data-driven" because that is virtuous in our current culture but when push comes to shove no one wants to invest the time to do it properly.

Zoom, teams, etc. You can still talk to customers, and they can still show you what they are doing, and what they might need.

> the key thing a product manager has to do is get out of the building.

Well, no, that's the sales job. First being a product manager is different in every company. And second there is a lot of differences depending of the type of business you are working in.

For example if you work in Saas b2b enterprise you can easily be a very good product manager and almost never meet the customers nor the users [1], because that's not what is important for the business.

On the contrary if you work in Saas b2c, talking (or doing surveys) to customers is crucial. So I would say that your advice apply well to B2C, in which there is no sales people

[1] https://blog.luap.info/product-management-in-saas-b2b-enterp...

No, sales goes to the customer when you have a product to sell. The product manager need to go to the customer to understand what they need, and what product needs to be created.

I would say 1 salesperson in 20 has the ability, interest and influence to alter a product roadmap. The other 19 exist because of their competitive drive and ability to bang their head against a wall without losing enthusiasm.

In my experience 100% of salespeople will try to influence the product roadmap if it means they can sign a new deal

Yes. “What can I promise on the roadmap to close this deal?” is very different than “What is best for the roadmap?”

You can’t trust a salesperson to think about the broader good when half their comp is tied to specific deals.

Usually any impact a salesperson has over the product roadmap is too slow to have any impact on the sales opportunity.

Salespeople usually have more influence on the customers than on the roadmap, so they're better of trying to influence the decision making of the customer, than the product.

Salespeople focus on their sales targets, trying to change a product roadmap is not a very effective way to reach short term targets.

Obviously, a product manager should reach out to sales to try and understand their perspective on the product and the customer needs.

Depends on the company. I worked for a small company that was a real clown show. Sales would come down to the engineering area and say things like "I just closed a huuuuuuge sale for the company. We need a product that does A, B, and C, now so we can deliver it!" And, that became engineering's scope for the next 4 weeks...

I’ve been at similar though 4 weeks would have been generous.

It would be 4 weeks because Sales told the customer that A, B, and C were already part of the product.

Yes small companies commonly works like this. Basically, they hustle sales and the development team needs to cover for them.

Hey, I also worked at this company! (and left after 6 months)

If your product is B2B enterprise then your end users' delight at your UX might not matter very much, but you definitely want to understand the decision makers' interest in getting additional reporting/auditing tools and how much value [if any] they get from their staff being more accurate in using the tool...

The issue is most of the time the decision maker has no clue about that. In B2B enterprise the product is not a big part of the decision to buy or not.

The decision maker is usually someone in the C-suite or a little below it who cares very much about whether the system gives them the reports they asked for, whether it ticks all the boxes on the operations plan someone drew up for them, whether middle management are frequently complaining about errors, how much resource is needed to switch from service Y etc.

That's a different product focus from the end user (who probably finds the new operations checkboxes demanded by the decision maker a horrible pain) and instead of actually using it, their perception will be shaped by middle management feedback and some claims made by the enterprise salesperson about how much money their business can save from staff being able to complete X faster or Y being shared, but it very much is a product based decision. Otherwise the lowest bidder (or at least the lowest bidder with an SLA) or incumbent would win every time.

This is an outdated stereotype about enterprise buyers.