5 ms·

The problem is that no one actually dug in, which is why I say 80% of product people are a net negative. If someone asks for something, dig in. Think about it

The problem is that no one actually dug in, which is why I say 80% of product people are a net negative. If someone asks for something, dig in. Think about it like this. I go to a mechanic and tell them to replace my alternator. They do. I'm unhappy with and tell them they did a bad job. vs I got to a mechanic and tell them to replace my alternator. They ask me WHY I want the alternator replaced. I tell them my vehicle isn't running and I need it to transport me from A to B. They then start asking me questions. Turns out it was the solenoid, they replace it, my vehicle successfully transports me from A to B and I think they did a great job. This is why senior developers often make better product people than product people. Too often you'll see PM's who will tell you the have 1-2, sometimes up to 5 years of experience as a developer. But quite often they don't actually understand anything because you can't beat that veteran with a guy who worked for a year or two then got a certificate for a product job. people need to dig in, it doesn't matter what your assumption is, if you're not digging in and not having conversations you're making suboptimal decisions.

AntonZ234 3y ago
I can relate to the senior developers in PM roles. I only worked with one such PM, but he was amazing. Most of the PMs come from non-tech background, more project-management types, and it shows.
FridgeSeal 3y ago
Fully agreed. Once worked in a place that hired a design researcher and they were amazing, they took the time to dig in to what you’re talking about here: the actual issues, not the words that came out of people’s mouthes. Had a lot of good insights, which were ultimately wasted on that particular business, but that’s for different reasons.
- hitchstory 3y ago
  The most successful company I ever worked out figured out a way to perform and get high quality feedback on low cost user experiments with a quick turnaround. About 4/10 failed, 5/10 did ok and then with 1/10 they would absolutely hit it out of the park - usually on something that looked about as promising as the other 10. They did this frequently enough that they clobbered the competition, who were mostly just trying to do normal product management stuff like user surveys, etc. The most interesting thing was that most people if you'd have asked them before would have gone "I don't think you can turn this into an experiment" and then immediately adopted a different strategy. Somehow they always figured out a creative way of injecting a low cost experiment where most people would have imagined that it wasnt feasible to run any experiment at all. It required quite a lot of pressure/leadership from above.
  - ac2u 3y ago
    Concrete examples sound interesting here in so far as you’re able to share
    - hitchstory 3y ago
      One example was when they decided to test out the idea of sending particular kinds of price change notification emails to users. They created one checkbox on a form our users could click and set up a trigger to fire notify somebody in the Philippines who would construct the emails manually from the database. They then iterated on those emails, creating them manually the whole time. Once the email was iterated upon and the idea was proven (i.e. that users actually wanted it in the form that existed), it was handed back to me to automate properly, which in that case took about 7-10 days of dev work. Or not, if it turned out the customers simply weren't interested. There were plenty of experiments like that where I created a checkbox or something and then we quietly removed it 2 weeks later. It was a refreshing change from past jobs where I'd spent weeks working on a feature asked for by users that we were so sure would be a game changer only to see 1 or 2 people actually use it.
      - satvikpendem 3y ago
        It's the same advice as building an MVP, do everything manually first, then automate once you've proven the market, basically Paul Graham's advice of doing things that don't scale. The Doordash founders hand-delivered food first before building an app.
        esafak 3y ago
        Obviously, that does not apply if the market already exists, which it usually does. In that case you have to be different and better enough than the alternatives.
        satvikpendem 3y ago
        Why doesn't it apply? Even if there were a lot of food delivery companies, it would still be good to gain traction through doing it manually instead of (or before) spending months building out a software solution. Even better, because one would personally deliver the food, they can talk to customers and ask what problems they have currently with other food delivery competitors, thereby learning what differentiating advantage would work well when creating the software solution. In other words, doing things that don't scale is not just useful for validating the market, it's arguably even more useful for validating one's specific implementation of a product, and also derisking the business model as a whole rather than having high capex initially.
