5 ms·

I don't actually understand what's bad about this, maybe someone who is in a company like this can explain why it's a negative? I am working with a company that

by davzie 7y ago

I don't actually understand what's bad about this, maybe someone who is in a company like this can explain why it's a negative? I am working with a company that is moving more towards this approach and I'm really enjoying it. Isn't this essentially what Basecamp's Shape Up method advocates for? Not everyone feels they need to be building something that changes the world I suppose. Each to their own.

SpicyLemonZest 7y ago
The problem is that, if you're churning out features without thinking critically about why, your work might not even change the company. I've seen engineers, teams, even entire departments spend multiple quarters being a net drain on the company. But they never noticed, because they kept consistently defining release targets and hitting them.
- lazyjones 7y ago
  > churning out features without thinking critically about why, your work might not even change the company Isn't this just speculation? Why would anyone build features without any thoughts about their benefit? In practice you never know how a feature is going to work out and benefit or harm the company, you just have to try it. Not trying is a sure way to lose to bolder competition.
  - SpicyLemonZest 7y ago
    There are a couple reasons I've seen why you'd do that. I'm sure there are others I haven't seen. * Sometimes companies have declared focus areas, and it's advantageous to be working in those areas. If the CEO says Project Foobar is going to be the next big thing, you want your team to be touching Project Foobar even if you have nothing valuable to contribute. * Some kinds of projects are costly to push back on. If someone comes to you and says "this is a security feature, I'm going to build it to increase security", you have to demonstrate that the system is secure without it and not just tell them no. * In some environments, people are measured by their ability to produce lots of features. This makes it embarrassing and politically damaging to not do a feature you proposed. So once it's publicly known that you have a feature, it's too late to think about whether it's useful, you have to just buckle down and do it.
  - dillonmckay 7y ago
    I strongly disagree with this sentiment. I’ve seen quite a few features added simply ‘because we can’, without any thought to ongoing maintenance, support, or additional infrastructure requirements/costs. A little bit of common sense and forethought can go a long way in preventing unprofitable or revenue-decreasing features from being added to the product. If you keep adding features, without increasing your conversion rate or user revenue, you are simply decreasing your profitability. Death by a thousand cuts.
    - lazyjones 7y ago
      You are basing your sentiment on assumptions that cannot be verified in practice without implementing/releasing the features. Nobody wants to implement revenue-decreasing feature but nobody knows beforehand whether they will increase or decrease revenue. So such statements are useless.
      - dillonmckay 7y ago
        This is not accurate at all. Approximate costs can be estimated before hand. You can even ask the customer if they are willing to pay a specific amount for the feature. But, insisting you have to build and deploy a feature first, before you have any idea of its impact, that is, an expensive, and foolish way to learn.
      - joegahona 7y ago
        There are lots of ways to test and to map potential features to customer problems. Launching features because _you_ think they’ll resonate with users is a complete crapshoot. More often than not, people inside the company are way too close to the product to be able to determine which features are the right ones. I recommend “The Right It” by Alberto Savoia, “What Customers Want” by Tony Ulwick, and “The Lean Product Playbook” by Dan Olsen if Cutler’s essay doesn’t convince you.
  - s_y_n_t_a_x 7y ago
    > Why would anyone build features without any thoughts about their benefit? > In practice you never know how a feature is going to work out Those two sentences are somewhat contradictory. If you think through the features you should know exactly how they further your initial goal. When you add things based on what some people might like, that's when you are guessing and you can't know. This all boils down to having or not having a vision. Some leaders have a vision and you can see the long-term goals, others (like Google) throw things at the wall to see what sticks then shuts them down. If you're not a monopoly, that strategy will not work.
    - lazyjones 7y ago
      Google certainly had visions for all their products. They just didn't work out, for reasons that became apparent much later (although some people will always claim they "knew" beforehand).
      - s_y_n_t_a_x 7y ago
        Those visions are not long term goals. They are spin-offs that have nothing to do with anything. That's how you end up with: https://gcemetery.co/ https://gcemetery.co/
        loopz 7y ago
        That's the whole point of agility: Release working software often. Make new business decisions based on customer feedback. Remember Google Beta? Not saying it doesn't offload responsibility and potential damage to end users..
        s_y_n_t_a_x 7y ago
        No that's not the point. The point of agile development is not to get stuck in the water with long releases and no feedback cycle. It doesn't mean you blindly follow customer feedback and guesses until something works. It means you incrementally release your vision. tldr: agile tells you how to release, not what to release
  - enjo 7y ago
    There are lots of bad actor reasons (putting career advancement ahead of product success), but there also structural issues that can lead teams to operate this way. The most common: product decisions are made higher up by well intentioned leaders who lack the product management expertise and the context the team does. Usually this looks something like a sales person hearing from a couple of customers “we really need feature X”. The sales person doesn’t ask what actual problem they’re trying to solve but instead reports back “the market is telling me we need X!!”. An executive picks this up, writes a business case, and then hands a solution (build X) instead of the problem (our customers are struggling with Y) to a product manager. That PM is no longer really empowered to think about the overall outcomes but rather is tasked with discovering requirements and then project managing the feature through. At some companies this is how all product decisions are made. It’s not that there is no thought about benefit, it’s that the wrong people are the ones doing the thinking and as a result you end up with teams who spends years never delivering anything actually valuable to their users.
    - BlueTemplar 7y ago
      I hear that these situations exist, yet this is the complete opposite of what I was taught, which is that (at least !) the project manager had to have frequent and direct contact with the customers starting from trying to figure out what their real needs are - for the project to have any hope to succeed?
      - loopz 7y ago
        In software/tech world, PM's customer are often internal stakeholders, often not all relevant ones. Very rarely company's customer. PM juggles internal issues like milestones, priority, resources, budgets and even some politics.
        tomaskafka 7y ago
        Yes. This is a redefinition of a role though, this should be called Project manager.
