10 ms·

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

324 points by bilsbie 1y ago

semitones 1y ago
This is an excellent strategy for smaller startups, where every individual contributor needs to have an understanding of the customer's needs, in order to develop an understanding of what kind of product must be built. I have much more success in projects where I deeply understand the product requirements (because I am involved in defining them), than those where the product requirements are "handed" to me and I just have to implement something that satisfies them.
- ranger_danger 1y ago
  Are you saying that you follow directions better because you wrote them... or that you are just ending up with a better UX because of your involvement?
  - dghlsakjg 1y ago
    Human communication is incredibly lossy (sometimes intentionally), plus humans will try to fill in gaps with assumed information. The more people you cut out between the message sender and the receiver, the more likely the message is to still be intact. The kindergarten game of telephone is the perfect demonstration. You only end up with distorted messages if you have many players between the sender and the receiver. If you play telephone with 2 people, you end up with a boring game where any mistakes in communication are immediately resolved.
    - davorak 1y ago
      The telephone game is the analogy I use too when explaining the value of having engineers in the custom calls. Other than mistakes in communication, engineers often know what the hard trade offs are when designing a new feature while sales and PMs do not. They can ask the questions to find out if a customer is on one side of a trade off or the other. Or if a feature is 10x as expensive to implement because the customer needs/wants the benefits on both sides. Finding that out at the start can save a full development cycle of time/effort at times.
      - dghlsakjg 1y ago
        > engineers often know what the hard trade offs are when designing a new feature while sales and PMs do not. I frequently run into the issue of PMs spending more time discussing and trying to slot a feature into the roadmap than it would take to just implement it. Most recently it was with trying to scope out how long it would take to ingest encrypted files. I wrote the feature and had a pull request up before the end of the meeting where they were trying to figure out if we could implement it this quarter or next. The inverse is when a feature is assumed to be technically easy to implement (just change that setting), and you have to gently explain why that will take a week. Having people who are technically competent in the meeting often allows a short circuit to getting tot the solution along a pathway that a PM didn't know esited ro was possible through no fault of their own.
richwater 1y ago
All this says to me is that they have no technical product/program management in place to actually do what is described.
dcastonguay 1y ago
> 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/actionable at turning customer needs into working solutions.”
- hughredline 1y ago
  > DevOps engineer is more capable/actionable at turning customer needs into working solutions That’s been my experience all my tears in industry.
  - neogodless 1y ago
    I, too, have had many, many tears in this industry.
    - hughredline 1y ago
      ;P An errant autocorrect a little too correct to correct.
- HPsquared 1y ago
  Many such cases of employees adding negative value.
- sc68cal 1y ago
  -10x employees DO exist!
- barbazoo 1y ago
  Agree, also the whole thing reads kinda fake in the first place.
- vkou 1y ago
  This is the first thing that struck me. Why does the OP still have a job if a line engineer can do it better? Promote the guy to CTO, and fire the useless chumps who were collecting a paycheck spinning their wheels.
theshrike79 1y ago
Dogfooding works
- pavel_lishin 1y ago
  I don't think this is an example of that. This is just engineers being able to talk directly to customers, which is great in most cases. I absolutely loved my jobs where I could directly talk to the users of our products, especially when they came to me with bugs or problems. Unfortunately, that's not always possible. I wonder if that's why I always liked building tools for "internal" clients, other users within the org - it was trivial to just Slack someone or ask if I could walk over to their desk.
- GuinansEyebrows 1y ago
  difficult to do unless you're building tooling/personal productivity stuff. i don't know how a company would dogfood a point-of-sale platform, for example.
  - theshrike79 1y ago
    Like this. =) Force the people making it to use it for a while. Even just a day.
    - GuinansEyebrows 1y ago
      fair!
ranger_danger 1y ago
Thankfully the comments agree that OP was the problem all along.
justtinker 1y ago
Out come the "this is dumb because .." messages in the redit responses. I have experiences dozens of projects where the developer had the wrong view of the end use needs for a myriad of reasons (everything after the because). It doesn't matter why in this case just that they found their solution. The TL;DR message should be make sure the real needs get serviced.
pseudocomposer 1y ago
At my company, as developers, we rotate taking support tickets and working directly with customers on the issues our (very capable) support team can’t handle. We and our customers are both very happy with the results.
- snarf21 1y ago
  Yeah, this drives value for almost all roles. No need for a separate focus group when you can ask the people who are already using and/or paying for your product.
- nunez 1y ago
  What you're describing is customer success, which is almost always post-sales. Engineers working with customers post-sales is a great idea. *Pre*-sales is where it gets tricky.