pm 3y ago
Absolutely. 95% of the suggestions product creators receive are solutions. A product creator's job is to work out what problem their customer is trying to solve. It goes to the same motivation as root cause analysis when analysing an outage: the actual problem is nestled deep under layers of semantic shielding. Whether your product is trying to solve that problem is another question, but at least you can understand how others perceive and try to use your product, which goes a long way to getting a product to be more broadly adopted.
- wanderingmind 3y ago
  semantic shielding is a word I have not heard before. But it perfectly summarizes most of the interactions with customers and stakeholders
  - hliyan 3y ago
    Causal shielding feels like a better term in this case
  - pm 3y ago
    I honestly made it up on the spot, so don't take it as proper nomenclature. However, to describe it another way: the unconscious mind synthesises its emotional choice, which the conscious mind presents as rational fact. If you want to know how the mind arrived at that conclusion, you've got to go on a fact-finding mission, i.e., asking why. However, asking that question without triggering a negative response is an art form within itself. Rarely can you be so direct, which is why it's often much easier to watch how a person interacts with a product rather than asking them why they did what they did.
    - PH95VuimJjqBqy 3y ago
      > the unconscious mind synthesises its emotional choice, which the conscious mind presents as rational fact. If you want to know how the mind arrived at that conclusion, you've got to go on a fact-finding mission, i.e., asking why. the more common name for it is post-hoc rationalization.
mcmoor 3y ago
It's a good old XY problem. Funnily I've heard customers that doesn't wanna bother getting asked why, they just want someone who do what they're told. Some junior engineers too, just wants the answer of what is asked instead of "the real problem".
- chmod600 3y ago
  The XY problem is poorly-framed. First of all, it's often a false dichotomy: you can answer the X directly and dig deeper to find Y. Second, it places the questioner in a "normal" bucket: surely they must have the same boring mundane needs as everyone else, and we just need to figure out which one it is (Y). But some people really are working on something interesting, and need to understand X to do so. Thirdly, even if Y really is better for them, they still might benefit from an answer to X to avoid asking future variations of X.
wouldbecouldbe 3y ago
The challenge here can be often that even though the client doesn't really need it, they are convinced they do. Even after digging deeper you understand there are other issues, for instance marketing or sales, that might not even be related to your software. But if they are a key client you might end up building it, understanding it won't solve their core issues but doing so in order to keep them happy
- bluGill 3y ago
  That happens, then you need to figure out how to handle them. Sometimes when you show them what they really need 'the light goes on' and they don't care about what they asked for anymore (or worse someone else shows it to them and they don't buy from you at all despite your customer focus). Other times they remain convinced they need that thing and so you need to gike it to them lest they buy from someone else). this it a hard problem to figure out, good luck.
- satvikpendem 3y ago
  This is one reason why it's better to have lots of small clients than a few big clients, because over time, the few big ones will increasingly dictate your product strategy in ways you will not want to go. Jason Fried from Basecamp has a good article about this [0]. [0] https://www.inc.com/magazine/201206/jason-fried/huge-accounts-make-me-nervous-it-takes-a-village.html https://www.inc.com/magazine/201206/jason-fried/huge-account... (Archive link: https://archive.is/IHmwL https://archive.is/IHmwL)