richie5um 7y ago
I think the high-level summary of the article is ‘fire-and-forget development’ - ie producing features, but not measuring impact/benefit/usage. I’m not convinced ‘feature factory’ in itself is problematic (definition not provided). There is no problem (IMO) in optimising to ship features - as long as the overall approach is to measure impact/benefit/usage and then learn and iterate.
- dillonmckay 7y ago
  I beliece the issue the article is attempting to convey is that a preponderance of these ‘symptoms’ indicates a lack of optimization, and a failure or refusal to measure the impact.
gjhr 7y ago
A combination of sign 3, 8 and 12 can be awful. The features that are shipped are half-baked, teams always say that they will come back and refactor it but of course never do. Developers start to care less and less about quality because that isn't what gets rewarded. Feature ship rates go up in the short term but in the long term slow down as the spaghetti gets worse and worse. Good developers either see what is happening and jump ship or just get bored and leave.
praptak 7y ago
There is a danger of a useless product which has 120 features.
wefarrell 7y ago
More features mean a more complex system, which takes more effort to maintain and adapt than a simpler system. So if you're not measuring and constantly reevaluating the value of your features you can wind up with parts of your product that cost the company far more than they are worth.
UK-Al05 7y ago
This is about making teams completely responsible for the product as you possibly can. Maybe even profit/loss responsibility. The idea being they're closer to product then anyone, and thus should make better decisions. If you follow the feature factory route, the team will just produce things they are told too. If it doesn't work, it's not the teams responsibility. They did what they were told to.
- loopz 7y ago
  This is pinnacle of old style dev. It just doesn't make much sense unless devs become stakeholders.
  - UK-Al05 7y ago
    Devs are stakeholders in a project by definition. Stakeholder is anyone with an interest in a project.
- wruza 7y ago
  Otoh, those who “tell” are closer to the business/client, and thus should issue better requirements. I honestly can’t see what’s wrong with doing what you’re told to. You cannot play a jack of all trades and program the damn thing perfectly at the same time. (And if you can, you should not waste your time bringing profits to that Corporate, Inc anyway.)
  - UK-Al05 7y ago
    Teams that take ownership have a product person, who sits with the team. And is part of the team. Their entire job is work out the best product direction. They interact, sit with, pair, answer questions from developers everyday, talk to customers etc. Work with the team to set future product direction. It shouldn't be external group pushing features into a team backlog. Devs talk to customers, look at the logs, debug issues, look at the stats being logged out. As result they have far better understanding of product usage than most people higher up.