m463 1y ago
All the negative responses. I have been at countless places where the engineers are out of sync with the product. And it might be something silly like their coworker added something they didn't know about and the UI is now confusing. Could even be the website started proclaiming something that didn't align well with the product. Another factor is that the [product -> PM -> bug system -> engineer -> fix -> QA -> product] loop is heavy. It takes a long time and major things get fixed but minor friction doesn't. having [product <-> engineer] can be amazing. Engineers might have never encountered the full experience, or may merely be out of sync with how it works today vs last year.
- PaulKeeble 1y ago
  There are myriad of ways to get this wrong and I have seen them all happen: - force all the communications with the users through Project Managers or Product Owners. Sometimes they are great and sometimes they are terrible. - The customers refuse to talk to the developers and so they are forced to interpret the users managers requirements without any further input. - The developers just want to write code and refuse to meet the customer forcing all communication through their product manager or bug tracker. - I have seen a couple of times where commercial software platforms were used the technology can get in the way, they are limited in the types of modifications and customisations that can be applied and this can make some workflows really awful. There is always a disconnect somewhere, someone blocking a conversation happening and it can be the customer, a middle man or the developers causing it, often its all three to get a really dysfunctional system or the solution has been chosen before any developers or users really got into the details and its the wrong choice. There are a lot of ways to make systems that aren't very good for the users.
