131–140 of 221 posts
> 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…
Earlier quoted context omitted.
Lots of product managers have never studied product development. You'll find philosophers, designers, physicists, even musicians in the role. Many have great people skills, but little understanding of customer service, building products, or scaling a business. And funnily enough, those are all real careers and degrees. The result, which you often see in companies with 300+ employees, is that engineers have far more e…
>> Many have great people skills, but little understanding of customer service, building products, or scaling a business. And funnily enough, those are all real careers and degrees. Where would people skills rank then in your hierarchy for product managers?
Earlier quoted context omitted.
Ultimately, you need to decide who your target user is. Do you want to cater to the lowest common denominator, or do you want to want to make something power users can customize to fit their workflow? Neither answer is necessarily wrong, you just need to make a choice.
> you just need to make a choice. This fallacy is at the heart of the failure of modern software. Making things work for the median user is almost entirely about defaults and intuitiveness. If everybody is sending messages all the time, there should be a conspicuous button for sending messages. Making things work for power users is about allowing those defaults to be changed. It's fine if this is five deep in a menu…
I love this.
Building on this thought: When you are starting to build something, you have very limited resources. Focus only on making simple things easy and forget everything else. Once you have product market fit expand into making complex things possible. This applies to 90% of all products.
They often are having to integrate the company's software with the whole stack of the customer.
They experience the pain of real world setup/optimization/bugs more than anyone else in the company.
They generally are savvy to the challenges of actual software engineering and what is realistic to get done in a given time frame.
They are usually technically articulate enough to frame the challenges in an understandable way for SDEs.
They are driven to improve the customer experience because it also makes their lives better, vs the sales guy looking for ways to just close a sale for commission.
They are very aware of what the competition is coming into bake offs with as far as features and support.
They can let you know what bugs and missing features are costing the company the most money and customer sat.
> The rewrite took 2 weeks. We removed 60% of features. Added a simple progress bar. Built Slack integration for questions. Created "done-for-you" workflows. > Our support tickets dropped 70%. If this isn't fake something is extremely wrong with this picture.
Reddit has become an outlet for creative writing. This might have been inspired by some real life events, or it might have been pure fiction. Either way the end result is dripping with the typical Reddit creative writing elements, with a dash of LinkedIn style business storytelling.
They say they have a certain job, work for a certain company, or know how to do a certain task; and they get the terminology completely wrong, or make up stuff that is obvious to someone who actually knows, but sounds good to people who don't know.
Karma is a hell of a drug.
Earlier quoted context omitted.
I run a small tech startup, about 2M ARR. And at times we’ve been short staffed on support and I’ve sat in for support for a day or two. And every time I do this I discover loads of issues customers are complaining about that don’t seem to ever make it back to our engineering team. Perhaps it’s just our support reps, or the nature of support, but they seem to love to “solve” problems themselves rather than reporting…
speaking as someone who clawed their way up out of the support mud... sometimes it's a lack of accessible escalation procedure (no, a bug report is not the same thing as "this feature sucks to use and needs to be revisited), and sometimes it's just the unfortunate fact that those support reps most capable of clearly explaining these issues (or better yet, understanding the underlying mechanisms that cause the issues)…
The way I've typically solved this is by keeping an eye on the support inbox myself. It takes just a few minutes every day and I've caught some pretty low-hanging fruit with this that really does make the product better. Sometimes it's as simple as just adding a permalink somewhere.
> 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…
I run a small tech startup, about 2M ARR. And at times we’ve been short staffed on support and I’ve sat in for support for a day or two. And every time I do this I discover loads of issues customers are complaining about that don’t seem to ever make it back to our engineering team. Perhaps it’s just our support reps, or the nature of support, but they seem to love to “solve” problems themselves rather than reporting…
Person1: "thing doesn't work?"
Person2: "yeah it doesn't work for me either"
Person3: "it's always something I have to work around"
Person4: "I work for as a customer support outreach social media community engagement executive. Can you go and jump through hoops and open a support case?"
Not raising it internally, not getting anything changed or fixed; suggesting the customer do more work to tell the company about the problem. A person who works for the company and is paid to read social media and has read the complaints, is not only apparently ignoring them but annoying the customers as well.
Alternate Person4: " I work for as a technical employee and we've been begging to get this fixed for years. As a workaround you can . Email me directly if you need more help, and if we get a patch to fix ever, I'll let you know".
Earlier quoted context omitted.
Most engineers turn up at meetings with product managers with two major problems: 1. They assume they know more than everyone else. Got a guy who has had a problem for 5 years and tried 20 different solutions? The engineers will spend 10 minutes thinking about it, come up with a solution (that won't work, but they insist it will) and dismiss the problem as "trivial", and think the guy is an idiot. I've done it myself…
> I can not understate how hard it is to get engineers to read a scope document, ... Ironically, it is hard because it doesn't consider the user. Scope documents likely seem reasonable for the author living in their own little bubble, dismissing it as something "trivial", but if they actually had to use it like those on the receiving end they would soon realize how horrid and ill-conceived it is. Much like was learne…
Doesn’t matter if you drive VS Code every day though, because that means You Know Better (tm), and to hell with the discovery process.
I actually wouldn’t have a problem with pulling engineers into those discovery exercises directly, except when I have, they’ve just refused to engage. Come out without asking many questions and seemingly haven’t listened to a thing.
It’s like engineers just think it’s all beneath them, (and I accept I was a bit like that when I was engineering), so forcing them to do the calls isn’t an awful idea.
Earlier quoted context omitted.
There are two separate problems, and they aren't mutually exclusive, but this post seems to be specifically about the latter case (if one believes the story, of course): - The PM(s) are bad at listening to customers or turning customer feedback into a focused set of requirements. - The engineer(s) are bad at following the requirements or going back to the PM(s) when the requirements aren't clear. In the first the PM(…
Lots of product managers have never studied product development. You'll find philosophers, designers, physicists, even musicians in the role. Many have great people skills, but little understanding of customer service, building products, or scaling a business. And funnily enough, those are all real careers and degrees. The result, which you often see in companies with 300+ employees, is that engineers have far more e…