mobjack 7y ago
It is bad if you don't properly measure the impact of the features. There are some features that seem like obvious wins on paper but actually do worse when you A/B test it. They hurt business value and add needless complexity to the development process.

by davzie 7y ago

SpicyLemonZest 7y ago

The problem is that, if you're churning out features without thinking critically about why, your work might not even change the company. I've seen engineers, teams, even entire departments spend multiple quarters being a net drain on the company. But they never noticed, because they kept consistently defining release targets and hitting them.

lazyjones 7y ago
> churning out features without thinking critically about why, your work might not even change the company Isn't this just speculation? Why would anyone build features without any thoughts about their benefit? In practice you never know how a feature is going to work out and benefit or harm the company, you just have to try it. Not trying is a sure way to lose to bolder competition.
- SpicyLemonZest 7y ago
  There are a couple reasons I've seen why you'd do that. I'm sure there are others I haven't seen. * Sometimes companies have declared focus areas, and it's advantageous to be working in those areas. If the CEO says Project Foobar is going to be the next big thing, you want your team to be touching Project Foobar even if you have nothing valuable to contribute. * Some kinds of projects are costly to push back on. If someone comes to you and says "this is a security feature, I'm going to build it to increase security", you have to demonstrate that the system is secure without it and not just tell them no. * In some environments, people are measured by their ability to produce lots of features. This makes it embarrassing and politically damaging to not do a feature you proposed. So once it's publicly known that you have a feature, it's too late to think about whether it's useful, you have to just buckle down and do it.
- dillonmckay 7y ago
  I strongly disagree with this sentiment. I’ve seen quite a few features added simply ‘because we can’, without any thought to ongoing maintenance, support, or additional infrastructure requirements/costs. A little bit of common sense and forethought can go a long way in preventing unprofitable or revenue-decreasing features from being added to the product. If you keep adding features, without increasing your conversion rate or user revenue, you are simply decreasing your profitability. Death by a thousand cuts.
  - lazyjones 7y ago
    You are basing your sentiment on assumptions that cannot be verified in practice without implementing/releasing the features. Nobody wants to implement revenue-decreasing feature but nobody knows beforehand whether they will increase or decrease revenue. So such statements are useless.
    - dillonmckay 7y ago
      This is not accurate at all. Approximate costs can be estimated before hand. You can even ask the customer if they are willing to pay a specific amount for the feature. But, insisting you have to build and deploy a feature first, before you have any idea of its impact, that is, an expensive, and foolish way to learn.
    - joegahona 7y ago
      There are lots of ways to test and to map potential features to customer problems. Launching features because _you_ think they’ll resonate with users is a complete crapshoot. More often than not, people inside the company are way too close to the product to be able to determine which features are the right ones. I recommend “The Right It” by Alberto Savoia, “What Customers Want” by Tony Ulwick, and “The Lean Product Playbook” by Dan Olsen if Cutler’s essay doesn’t convince you.
- s_y_n_t_a_x 7y ago
  > Why would anyone build features without any thoughts about their benefit? > In practice you never know how a feature is going to work out Those two sentences are somewhat contradictory. If you think through the features you should know exactly how they further your initial goal. When you add things based on what some people might like, that's when you are guessing and you can't know. This all boils down to having or not having a vision. Some leaders have a vision and you can see the long-term goals, others (like Google) throw things at the wall to see what sticks then shuts them down. If you're not a monopoly, that strategy will not work.
  - lazyjones 7y ago
    Google certainly had visions for all their products. They just didn't work out, for reasons that became apparent much later (although some people will always claim they "knew" beforehand).
    - s_y_n_t_a_x 7y ago
      Those visions are not long term goals. They are spin-offs that have nothing to do with anything. That's how you end up with: https://gcemetery.co/ https://gcemetery.co/
      - loopz 7y ago
        That's the whole point of agility: Release working software often. Make new business decisions based on customer feedback. Remember Google Beta? Not saying it doesn't offload responsibility and potential damage to end users..
        s_y_n_t_a_x 7y ago
        No that's not the point. The point of agile development is not to get stuck in the water with long releases and no feedback cycle. It doesn't mean you blindly follow customer feedback and guesses until something works. It means you incrementally release your vision. tldr: agile tells you how to release, not what to release