- nunez 1y ago
  you're not wrong, but i don't think forcing engineers to take sales calls is the right move either. there's lots of soft skills involved in running a successful call that engineers aren't trained or even interviewed on. (i'm definining "sales calls" as the initial discovery call before a demo or proof of concept is agreed upon. i would be okay with having engineers _ride along_ for complex presales demos, but even then, product should really be serving that role.)
notatoad 1y ago
we've done this before, either with sales or support calls for the product. customer interaction is good, and can lead to good things. but it also leads to things that are heavily focused on the needs of one customer or one point in time. most of the stuff i've built as a direct result of customer interaction has been later deleted, as it becomes a maintenance burden with limited utility even for the customers who initially needed it. software should actually be planned, not written in response to somebody's gripes.
- Palomides 1y ago
  "does anyone use this?" is a running joke where I work because we always say yes to a feature request, most of them get used briefly by one customer, then we have to maintain/test forever just in case
analog31 1y ago
This is a recurring theme in quality control. Let the workers investigate and solve the problem themselves.
SpicyLemonZest 1y ago
Am I not supposed to notice the transition from "he promised me 5 calls and I guaranteed he'd never have to do it again" to "Every engineer takes 5 sales calls per quarter"? This kind of casual dishonesty makes me question the entire story. I've encountered a lot of people who think they're building a better product when they're really building N customized installs that will never again reconverge.
phyzome 1y ago
This is hilarious: https://old.reddit.com/r/Entrepreneur/comments/1mw5yfg/forced_every_engineer_to_take_sales_calls_they/n9vvuyz/?context=2 https://old.reddit.com/r/Entrepreneur/comments/1mw5yfg/force... > Sounds like you have no product managers or your PMs suck. The platform must also be dead simple if it can be rewritten in two weeks. And the OP's response: > we pride ourselves in not hiring any product folks until after we raised our series A. this helped us stay super lean, move fast, and build exactly what our customers want. ...which then gets called out as pretty much in direct conflict with what came before.
IOT_Apprentice 1y ago
Have every engineer to install their product at a customer site, this should be able be done remotely and use the product to load key data and update. Have your engineers take support calls.
wredcoll 1y ago
I don't know if this scales, but I ask for this at every company I work for and none of them agree. It frustrates.
GabeIsko 1y ago
I have been on the other side of this where engineers end up just being a technical support team, and are competed over to directly support accounts, and then there ends up being a plethora of hot fixes and custom solutions per customer. There is a ton of technical debt, because non of this stuff is tested properly and there are regressions all over the place. The whole thing goes under after a competitor, with their properly invested engineering resources makes a better and fully featured product than you. To me, this screams a real failure of product management. They can't communicate the needs of their customer to their engineers or push back against them? Having engineers take sales calls is not going to scale when you have an actually mature base of customers. If this product manager really wants Engineers to take sales calls, the Engineers need to earn part of the commission on the accounts. That is the only fair way to do this. I would never take a sales call without part of my compensation being commissions based.
ilc 1y ago
As an engineer, there's only one reason I don't want to be on customer calls: Once a customer knows the person who actually builds the product, they will short cut: - Customer Service - Product Management - Any other sane defenses you put in to protect a developer's time. And just contact me directly. Then what do I do to get them off of me without losing a customer? ... That is why engineers don't get on support calls. If I could be "Anon E. Mouse" for the engagement, that'd be fine. But fact is, that's not what happens.
- jacquesm 1y ago
  Yes, god forbid that an engineer would be contacted directly to solve a problem they have. The thought alone.
  - ilc 1y ago
    Yes, god forbid people escalate their issues properly so they go to the right people. The thought alone.
- convolvatron 1y ago
  personally I think the customers and I both get some value out of our interactions. but I normally don't sit on customer calls. why? because half of the time I screw up the sales aspect by saying - the salesperson told you what? no, we don't do anything like that - oh, yeah, this is easy, you don't really need our product, just use X - yeah, we have vague plans to do that, but no real schedule. its gonna be a major lift - once we finish coding and testing that, its gonna be great!
- teunispeters 1y ago
  And from experience, customer requests will not only be pushy and aggressive, but often at odds with company policy and directions. If they have a direct way to contact, one may end up not being able to do one's job due to the interruptions.
elzbardico 1y ago
Well. Then you should fire your project owners, product manager and marketing folks, as two things emerge clearly: 1 - Those people were not able either to capture what the customers really wanted, or to translate this into requirements for the developers, or both things at the same time. 2 - Due to the fact that their minds are trained to see things systematically, maybe you should remove all those layers between customers and developers.
marssaxman 1y ago
I used to love having a job where I had regular interaction with customers. It really made a difference in my ability to improve the features we had, and to design new systems which would be more likely to succeed. I miss that, and I wish more companies found a way to put engineers in contact with actual users... ...but if you tried to make me do even one sales call, at all, ever, for any reason, that would instantly terminate my interest in working for you.
aefalcon83 1y ago
Once upon a time I was doing some custom enhancement for what was probably our largest customer. The CEO and CTO both gave me different descriptions of what the customer wanted. Neither made any sense. I was out of the loop for this whole discussion, but I did get a forward of an email chain at some point that included the customer, so I ended up emailing him directly with stories for those two descriptions plus a third. The customer replied he needed the 3rd story, the one I came up with. This took at least two months to implement, so that was a lot of waste avoided. The amount of information that gets lost in hand-offs can be incredible. People directly involved in developing the product really need to be more involved with the customers, but I personally have had only bad experiences with organizations enabling this. Those responding here that they get to in some manner, I'm jealous.
Johnny555 1y ago
My former company used to have engineers sit on sales calls regularly too. While it was interesting to see what companies wanted and how they were sold our product, it wasn't extremely illuminating. The features that customers wanted were already on our roadmap, we had one feature that customers found confusing and hard to use, but it was written that way to meet the needs of our largest customer. Engineering wanted to streamline it but then it wouldn't have met that customer's needs. Eventually we wrote a "lite" version of the feature that was easier to use and turned that on for everyone but the big customer. (but that didn't come about because of engineers sitting on sales calls, we all knew it was hard to use but couldn't change it until it was on our product roadmap.
mikewarot 1y ago
When I was just getting started in programming, the best education I got came from the operations manager at a fossil fuel generating station. Russ Reynolds had a quite pragmatic view of computers as tools. Once I had written the system they wanted, he brought someone in from the plant and carefully explained that he was testing the system I built, and not them. He said "anything that goes wrong is his fault" pointing at me. He also told me to just be quiet and watch. User looks at system, doesn't know what to do... I say oh, just press F1 for help (it was back in the MS-DOS era), Russ says.. "how is he supposed to know that?" I was then enlightened. Every screen after that had "Press F1 for help" on it either on the top or bottom line of text
swader999 1y ago
My best projects have been where I code side by side with the actual users or subject matter experts. Built a small business loan approval app for a bank, sat right beside the underwriters. Airport billing system, worked one door down from accounting. They came to standup everyday, you take breaks with them, gradually they feel like they own the product.
- corysama 1y ago
  Ideally, folks would practice mob programming that includes rotating customers into the room in addition to a designer and a product manager. But, so many engineers have had bad experiences with pair programming that they allergically jump to making strawman arguments against even considering mob programming. Ex: It doesn't require you to be forced into doing it 24/7 for everything. You can still do the vast majority of your work alone in your cave.
Glyptodon 1y ago
IMO this stuff happens frequently because the layers between engineers and users (IE product, project management, executive leadership) are crap and blaming the engineers for it. Not that engineers can't be problematic. But product people who aren't technical enough and badly manage trade offs they don't understand or invent out of thin air outnumber engineers who are pigheaded know it alls more obsessed with technical minutae than product success. Another one I see in the same ballpark is hiring a bunch of outsourced coders and then wondering why velocity and quality goes down. (Because you're multiplying the mythical man month effect by the skill difference between a day laborer from Home Depot and someone with significant skills/domain knowledge like a welder or electrician.)
ConanRus 1y ago
[dead]
jmuguy 1y ago
> 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.
- awkward 1y ago
  It sounds like it's a B2B SaaS product that's gone through multiple pivots with very weak guidance on product on every step. Not that I'm disagreeing with you, but it's a very common way for things to go wrong.
  - jmuguy 1y ago
    There's just something about the specifics that seems really odd to me. "60% of features"... really? Sixty percent, specifically? Like I think this story is maybe based on some series of events at a SaaS and I agree with you in principle but it seems like the author ran it through a Linkedin thought leader LLM.
    - mvdtnz 1y ago
      60% of the features in a product small enough to rewrite in 2 weeks is probably 3 features.
- superdisk 1y ago
  You can tell it's fake by the LinkedIn-y prose, which is always short sentences followed by a "mic drop moment."
- encom 1y ago
  Of course it's fake, it's Reddit. How does this dredge reach the front page?
- Aurornis 1y ago
  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.