robertlagrant 3y ago
> They ask me WHY I want the alternator replaced. I tell them my vehicle isn't running and I need it to transport me from A to B. They then start asking me questions. Turns out it was the solenoid, they replace it, my vehicle successfully transports me from A to B An XY problem[0] about A-B! [0] https://en.m.wikipedia.org/wiki/XY_problem https://en.m.wikipedia.org/wiki/XY_problem
- smeej 3y ago
  Thank you for this link! I finally understand why one of my former coworkers' answers always frustrated me as much as they did. I would always ask my Slack questions in XY format, but lead with the actual question, followed by a full paragraph explaining exactly why I believed X to be the solution for Y, and what other letters I had tried before concluding that X was the next likeliest solution for Y. Something in her brain was programmed to see an XY question and immediately assume the asker was wrong about X. Not once did she read the following paragraph. I would have to reiterate it sentence by sentence as she asked as many "what abouts" to try to challenge my X as I had sentences in the paragraph. It drove me BONKERS. But I never understood how there was such a disconnect between my frustration and how much customers actually apparently liked dealing with her. Her default approach to XY questions was probably very effective with people who actually did not know the product in-depth, but was profoundly aggravating to those of us whose job it was to be familiar with all the other letters, who really, truly only wanted the answer about X and did not need someone to rethink our entire process.
  - delecti 3y ago
    I have such little patience for that kind of person. In slack (well mattermost, but it's essentially the same thing) you can copy the direct link to a message and it'll re-embed it if you link to it in a subsequent message. I'll do that if someone is asking questions I just answered, because really what's the point of a conversation if you're ignoring my half of it.
    - smeej 3y ago
      I started so many replies with, "As I mentioned," that I needed a keyboard shortcut for it.
sameerds 3y ago
It's hard for me to say this without wondering if I am being rude, but did you mean to say "dig down"? At least to me, "to dig in" means to prepare for a long-drawn confrontation (like an argument or a battle). Maybe I am wrong, but my brain just wouldn't let me go on to the next comment without pointing it out.

AntonZ234 3y ago

I can relate to the senior developers in PM roles. I only worked with one such PM, but he was amazing. Most of the PMs come from non-tech background, more project-management types, and it shows.

FridgeSeal 3y ago

Fully agreed. Once worked in a place that hired a design researcher and they were amazing, they took the time to dig in to what you’re talking about here: the actual issues, not the words that came out of people’s mouthes. Had a lot of good insights, which were ultimately wasted on that particular business, but that’s for different reasons.

hitchstory 3y ago
The most successful company I ever worked out figured out a way to perform and get high quality feedback on low cost user experiments with a quick turnaround. About 4/10 failed, 5/10 did ok and then with 1/10 they would absolutely hit it out of the park - usually on something that looked about as promising as the other 10. They did this frequently enough that they clobbered the competition, who were mostly just trying to do normal product management stuff like user surveys, etc. The most interesting thing was that most people if you'd have asked them before would have gone "I don't think you can turn this into an experiment" and then immediately adopted a different strategy. Somehow they always figured out a creative way of injecting a low cost experiment where most people would have imagined that it wasnt feasible to run any experiment at all. It required quite a lot of pressure/leadership from above.
- ac2u 3y ago
  Concrete examples sound interesting here in so far as you’re able to share
  - hitchstory 3y ago
    One example was when they decided to test out the idea of sending particular kinds of price change notification emails to users. They created one checkbox on a form our users could click and set up a trigger to fire notify somebody in the Philippines who would construct the emails manually from the database. They then iterated on those emails, creating them manually the whole time. Once the email was iterated upon and the idea was proven (i.e. that users actually wanted it in the form that existed), it was handed back to me to automate properly, which in that case took about 7-10 days of dev work. Or not, if it turned out the customers simply weren't interested. There were plenty of experiments like that where I created a checkbox or something and then we quietly removed it 2 weeks later. It was a refreshing change from past jobs where I'd spent weeks working on a feature asked for by users that we were so sure would be a game changer only to see 1 or 2 people actually use it.
    - satvikpendem 3y ago
      It's the same advice as building an MVP, do everything manually first, then automate once you've proven the market, basically Paul Graham's advice of doing things that don't scale. The Doordash founders hand-delivered food first before building an app.
      - esafak 3y ago
        Obviously, that does not apply if the market already exists, which it usually does. In that case you have to be different and better enough than the alternatives.
        satvikpendem 3y ago
        Why doesn't it apply? Even if there were a lot of food delivery companies, it would still be good to gain traction through doing it manually instead of (or before) spending months building out a software solution. Even better, because one would personally deliver the food, they can talk to customers and ask what problems they have currently with other food delivery competitors, thereby learning what differentiating advantage would work well when creating the software solution. In other words, doing things that don't scale is not just useful for validating the market, it's arguably even more useful for validating one's specific implementation of a product, and also derisking the business model as a whole rather than having high capex initially.

pm 3y ago

Absolutely. 95% of the suggestions product creators receive are solutions. A product creator's job is to work out what problem their customer is trying to solve. It goes to the same motivation as root cause analysis when analysing an outage: the actual problem is nestled deep under layers of semantic shielding. Whether your product is trying to solve that problem is another question, but at least you can understand how others perceive and try to use your product, which goes a long way to getting a product to be more broadly adopted.

wanderingmind 3y ago
semantic shielding is a word I have not heard before. But it perfectly summarizes most of the interactions with customers and stakeholders
- hliyan 3y ago
  Causal shielding feels like a better term in this case
- pm 3y ago
  I honestly made it up on the spot, so don't take it as proper nomenclature. However, to describe it another way: the unconscious mind synthesises its emotional choice, which the conscious mind presents as rational fact. If you want to know how the mind arrived at that conclusion, you've got to go on a fact-finding mission, i.e., asking why. However, asking that question without triggering a negative response is an art form within itself. Rarely can you be so direct, which is why it's often much easier to watch how a person interacts with a product rather than asking them why they did what they did.
  - PH95VuimJjqBqy 3y ago
    > the unconscious mind synthesises its emotional choice, which the conscious mind presents as rational fact. If you want to know how the mind arrived at that conclusion, you've got to go on a fact-finding mission, i.e., asking why. the more common name for it is post-hoc rationalization.

mcmoor 3y ago

It's a good old XY problem. Funnily I've heard customers that doesn't wanna bother getting asked why, they just want someone who do what they're told. Some junior engineers too, just wants the answer of what is asked instead of "the real problem".

chmod600 3y ago
The XY problem is poorly-framed. First of all, it's often a false dichotomy: you can answer the X directly and dig deeper to find Y. Second, it places the questioner in a "normal" bucket: surely they must have the same boring mundane needs as everyone else, and we just need to figure out which one it is (Y). But some people really are working on something interesting, and need to understand X to do so. Thirdly, even if Y really is better for them, they still might benefit from an answer to X to avoid asking future variations of X.

wouldbecouldbe 3y ago

The challenge here can be often that even though the client doesn't really need it, they are convinced they do. Even after digging deeper you understand there are other issues, for instance marketing or sales, that might not even be related to your software. But if they are a key client you might end up building it, understanding it won't solve their core issues but doing so in order to keep them happy

bluGill 3y ago
That happens, then you need to figure out how to handle them. Sometimes when you show them what they really need 'the light goes on' and they don't care about what they asked for anymore (or worse someone else shows it to them and they don't buy from you at all despite your customer focus). Other times they remain convinced they need that thing and so you need to gike it to them lest they buy from someone else). this it a hard problem to figure out, good luck.
satvikpendem 3y ago
This is one reason why it's better to have lots of small clients than a few big clients, because over time, the few big ones will increasingly dictate your product strategy in ways you will not want to go. Jason Fried from Basecamp has a good article about this [0]. [0] https://www.inc.com/magazine/201206/jason-fried/huge-accounts-make-me-nervous-it-takes-a-village.html https://www.inc.com/magazine/201206/jason-fried/huge-account... (Archive link: https://archive.is/IHmwL https://archive.is/IHmwL)

