Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I forced every engineer to take sales calls and they rewrote our platform

old.reddit.com

Post reply on HN
Print view View original

201–210 of 221 posts

Re: I forced every engineer to take sales calls and they rewrote our platform

#201

Post by pyman »

jbmsf wrote: post #186
ivan_gammel wrote: post #140

Earlier quoted context omitted.

I support every single word of this comment. Good product managers are unicorn masters of discovery and delivery who are so rare that they climb up quickly in corporate hierarchy to strategic positions leaving holes in product operations. I have seen products running A/B tests without understanding how they work, designing UI sketches without any knowledge of UX, pushing features to roadmap based on a feedback of a s…

I have worked with so so many ineffective product managers. The good ones are indeed unicorns. Even when you have good ones, they can't scale up to all of the things that I'd want them to own, meaning that engineering fills a lot of gaps. This ends up being uncomfortable and necessary. I'm still learning how to make it work.

The best PMs are like mini-CEOs, and many of them go on to become CPOs. But there's a lot of confusion in the software industry about what the role of a PM should be. For example, I see companies putting too much emphasis on usage metrics, while very few focus on the far more important skill of asking the right questions. PMs look at dashboards to make informed decisions, but most of them aren't even asking the right questions. And they don't know if the questions they're asking are the right ones, because they have no real knowledge of product development, just a bit of experience which is limiting. That's what happens when engineers, designers, or musicians end up in PM roles, reacting to data or using it to validate their own or someone else's assumptions.

The real problem, I believe, starts with companies hiring anyone with people skills as a PM. They don't understand their role and responsibilities, it's common to hear PM say "I own the product." But that's not really true. According to successful founders and CEOs, they are the only ones who truly own the product, and that's an important point for leadership to establish. PMs thinking they own the product creates power struggles with leadership, engineering and design, while a title like "Customer Experience Manager" makes it clear the role is about representing the customer's needs, aligning them with the CEO's vision, and making the right trade-offs.

Business people with knowledge and experience always put the customer at the centre and focus on aligning customer value with business value. In other words, if you're the CEO of Uber and your PM isn't driving a taxi once a week, then, IMO, you hired the wrong person.

Re: I forced every engineer to take sales calls and they rewrote our platform

#202

Post by throw310822 »

dcastonguay wrote: post #5

> At the end of it, they were sketching a completely different architecture without my "PMing". Because they finally understood who was actually using our product. I cannot help but read this whole experience as: “We forced an engineer to take sales calls and we found out that the issue was that our PMs are doing a terrible job communicating between customer and engineering, and our DevOps engineer is more capable/ac…

> the issue was that our PMs are doing a terrible job communicating between customer and engineering

That makes it look like it's the PMs' fault. Yet I bet you wouldn't want a car designed by engineers who never drove one and never directly spoke with someone who did, either. It's that simple.

Re: I forced every engineer to take sales calls and they rewrote our platform

#203

Post by klingon33 »

general1726 wrote: post #52
dcastonguay wrote: post #5

> At the end of it, they were sketching a completely different architecture without my "PMing". Because they finally understood who was actually using our product. I cannot help but read this whole experience as: “We forced an engineer to take sales calls and we found out that the issue was that our PMs are doing a terrible job communicating between customer and engineering, and our DevOps engineer is more capable/ac…

Or engineers are little bit full of themselves and know better how user should experience the product. If user is "holding the product wrong" it is a problem of a user and not a problem of stupid design, created by a person who knows in which order these buttons should be pressed. People around Desktop Linux could write a complete book about dismissing user's complaints. The moment you have stubborn engineer who know…

This story of whittling down the product to meet the needs of the user as grepped from several sales calls assumes that a small sample is statistically representative (and it’s not) and assumes simplification always makes for a better product (and it doesn’t).

When I ask 15 users for their input, only 3 will speak up, and their needs and views don’t fully overlap.

Photoshop is a great example of a product that was extremely complicated and difficult to use but dominated the market for many years.