- enjo 7y ago
  There are lots of bad actor reasons (putting career advancement ahead of product success), but there also structural issues that can lead teams to operate this way. The most common: product decisions are made higher up by well intentioned leaders who lack the product management expertise and the context the team does. Usually this looks something like a sales person hearing from a couple of customers “we really need feature X”. The sales person doesn’t ask what actual problem they’re trying to solve but instead reports back “the market is telling me we need X!!”. An executive picks this up, writes a business case, and then hands a solution (build X) instead of the problem (our customers are struggling with Y) to a product manager. That PM is no longer really empowered to think about the overall outcomes but rather is tasked with discovering requirements and then project managing the feature through. At some companies this is how all product decisions are made. It’s not that there is no thought about benefit, it’s that the wrong people are the ones doing the thinking and as a result you end up with teams who spends years never delivering anything actually valuable to their users.
  - BlueTemplar 7y ago
    I hear that these situations exist, yet this is the complete opposite of what I was taught, which is that (at least !) the project manager had to have frequent and direct contact with the customers starting from trying to figure out what their real needs are - for the project to have any hope to succeed?
    - loopz 7y ago
      In software/tech world, PM's customer are often internal stakeholders, often not all relevant ones. Very rarely company's customer. PM juggles internal issues like milestones, priority, resources, budgets and even some politics.
      - tomaskafka 7y ago
        Yes. This is a redefinition of a role though, this should be called Project manager.

richie5um 7y ago

I think the high-level summary of the article is ‘fire-and-forget development’ - ie producing features, but not measuring impact/benefit/usage. I’m not convinced ‘feature factory’ in itself is problematic (definition not provided). There is no problem (IMO) in optimising to ship features - as long as the overall approach is to measure impact/benefit/usage and then learn and iterate.

dillonmckay 7y ago
I beliece the issue the article is attempting to convey is that a preponderance of these ‘symptoms’ indicates a lack of optimization, and a failure or refusal to measure the impact.

gjhr 7y ago

A combination of sign 3, 8 and 12 can be awful. The features that are shipped are half-baked, teams always say that they will come back and refactor it but of course never do. Developers start to care less and less about quality because that isn't what gets rewarded. Feature ship rates go up in the short term but in the long term slow down as the spaghetti gets worse and worse. Good developers either see what is happening and jump ship or just get bored and leave.

praptak 7y ago

There is a danger of a useless product which has 120 features.

wefarrell 7y ago

More features mean a more complex system, which takes more effort to maintain and adapt than a simpler system. So if you're not measuring and constantly reevaluating the value of your features you can wind up with parts of your product that cost the company far more than they are worth.

UK-Al05 7y ago

This is about making teams completely responsible for the product as you possibly can. Maybe even profit/loss responsibility. The idea being they're closer to product then anyone, and thus should make better decisions. If you follow the feature factory route, the team will just produce things they are told too. If it doesn't work, it's not the teams responsibility. They did what they were told to.

loopz 7y ago
This is pinnacle of old style dev. It just doesn't make much sense unless devs become stakeholders.
- UK-Al05 7y ago
  Devs are stakeholders in a project by definition. Stakeholder is anyone with an interest in a project.
wruza 7y ago
Otoh, those who “tell” are closer to the business/client, and thus should issue better requirements. I honestly can’t see what’s wrong with doing what you’re told to. You cannot play a jack of all trades and program the damn thing perfectly at the same time. (And if you can, you should not waste your time bringing profits to that Corporate, Inc anyway.)
- UK-Al05 7y ago
  Teams that take ownership have a product person, who sits with the team. And is part of the team. Their entire job is work out the best product direction. They interact, sit with, pair, answer questions from developers everyday, talk to customers etc. Work with the team to set future product direction. It shouldn't be external group pushing features into a team backlog. Devs talk to customers, look at the logs, debug issues, look at the stats being logged out. As result they have far better understanding of product usage than most people higher up.

mobjack 7y ago

It is bad if you don't properly measure the impact of the features. There are some features that seem like obvious wins on paper but actually do worse when you A/B test it. They hurt business value and add needless complexity to the development process.