jacquesm 1y ago
Someone apply this to the Microsoft 'teams' team please.
nunez 1y ago
Very risky strategy with engineers that don't have good "customer presence" depending on the kind of sales calls they "ran." This is something I would expect product managers to do. I would say that this is more of a product management failure than anything else. Unless it's a super small early-stage startup, in which case all bets are off and I'd expect everyone to kind of do everything.
steele 1y ago
What kind of commission was involved and are the engineers now given product designer titles?
SirMaster 1y ago
OK, but do the actual sales people like to use the workflow that an engineer likes? Just because as an engineer I might try to be the end user, in order to design a UX to solve a problem, doesn't mean that the people who aren't engineers who will ultimately be using the UX for sales will actually like the workflow an engineer likes. If anything I have found from experience that what an engineer finds intuitive and fluid is not the same thing that most non-engineers find intuitive or fluid.
gtech1 1y ago
Relevant: https://www.youtube.com/watch?v=hNuu9CpdjIo https://www.youtube.com/watch?v=hNuu9CpdjIo
McNulty2 1y ago
I worked at a place where every new dev was required to spend a month or more working on the frontline helpdesk. It was very effective.
mrbluecoat 1y ago
Forced every politician to use average health insurance. They rewrote our national healthcare polices in 2 weeks.
alexeiz 1y ago
Here's what I see: * PM asking a client: "Do you want beautiful logging, metrics and shit?" - "Hell yeah we want logging, metrics and shit!" * PM telling devs: implement beautiful logging, metrics and shit * Devs spend half a year implementing all that shit * The client looks at the final product: "What is this shit? We need a freaking green checkmark!"
venuur 1y ago
I can’t comment on whether the PMs are doing their job, but I’ve been building on my own for almost a year now. Working directly with the end user is what motivates me and it’s very eye opening. A lot of engineering thought can miss without guidance. Some experience is always worthwhile.
mrkstu 1y ago
Sales engineers should be the spirit animals of PMs/SDEs. 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.
uberduper 1y ago
I worked at a place that made a robo-calling sales crm and they thought it would be great if during an offsite they had everyone use it to cold call places and run through some script they'd prepared. They didn't seem to understand nor care about what sort of anxiety that could cause not-sales-people. That's when I decided to start looking for another job.
darig 1y ago
[dead]
Bender 1y ago
I've seen something like this before. A monitoring team said that front-line engineers should be opening tickets for every alert that came in. There were upwards of 10,000 unique alerts per hour. Critical issues had been missed due to all the noise. The directors and VPs got an earful enough times that they forced the monitoring team to open tickets for all the alerts and troubleshoot them. The next day the system was down to about a dozen unique alerts per hour after excluding informational alerts and the remainder were eventually closed out. It was the first time the boards had all been green for real this time vs. painting them green for the media and the Gartner Group.
protocolture 1y ago
Inhumane. Humans shouldnt be exposed to sales calls. Thats why sales "people" exist.
yAak 1y ago
> Because they finally understood who was actually using our product. Yes!!! > The biggest problem with most engineers is actually over-engineering. Err, wait, go back to step 1. Over-engineering is sometimes a byproduct of not understanding the customer use cases. That lack of understanding is the biggest problem. So, I’m an “engineer” —- my most common frustration with other engineers is their lack of interest in understanding of the actual product being sold. In my experience, sometimes the reason is job-fit issues, sometimes it’s ego, but usually it’s a combination of culture and incentive.
davidgerard 1y ago
I am pretty sure that post was written with a chatbot. It reads like LinkedIn glurge. Do we have any evidence of the claimed sequence of events?
tr_user 1y ago
I don't think you can build a unified platform using anecdotes. That's why product research and product market fit is a thing. Not product customer fit. Unless you're willing to understand how to address your market segment's painpoints, you're just going to have a platform like jira that does nothing great but everyone somehow limps along with it.
rufus_foreman 1y ago
I forced every engineer to take sales calls and now our platform is command line only.
marcus_holmes 1y ago
I managed a tech team back in the late 90's and we were building a product used in a semi-industrial process. Every software dev joining the team spent their first week on the factory floor actually doing the job. Then when they started looking at the code they had some context.
ekusiadadus 1y ago
It doesn’t really look like the solution was simply forcing engineers to join sales calls. The real issue seems to have been a breakdown in communication between engineers and those relaying customer needs.
magicalhippo 1y ago
We make a B2B application, and I jump at the opportunity to join in on a support call with a customer or otherwise see how our customers use our product. I knew nothing about the sector when I started, but I've grown a fairly decent understanding of the challenges and pain points. However every customer does things a bit differently, and so it's useful to experience it first hand. That our dev team has such good understanding of the domain and our customers has been instrumental to the company's rise to a dominant position, I think. You just make better decisions, from small to large, when you're more in-tune with how the application will be used.
game_the0ry 1y ago
This makes me question why we need product managers. You could record the calls, have AI summarize them, and then have AI create user stories.
sinuhe69 1y ago
I always say the engineers and designer should actually use the product (including cleaning!), then we will have better products. It’s true for household items. It’s certainly true for software products.