Microsoft has continually made updates to its products over the years, making it basically do the same thing but with unnecessary and frustrating changes, and people keep buying it.

Yes, UX is important, and A/B or similar evolutionary testing is important. Yes, devs tend to overcomplicate things. But, there’s no magic simplification bullet.

Re: I forced every engineer to take sales calls and they rewrote our platform

#205

Post by selbyk »

boticello wrote: post #199
Nadya wrote: post #119

Earlier quoted context omitted.

If a user holds an ice cream cone upside-down and their ice cream falls to the floor, do you blame the user for not holding their ice cream cone upright or the creator of the ice cream cone for a stupid design that allows the ice cream to so easily fall out of the ice cream holding device and onto the floor? I find far more often that bad UX is the result of someone trying to use a tool for something it wasn't design…

And thus the tub was conceived. By someone who was watching people wrangling with cones.

Unfortunately tho, it also suffers the same huge design flaw: hold it upside down, ice cream hits floor. =(

Re: I forced every engineer to take sales calls and they rewrote our platform

#206

Post by fuzzy_biscuit »

selbyk wrote: post #205
boticello wrote: post #199

Earlier quoted context omitted.

And thus the tub was conceived. By someone who was watching people wrangling with cones.

Unfortunately tho, it also suffers the same huge design flaw: hold it upside down, ice cream hits floor. =(

And thus, the milkshake was born. And it was good.

Re: I forced every engineer to take sales calls and they rewrote our platform

#207

Post by sfn42 »

lmm wrote: post #196
yen223 wrote: post #182

Earlier quoted context omitted.

The first rule of Hacker News comments is it's never the engineer's fault

It can be the engineer's fault if it's an engineering mistake. But bad process is the fault of the people who control the process and bad product management is the fault of the people who control the product management.

As a developer I work closely with my managers and designers etc to ensure that our project goes smoothly and that we create a good product. I don't necessarily decide what we build but I have a lot of ways to influence what we build and how.

We talk about stuff, we plan stuff, I chip in and people listen. Whenever I see devs complaining about how terrible their project management is I think to myself that the dev is probably at least partially responsible.

Maybe I'm just lucky to have good colleagues, but when I talk about software engineering topics people listen and take it seriously. I think that's a big part of our job as developers, we know the tech and we guide our managers just as they guide us. We're a team, we work together.

Re: I forced every engineer to take sales calls and they rewrote our platform

#208

Post by anbotero »

general1726 wrote: post #52
dcastonguay wrote: post #5

> At the end of it, they were sketching a completely different architecture without my "PMing". Because they finally understood who was actually using our product. I cannot help but read this whole experience as: “We forced an engineer to take sales calls and we found out that the issue was that our PMs are doing a terrible job communicating between customer and engineering, and our DevOps engineer is more capable/ac…

Or engineers are little bit full of themselves and know better how user should experience the product. If user is "holding the product wrong" it is a problem of a user and not a problem of stupid design, created by a person who knows in which order these buttons should be pressed. People around Desktop Linux could write a complete book about dismissing user's complaints. The moment you have stubborn engineer who know…

While PMs have their own share of quirks to work around with and your comment doesn't say they have no faults at all, I wholeheartedly agree with you here. I've worked as a developer, QA, systems operator, and a bunch of other positions. Holy cow, we are all full of ourselves (PMs included), but the disdain of a lot of developers towards the end user (sometimes PMs fault) is incredible. A bunch of nerds ignoring common people use cases and abilities. And it keeps happening and most still don't recognize what's happening.

I've worked as a Manager so I've had to deal (and collaborate) with this kind of misunderstanding, but it truly gets tiring when developers complain about users trying dumb things (for developers) over and over again, yet they themselves have learned nothing from previous encounters with this phenomenon and complain instead about stupid users (or PM, or company, or whatever).

Re: I forced every engineer to take sales calls and they rewrote our platform

#209

Post by ccakes »

general1726 wrote: post #52
dcastonguay wrote: post #5

> At the end of it, they were sketching a completely different architecture without my "PMing". Because they finally understood who was actually using our product. I cannot help but read this whole experience as: “We forced an engineer to take sales calls and we found out that the issue was that our PMs are doing a terrible job communicating between customer and engineering, and our DevOps engineer is more capable/ac…

Or engineers are little bit full of themselves and know better how user should experience the product. If user is "holding the product wrong" it is a problem of a user and not a problem of stupid design, created by a person who knows in which order these buttons should be pressed. People around Desktop Linux could write a complete book about dismissing user's complaints. The moment you have stubborn engineer who know…

I kind of think this is correct but not for the reason you think. To most engineers, users are the annoying thing on the other end of a ticket. They “don’t know how to use the product properly”.

I’ve also had great success dropping engineers directly in front of customers. I think it’s just because it humanizes the person behind the ticket

Re: I forced every engineer to take sales calls and they rewrote our platform

#210

Post by godelski »

ccakes wrote: post #209
general1726 wrote: post #52

Earlier quoted context omitted.

Or engineers are little bit full of themselves and know better how user should experience the product. If user is "holding the product wrong" it is a problem of a user and not a problem of stupid design, created by a person who knows in which order these buttons should be pressed. People around Desktop Linux could write a complete book about dismissing user's complaints. The moment you have stubborn engineer who know…

I kind of think this is correct but not for the reason you think. To most engineers, users are the annoying thing on the other end of a ticket. They “don’t know how to use the product properly”. I’ve also had great success dropping engineers directly in front of customers. I think it’s just because it humanizes the person behind the ticket

I think you're right. Similar to the article's title, a useful thing is dogfooding. But where this can go wrong is because conversation is engineer to engineer (not exclusively) is that the takeaway can be "Oh, I was holding it wrong" instead of "this was not as intuitive as I thought, how can I fix that?" I know there's backend vs frontend arguments[0] but I think backend needs to be conscious about front end. When we write backend it is easy to just focus on making things work but we're a few steps back from typical (or targeted) use cases.

Classic problem with us eningeering types, right? When you're in the weeds it is easy to see the differences. Humans are always biased to forget how difficult it was to learn something, judging on level of current (subjective) difficulty. For me a big change in framing came through Linux. I'd convince my friends to use it and then as the years went by I saw how much easier it became to do so. Now, for the most part it is much easier for an average person to use. There difference isn't "holding it wrong" so much as "it's hard to hold" (or "it's hard/unintuitive to hold correctly"). Even just with the more recent rise of TUIs. Even us terminally terminal types are loving the new TUIs and ultimately that is a frontend thing. It's just frontend for backenders, allowing us to stay in the environments we are efficient in, maintain our power and flexibility, but also get some aesthetics (which has functional utility! I bet you use syntax highlighting, and not just because it is pretty).

There's a strategy to writing backends that I think helps both backend and frontend: write flexible code. It draws from the unix philosophy, where functions (or small programs) should be containerized or focused. Then the complexity happens by putting the things together (there's a hierarchy to this). Helps write backend code so it is easier to maintain, reduces repetition, allows for quicker feature development, and ultimately makes it far easier to read. It's a little more work up front, but it sure pays dividends. It helps front end people because ultimately they are towards the... *front end* of that hierarchy. Makes it easier for them to pull pieces together, wrap things, and communicate with backend types.

Honestly, I think the biggest roadblock to this strategy is the constant push for rushing. Why is there always time to do things twice but never enough time to do things right? It all depends if we're running a sprint or a marathon. A sprint is all about speed, but a marathon requires a lot of strategizing. A marathon requires some sprinting, but you can't sprint the entire thing. We like to drop sayings like "don't let perfection be the enemy of good" but truth is it's not about perfection, it is about different ideas of what is "good enough." Which, is ultimately an issue of communication.

[0] I'll still argue backend is more important ;) because that's the foundation. Your building can't stand, let alone be pretty, if it doesn't have a solid foundation and skeleton. All that is invisible though. Maybe that's why these arguments occur.

Post reply on HN