5 ms·

A team with a strong product leader who is visionary and empathizes with users will run circles around a loosely organized group of stakeholders/engineers duct

by netfl0 5y ago

A team with a strong product leader who is visionary and empathizes with users will run circles around a loosely organized group of stakeholders/engineers duct taped together by process. The problem is that it is hard to scale.

neandrake 5y ago
This has been my experience, along with most great product leaders I’ve known have been “promoted” from developers/engineering as opposed to from the business end. Most devs/engineers I know also don’t want to take on this responsibility because they would rather be developing rather than overseeing product development.
- MattGaiser 5y ago
  I find that it is enough to have an engineering background. Someone who grasps why simply adding a new button on the frontend might require a week of backend work because of prior decisions.
- datavirtue 5y ago
  I would love this role and have had the chance to act in it. I'm quite adept at it but I do not want to be thrown into a business or domain that I don't know. It's like asking me to invest in a company or industry that I'm not an expert at. I need to be a a dev that just crushes stories for a while so that I can observe and learn about the business. I can sense the fear and imposter syndrome in people who have never been a dev and who don't really know the business. They are dead weight, and nobody wants to be dead weight.
topspin 5y ago
> A team with a strong product leader I think the problem begins before the 'leader.' The product itself dictates all the downstream consequences, including whether 'requirements' are a problem. Assuming no fatal management dysfunction, when you're working on a product that has substantial value, enough that the customer is eager to pay for what you're capable of delivering, requirements are straightforward. When you're working on things of low value and the customer won't pay unless they get an ever more improbable gymnastics routine and every tier of stake holder is lying to the other then you starting hearing about 'requirements' problems. The 'requirements' problem severity is a function of where you are on on the continuum between these two products.
- mason55 5y ago
  Depends what you’re trying to build. Sure, if you’re just doing consulting work then go get requirements from a customer and deliver on them. If you’re building a real product there’s frequently not even an existing customer and certainly none to “give you requirements”. You need to understand problems to solve and turn those into requirements for a product and if you can do that then you’re not working at a customer giving requirements to a vendor.
  - bluGill 5y ago
    Even when you get requirements beware that the customer doesn't know what they want. So you get asked to make a faster horse instead of invent the car.
  - mdaniel 5y ago
    > You need to understand problems to solve and turn those into requirements for a product One subtly for me is that what you said is 100% true of the parts of the organization which interact with customers, or even design partners who want to become customers. But since not every member of engineering is in that role, the requirements which come back from those meetings still need to be "MVP accurate" and (IMHO) need to specify just as much what it *won't* do as what it needs to do For example, "customer wants to query for names" is a shitty requirement. Of course they do, we all want search engines for everything, but that's not how software works. Do they want it case sensitive, case insensitive, the ability to indicate by using special search syntax (like "quoted"), do they want "starts with" or "contains" searches, wildcard characters? Getting to MVP means not building the wrong or extraneous things just as much as building the right things, and only a handful of people bear responsibility for distinguishing between those sets
- deleted 5y ago
  [deleted]
- bcrosby95 5y ago
  Just because someone can pay for a requirement doesn't mean that requirement adds value to a product. If I think the cost for a requirement is higher than its value - which may potentially even be negative - I'm going to present my case for stripping it out.
natmaka 5y ago
Exactly, and in 3 decades of activity I didn't encounter a single counter-example. > The problem is that it is hard to scale. This is true for everything involving human beings.
- njharman 5y ago
  Tons of human things have been scaled. Agriculture, retail, manufacturing, soildering, …
  - natmaka 5y ago
    Those are effects of the Industrial Revolution, which led to the current climatic challenge. What a success!
    - darkerside 5y ago
      He typed smugly on his smartphone before hitting Send with a flourish
      - Dudeman112 5y ago
        As opposed to the humble hermits who reject modern technology and will still suffer from the climate change shitshow?
      - natmaka 5y ago
        I don't pretend to be strong enough to live autonomously.
    - doshaa 5y ago
      Thats irrelevant.
      - natmaka 5y ago
        How, why?