robertlagrant 3y ago

> They ask me WHY I want the alternator replaced. I tell them my vehicle isn't running and I need it to transport me from A to B. They then start asking me questions. Turns out it was the solenoid, they replace it, my vehicle successfully transports me from A to B An XY problem[0] about A-B! [0] https://en.m.wikipedia.org/wiki/XY_problem https://en.m.wikipedia.org/wiki/XY_problem

smeej 3y ago
Thank you for this link! I finally understand why one of my former coworkers' answers always frustrated me as much as they did. I would always ask my Slack questions in XY format, but lead with the actual question, followed by a full paragraph explaining exactly why I believed X to be the solution for Y, and what other letters I had tried before concluding that X was the next likeliest solution for Y. Something in her brain was programmed to see an XY question and immediately assume the asker was wrong about X. Not once did she read the following paragraph. I would have to reiterate it sentence by sentence as she asked as many "what abouts" to try to challenge my X as I had sentences in the paragraph. It drove me BONKERS. But I never understood how there was such a disconnect between my frustration and how much customers actually apparently liked dealing with her. Her default approach to XY questions was probably very effective with people who actually did not know the product in-depth, but was profoundly aggravating to those of us whose job it was to be familiar with all the other letters, who really, truly only wanted the answer about X and did not need someone to rethink our entire process.
- delecti 3y ago
  I have such little patience for that kind of person. In slack (well mattermost, but it's essentially the same thing) you can copy the direct link to a message and it'll re-embed it if you link to it in a subsequent message. I'll do that if someone is asking questions I just answered, because really what's the point of a conversation if you're ignoring my half of it.
  - smeej 3y ago
    I started so many replies with, "As I mentioned," that I needed a keyboard shortcut for it.

sameerds 3y ago

It's hard for me to say this without wondering if I am being rude, but did you mean to say "dig down"? At least to me, "to dig in" means to prepare for a long-drawn confrontation (like an argument or a battle). Maybe I am wrong, but my brain just wouldn't let me go on to the next comment without pointing it out.