324 points by bilsbie 1y ago

This is an excellent strategy for smaller startups, where every individual contributor needs to have an understanding of the customer's needs, in order to develop an understanding of what kind of product must be built. I have much more success in projects where I deeply understand the product requirements (because I am involved in defining them), than those where the product requirements are "handed" to me and I just have to implement something that satisfies them.

ranger_danger 1y ago
Are you saying that you follow directions better because you wrote them... or that you are just ending up with a better UX because of your involvement?
- dghlsakjg 1y ago
  Human communication is incredibly lossy (sometimes intentionally), plus humans will try to fill in gaps with assumed information. The more people you cut out between the message sender and the receiver, the more likely the message is to still be intact. The kindergarten game of telephone is the perfect demonstration. You only end up with distorted messages if you have many players between the sender and the receiver. If you play telephone with 2 people, you end up with a boring game where any mistakes in communication are immediately resolved.
  - davorak 1y ago
    The telephone game is the analogy I use too when explaining the value of having engineers in the custom calls. Other than mistakes in communication, engineers often know what the hard trade offs are when designing a new feature while sales and PMs do not. They can ask the questions to find out if a customer is on one side of a trade off or the other. Or if a feature is 10x as expensive to implement because the customer needs/wants the benefits on both sides. Finding that out at the start can save a full development cycle of time/effort at times.
    - dghlsakjg 1y ago
      > engineers often know what the hard trade offs are when designing a new feature while sales and PMs do not. I frequently run into the issue of PMs spending more time discussing and trying to slot a feature into the roadmap than it would take to just implement it. Most recently it was with trying to scope out how long it would take to ingest encrypted files. I wrote the feature and had a pull request up before the end of the meeting where they were trying to figure out if we could implement it this quarter or next. The inverse is when a feature is assumed to be technically easy to implement (just change that setting), and you have to gently explain why that will take a week. Having people who are technically competent in the meeting often allows a short circuit to getting tot the solution along a pathway that a PM didn't know esited ro was possible through no fault of their own.

richwater 1y ago

All this says to me is that they have no technical product/program management in place to actually do what is described.

dcastonguay 1y ago

> 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/actionable at turning customer needs into working solutions.”

hughredline 1y ago
> DevOps engineer is more capable/actionable at turning customer needs into working solutions That’s been my experience all my tears in industry.
- neogodless 1y ago
  I, too, have had many, many tears in this industry.
  - hughredline 1y ago
    ;P An errant autocorrect a little too correct to correct.
HPsquared 1y ago
Many such cases of employees adding negative value.
sc68cal 1y ago
-10x employees DO exist!
barbazoo 1y ago
Agree, also the whole thing reads kinda fake in the first place.
vkou 1y ago
This is the first thing that struck me. Why does the OP still have a job if a line engineer can do it better? Promote the guy to CTO, and fire the useless chumps who were collecting a paycheck spinning their wheels.

theshrike79 1y ago

Dogfooding works

pavel_lishin 1y ago
I don't think this is an example of that. This is just engineers being able to talk directly to customers, which is great in most cases. I absolutely loved my jobs where I could directly talk to the users of our products, especially when they came to me with bugs or problems. Unfortunately, that's not always possible. I wonder if that's why I always liked building tools for "internal" clients, other users within the org - it was trivial to just Slack someone or ask if I could walk over to their desk.
GuinansEyebrows 1y ago
difficult to do unless you're building tooling/personal productivity stuff. i don't know how a company would dogfood a point-of-sale platform, for example.
- theshrike79 1y ago
  Like this. =) Force the people making it to use it for a while. Even just a day.
  - GuinansEyebrows 1y ago
    fair!

ranger_danger 1y ago

Thankfully the comments agree that OP was the problem all along.

justtinker 1y ago

Out come the "this is dumb because .." messages in the redit responses. I have experiences dozens of projects where the developer had the wrong view of the end use needs for a myriad of reasons (everything after the because). It doesn't matter why in this case just that they found their solution. The TL;DR message should be make sure the real needs get serviced.

pseudocomposer 1y ago

At my company, as developers, we rotate taking support tickets and working directly with customers on the issues our (very capable) support team can’t handle. We and our customers are both very happy with the results.

snarf21 1y ago
Yeah, this drives value for almost all roles. No need for a separate focus group when you can ask the people who are already using and/or paying for your product.
nunez 1y ago
What you're describing is customer success, which is almost always post-sales. Engineers working with customers post-sales is a great idea. *Pre*-sales is where it gets tricky.

m463 1y ago

All the negative responses. I have been at countless places where the engineers are out of sync with the product. And it might be something silly like their coworker added something they didn't know about and the UI is now confusing. Could even be the website started proclaiming something that didn't align well with the product. Another factor is that the [product -> PM -> bug system -> engineer -> fix -> QA -> product] loop is heavy. It takes a long time and major things get fixed but minor friction doesn't. having [product <-> engineer] can be amazing. Engineers might have never encountered the full experience, or may merely be out of sync with how it works today vs last year.