Scarblac 5y ago
Another problem is that once that leader and initial team leave for another job, they can be extremely hard to replace. You may start with the first but the second seems kind of inevitable after some years.

by netfl0 5y ago

neandrake 5y ago

This has been my experience, along with most great product leaders I’ve known have been “promoted” from developers/engineering as opposed to from the business end. Most devs/engineers I know also don’t want to take on this responsibility because they would rather be developing rather than overseeing product development.

MattGaiser 5y ago
I find that it is enough to have an engineering background. Someone who grasps why simply adding a new button on the frontend might require a week of backend work because of prior decisions.
datavirtue 5y ago
I would love this role and have had the chance to act in it. I'm quite adept at it but I do not want to be thrown into a business or domain that I don't know. It's like asking me to invest in a company or industry that I'm not an expert at. I need to be a a dev that just crushes stories for a while so that I can observe and learn about the business. I can sense the fear and imposter syndrome in people who have never been a dev and who don't really know the business. They are dead weight, and nobody wants to be dead weight.

topspin 5y ago

> A team with a strong product leader I think the problem begins before the 'leader.' The product itself dictates all the downstream consequences, including whether 'requirements' are a problem. Assuming no fatal management dysfunction, when you're working on a product that has substantial value, enough that the customer is eager to pay for what you're capable of delivering, requirements are straightforward. When you're working on things of low value and the customer won't pay unless they get an ever more improbable gymnastics routine and every tier of stake holder is lying to the other then you starting hearing about 'requirements' problems. The 'requirements' problem severity is a function of where you are on on the continuum between these two products.

mason55 5y ago
Depends what you’re trying to build. Sure, if you’re just doing consulting work then go get requirements from a customer and deliver on them. If you’re building a real product there’s frequently not even an existing customer and certainly none to “give you requirements”. You need to understand problems to solve and turn those into requirements for a product and if you can do that then you’re not working at a customer giving requirements to a vendor.
- bluGill 5y ago
  Even when you get requirements beware that the customer doesn't know what they want. So you get asked to make a faster horse instead of invent the car.
- mdaniel 5y ago
  > You need to understand problems to solve and turn those into requirements for a product One subtly for me is that what you said is 100% true of the parts of the organization which interact with customers, or even design partners who want to become customers. But since not every member of engineering is in that role, the requirements which come back from those meetings still need to be "MVP accurate" and (IMHO) need to specify just as much what it *won't* do as what it needs to do For example, "customer wants to query for names" is a shitty requirement. Of course they do, we all want search engines for everything, but that's not how software works. Do they want it case sensitive, case insensitive, the ability to indicate by using special search syntax (like "quoted"), do they want "starts with" or "contains" searches, wildcard characters? Getting to MVP means not building the wrong or extraneous things just as much as building the right things, and only a handful of people bear responsibility for distinguishing between those sets
deleted 5y ago
[deleted]
bcrosby95 5y ago
Just because someone can pay for a requirement doesn't mean that requirement adds value to a product. If I think the cost for a requirement is higher than its value - which may potentially even be negative - I'm going to present my case for stripping it out.

natmaka 5y ago

Exactly, and in 3 decades of activity I didn't encounter a single counter-example. > The problem is that it is hard to scale. This is true for everything involving human beings.

njharman 5y ago
Tons of human things have been scaled. Agriculture, retail, manufacturing, soildering, …
- natmaka 5y ago
  Those are effects of the Industrial Revolution, which led to the current climatic challenge. What a success!
  - darkerside 5y ago
    He typed smugly on his smartphone before hitting Send with a flourish
    - Dudeman112 5y ago
      As opposed to the humble hermits who reject modern technology and will still suffer from the climate change shitshow?
    - natmaka 5y ago
      I don't pretend to be strong enough to live autonomously.
  - doshaa 5y ago
    Thats irrelevant.
    - natmaka 5y ago
      How, why?

Scarblac 5y ago

Another problem is that once that leader and initial team leave for another job, they can be extremely hard to replace. You may start with the first but the second seems kind of inevitable after some years.