PaulKeeble 1y ago
There are myriad of ways to get this wrong and I have seen them all happen: - force all the communications with the users through Project Managers or Product Owners. Sometimes they are great and sometimes they are terrible. - The customers refuse to talk to the developers and so they are forced to interpret the users managers requirements without any further input. - The developers just want to write code and refuse to meet the customer forcing all communication through their product manager or bug tracker. - I have seen a couple of times where commercial software platforms were used the technology can get in the way, they are limited in the types of modifications and customisations that can be applied and this can make some workflows really awful. There is always a disconnect somewhere, someone blocking a conversation happening and it can be the customer, a middle man or the developers causing it, often its all three to get a really dysfunctional system or the solution has been chosen before any developers or users really got into the details and its the wrong choice. There are a lot of ways to make systems that aren't very good for the users.
nunez 1y ago
you're not wrong, but i don't think forcing engineers to take sales calls is the right move either. there's lots of soft skills involved in running a successful call that engineers aren't trained or even interviewed on. (i'm definining "sales calls" as the initial discovery call before a demo or proof of concept is agreed upon. i would be okay with having engineers _ride along_ for complex presales demos, but even then, product should really be serving that role.)

notatoad 1y ago

we've done this before, either with sales or support calls for the product. customer interaction is good, and can lead to good things. but it also leads to things that are heavily focused on the needs of one customer or one point in time. most of the stuff i've built as a direct result of customer interaction has been later deleted, as it becomes a maintenance burden with limited utility even for the customers who initially needed it. software should actually be planned, not written in response to somebody's gripes.

Palomides 1y ago
"does anyone use this?" is a running joke where I work because we always say yes to a feature request, most of them get used briefly by one customer, then we have to maintain/test forever just in case

analog31 1y ago

This is a recurring theme in quality control. Let the workers investigate and solve the problem themselves.

SpicyLemonZest 1y ago

Am I not supposed to notice the transition from "he promised me 5 calls and I guaranteed he'd never have to do it again" to "Every engineer takes 5 sales calls per quarter"? This kind of casual dishonesty makes me question the entire story. I've encountered a lot of people who think they're building a better product when they're really building N customized installs that will never again reconverge.

phyzome 1y ago

This is hilarious: https://old.reddit.com/r/Entrepreneur/comments/1mw5yfg/forced_every_engineer_to_take_sales_calls_they/n9vvuyz/?context=2 https://old.reddit.com/r/Entrepreneur/comments/1mw5yfg/force... > Sounds like you have no product managers or your PMs suck. The platform must also be dead simple if it can be rewritten in two weeks. And the OP's response: > we pride ourselves in not hiring any product folks until after we raised our series A. this helped us stay super lean, move fast, and build exactly what our customers want. ...which then gets called out as pretty much in direct conflict with what came before.

IOT_Apprentice 1y ago

Have every engineer to install their product at a customer site, this should be able be done remotely and use the product to load key data and update. Have your engineers take support calls.

wredcoll 1y ago

I don't know if this scales, but I ask for this at every company I work for and none of them agree. It frustrates.

GabeIsko 1y ago

I have been on the other side of this where engineers end up just being a technical support team, and are competed over to directly support accounts, and then there ends up being a plethora of hot fixes and custom solutions per customer. There is a ton of technical debt, because non of this stuff is tested properly and there are regressions all over the place. The whole thing goes under after a competitor, with their properly invested engineering resources makes a better and fully featured product than you. To me, this screams a real failure of product management. They can't communicate the needs of their customer to their engineers or push back against them? Having engineers take sales calls is not going to scale when you have an actually mature base of customers. If this product manager really wants Engineers to take sales calls, the Engineers need to earn part of the commission on the accounts. That is the only fair way to do this. I would never take a sales call without part of my compensation being commissions based.

ilc 1y ago

As an engineer, there's only one reason I don't want to be on customer calls: Once a customer knows the person who actually builds the product, they will short cut: - Customer Service - Product Management - Any other sane defenses you put in to protect a developer's time. And just contact me directly. Then what do I do to get them off of me without losing a customer? ... That is why engineers don't get on support calls. If I could be "Anon E. Mouse" for the engagement, that'd be fine. But fact is, that's not what happens.

jacquesm 1y ago
Yes, god forbid that an engineer would be contacted directly to solve a problem they have. The thought alone.
- ilc 1y ago
  Yes, god forbid people escalate their issues properly so they go to the right people. The thought alone.
convolvatron 1y ago
personally I think the customers and I both get some value out of our interactions. but I normally don't sit on customer calls. why? because half of the time I screw up the sales aspect by saying - the salesperson told you what? no, we don't do anything like that - oh, yeah, this is easy, you don't really need our product, just use X - yeah, we have vague plans to do that, but no real schedule. its gonna be a major lift - once we finish coding and testing that, its gonna be great!
teunispeters 1y ago
And from experience, customer requests will not only be pushy and aggressive, but often at odds with company policy and directions. If they have a direct way to contact, one may end up not being able to do one's job due to the interruptions.

elzbardico 1y ago

Well. Then you should fire your project owners, product manager and marketing folks, as two things emerge clearly: 1 - Those people were not able either to capture what the customers really wanted, or to translate this into requirements for the developers, or both things at the same time. 2 - Due to the fact that their minds are trained to see things systematically, maybe you should remove all those layers between customers and developers.

marssaxman 1y ago

I used to love having a job where I had regular interaction with customers. It really made a difference in my ability to improve the features we had, and to design new systems which would be more likely to succeed. I miss that, and I wish more companies found a way to put engineers in contact with actual users... ...but if you tried to make me do even one sales call, at all, ever, for any reason, that would instantly terminate my interest in working for you.

aefalcon83 1y ago

Once upon a time I was doing some custom enhancement for what was probably our largest customer. The CEO and CTO both gave me different descriptions of what the customer wanted. Neither made any sense. I was out of the loop for this whole discussion, but I did get a forward of an email chain at some point that included the customer, so I ended up emailing him directly with stories for those two descriptions plus a third. The customer replied he needed the 3rd story, the one I came up with. This took at least two months to implement, so that was a lot of waste avoided. The amount of information that gets lost in hand-offs can be incredible. People directly involved in developing the product really need to be more involved with the customers, but I personally have had only bad experiences with organizations enabling this. Those responding here that they get to in some manner, I'm jealous.

Johnny555 1y ago

My former company used to have engineers sit on sales calls regularly too. While it was interesting to see what companies wanted and how they were sold our product, it wasn't extremely illuminating. The features that customers wanted were already on our roadmap, we had one feature that customers found confusing and hard to use, but it was written that way to meet the needs of our largest customer. Engineering wanted to streamline it but then it wouldn't have met that customer's needs. Eventually we wrote a "lite" version of the feature that was easier to use and turned that on for everyone but the big customer. (but that didn't come about because of engineers sitting on sales calls, we all knew it was hard to use but couldn't change it until it was on our product roadmap.

mikewarot 1y ago

When I was just getting started in programming, the best education I got came from the operations manager at a fossil fuel generating station. Russ Reynolds had a quite pragmatic view of computers as tools. Once I had written the system they wanted, he brought someone in from the plant and carefully explained that he was testing the system I built, and not them. He said "anything that goes wrong is his fault" pointing at me. He also told me to just be quiet and watch. User looks at system, doesn't know what to do... I say oh, just press F1 for help (it was back in the MS-DOS era), Russ says.. "how is he supposed to know that?" I was then enlightened. Every screen after that had "Press F1 for help" on it either on the top or bottom line of text

swader999 1y ago

My best projects have been where I code side by side with the actual users or subject matter experts. Built a small business loan approval app for a bank, sat right beside the underwriters. Airport billing system, worked one door down from accounting. They came to standup everyday, you take breaks with them, gradually they feel like they own the product.

corysama 1y ago
Ideally, folks would practice mob programming that includes rotating customers into the room in addition to a designer and a product manager. But, so many engineers have had bad experiences with pair programming that they allergically jump to making strawman arguments against even considering mob programming. Ex: It doesn't require you to be forced into doing it 24/7 for everything. You can still do the vast majority of your work alone in your cave.

Glyptodon 1y ago

IMO this stuff happens frequently because the layers between engineers and users (IE product, project management, executive leadership) are crap and blaming the engineers for it. Not that engineers can't be problematic. But product people who aren't technical enough and badly manage trade offs they don't understand or invent out of thin air outnumber engineers who are pigheaded know it alls more obsessed with technical minutae than product success. Another one I see in the same ballpark is hiring a bunch of outsourced coders and then wondering why velocity and quality goes down. (Because you're multiplying the mythical man month effect by the skill difference between a day laborer from Home Depot and someone with significant skills/domain knowledge like a welder or electrician.)

ConanRus 1y ago

[dead]

jmuguy 1y ago

> 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.

awkward 1y ago
It sounds like it's a B2B SaaS product that's gone through multiple pivots with very weak guidance on product on every step. Not that I'm disagreeing with you, but it's a very common way for things to go wrong.
- jmuguy 1y ago
  There's just something about the specifics that seems really odd to me. "60% of features"... really? Sixty percent, specifically? Like I think this story is maybe based on some series of events at a SaaS and I agree with you in principle but it seems like the author ran it through a Linkedin thought leader LLM.
  - mvdtnz 1y ago
    60% of the features in a product small enough to rewrite in 2 weeks is probably 3 features.
superdisk 1y ago
You can tell it's fake by the LinkedIn-y prose, which is always short sentences followed by a "mic drop moment."
encom 1y ago
Of course it's fake, it's Reddit. How does this dredge reach the front page?
Aurornis 1y ago
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.

jacquesm 1y ago

Someone apply this to the Microsoft 'teams' team please.

nunez 1y ago

Very risky strategy with engineers that don't have good "customer presence" depending on the kind of sales calls they "ran." This is something I would expect product managers to do. I would say that this is more of a product management failure than anything else. Unless it's a super small early-stage startup, in which case all bets are off and I'd expect everyone to kind of do everything.

steele 1y ago

What kind of commission was involved and are the engineers now given product designer titles?

SirMaster 1y ago

OK, but do the actual sales people like to use the workflow that an engineer likes? Just because as an engineer I might try to be the end user, in order to design a UX to solve a problem, doesn't mean that the people who aren't engineers who will ultimately be using the UX for sales will actually like the workflow an engineer likes. If anything I have found from experience that what an engineer finds intuitive and fluid is not the same thing that most non-engineers find intuitive or fluid.

gtech1 1y ago

Relevant: https://www.youtube.com/watch?v=hNuu9CpdjIo https://www.youtube.com/watch?v=hNuu9CpdjIo

McNulty2 1y ago

I worked at a place where every new dev was required to spend a month or more working on the frontline helpdesk. It was very effective.

mrbluecoat 1y ago

Forced every politician to use average health insurance. They rewrote our national healthcare polices in 2 weeks.

alexeiz 1y ago

Here's what I see: * PM asking a client: "Do you want beautiful logging, metrics and shit?" - "Hell yeah we want logging, metrics and shit!" * PM telling devs: implement beautiful logging, metrics and shit * Devs spend half a year implementing all that shit * The client looks at the final product: "What is this shit? We need a freaking green checkmark!"

venuur 1y ago

I can’t comment on whether the PMs are doing their job, but I’ve been building on my own for almost a year now. Working directly with the end user is what motivates me and it’s very eye opening. A lot of engineering thought can miss without guidance. Some experience is always worthwhile.

mrkstu 1y ago

Sales engineers should be the spirit animals of PMs/SDEs. 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.

uberduper 1y ago

I worked at a place that made a robo-calling sales crm and they thought it would be great if during an offsite they had everyone use it to cold call places and run through some script they'd prepared. They didn't seem to understand nor care about what sort of anxiety that could cause not-sales-people. That's when I decided to start looking for another job.

darig 1y ago

[dead]

Bender 1y ago

I've seen something like this before. A monitoring team said that front-line engineers should be opening tickets for every alert that came in. There were upwards of 10,000 unique alerts per hour. Critical issues had been missed due to all the noise. The directors and VPs got an earful enough times that they forced the monitoring team to open tickets for all the alerts and troubleshoot them. The next day the system was down to about a dozen unique alerts per hour after excluding informational alerts and the remainder were eventually closed out. It was the first time the boards had all been green for real this time vs. painting them green for the media and the Gartner Group.

protocolture 1y ago

Inhumane. Humans shouldnt be exposed to sales calls. Thats why sales "people" exist.

yAak 1y ago

> Because they finally understood who was actually using our product. Yes!!! > The biggest problem with most engineers is actually over-engineering. Err, wait, go back to step 1. Over-engineering is sometimes a byproduct of not understanding the customer use cases. That lack of understanding is the biggest problem. So, I’m an “engineer” —- my most common frustration with other engineers is their lack of interest in understanding of the actual product being sold. In my experience, sometimes the reason is job-fit issues, sometimes it’s ego, but usually it’s a combination of culture and incentive.

davidgerard 1y ago

I am pretty sure that post was written with a chatbot. It reads like LinkedIn glurge. Do we have any evidence of the claimed sequence of events?

tr_user 1y ago

I don't think you can build a unified platform using anecdotes. That's why product research and product market fit is a thing. Not product customer fit. Unless you're willing to understand how to address your market segment's painpoints, you're just going to have a platform like jira that does nothing great but everyone somehow limps along with it.

rufus_foreman 1y ago

I forced every engineer to take sales calls and now our platform is command line only.

marcus_holmes 1y ago

I managed a tech team back in the late 90's and we were building a product used in a semi-industrial process. Every software dev joining the team spent their first week on the factory floor actually doing the job. Then when they started looking at the code they had some context.

ekusiadadus 1y ago

It doesn’t really look like the solution was simply forcing engineers to join sales calls. The real issue seems to have been a breakdown in communication between engineers and those relaying customer needs.

magicalhippo 1y ago

We make a B2B application, and I jump at the opportunity to join in on a support call with a customer or otherwise see how our customers use our product. I knew nothing about the sector when I started, but I've grown a fairly decent understanding of the challenges and pain points. However every customer does things a bit differently, and so it's useful to experience it first hand. That our dev team has such good understanding of the domain and our customers has been instrumental to the company's rise to a dominant position, I think. You just make better decisions, from small to large, when you're more in-tune with how the application will be used.

game_the0ry 1y ago

This makes me question why we need product managers. You could record the calls, have AI summarize them, and then have AI create user stories.

sinuhe69 1y ago

I always say the engineers and designer should actually use the product (including cleaning!), then we will have better products. It’s true for household items. It’s certainly true for software products.