4 ms·

I think we need to develop a notion of 2 sided value: there is value in delivering additional profit/revenue, but there's also value in reducing costs. Creating

I think we need to develop a notion of 2 sided value: there is value in delivering additional profit/revenue, but there's also value in reducing costs. Creating reusable knowledge is an example of reducing (the expected) cost.

kqr 5y ago
Correct. The Ward approach to product development accounts for this. He suggests that the organisation structure should reflect that tension. Here's how: Functional departments and their managers are responsible for creating reusable knowledge. A project leader (chief engineer, in Toyota speak) is responsible for delivering value in a particular project. The project leader accomplishes their goals by help from the functional departments. However, the project leader has no formal authority over the engineers in the functional departments. In other words, there will be a constant negotiation between the project leader who argues for something to be designed for a project, and the functional department which must be convinced it's worth spending time to do that thing. The way a Toyota executive put it was "A great car is made from lots of conflict". I'm not doing this approach justice in my description. I suggest just reading Lean Product and Process Development by Allen Ward. Lots of good ideas in it.
- lifeisstillgood 5y ago
  The organisation structure of a car maker can be seen in a car dashboard. There is a light for the tyre pressure gauge because there is a business function for "tyres". Changing that is hard. Tesla has a screen where software decides what lights to flash - and dollars to doughnuts it's because there was not dozens of decades old business departments fighting to keep control. And the example you have above - a Product manager persuading functional teams is a separation of powers problem - think of the US government as a surprisingly long lived example One would need a lot of top management support to keep that from falling into one of two more stable systems - either the functional team leader tells the PMs what they are going to ask for, or the PMs get hold of budgetary control Either way the conflict is resolved.
ChrisMarshallNY 5y ago
I was just pontif- er...talking about this, yesterday. I am not a fan of the "MVP" concept, as it is defined in the software startup industry. I feel that it delivers time-delay disasters. Mostly, because of the deliberate, and premeditated, willingness to ablate Quality, in a drive for deliverable. We get bad stuff, fast. All too often, that bad stuff forms the nucleus of the product, for the rest of its lifetime. Basically, a foundation of sand. It's hard to argue against the "dollars and cents" rationale for it. People make money, this way; lots of money. As long as money and profit are the main measure of success (and it can be argued that they are the only ones that matter), we will have this drive to deprecate Quality, in favor of profit. Quality is expensive. Real expensive. I've talked about this before. But I've worked for hardware companies, for most of my life, and it's fairly rare, when hardware companies can get away with it; often, because laws and regulations. Also, tooling up a product line is a major commitment. You really don't want to cheap out on that. Distribution channels are also some heavy-duty overhead. For whatever reason, software shops believe that we are exempt from the restrictions that have governed all engineering; throughout history. In a way, this is true. Software is not hardware, and requires a drastically different approach. I always had a devil of a time, convincing hardware people of this. On the other hand, I don't like the idea that we are also exempt from the requirement to deliver a baseline level of Quality. Personal gripe. I'm an old curmudgeon.
- kqr 5y ago
  This is an all too common misunderstanding of what an MVP is. A bad MVP is a bunch of features thrown together badly in the hopes that parts of it will match market demand and that the market is willing to look past the quality problems. What follows after moderate success with this approach is a long journey to try to build back in some of the quality that was avoided at the start. The end is predictable: sprawling, mediocre software. With some luck it makes money. Often it does not. A good MVP delivers a single, deliberately chosen feature to a well-researched segment of the market. This single feature has excellent quality characteristics and blows any competition out of the water. On that success follows continued incremental, high-speed development, always with quality as a primary driver. But it takes discipline. In order to economically deliver quality, you must do the research, and you must be willing to deliver in really small, very well chosen increments. And that is hard. That takes excellent developers. It's easier to just throw something together and hope to get lucky.

kqr 5y ago

Correct. The Ward approach to product development accounts for this. He suggests that the organisation structure should reflect that tension. Here's how: Functional departments and their managers are responsible for creating reusable knowledge. A project leader (chief engineer, in Toyota speak) is responsible for delivering value in a particular project. The project leader accomplishes their goals by help from the functional departments. However, the project leader has no formal authority over the engineers in the functional departments. In other words, there will be a constant negotiation between the project leader who argues for something to be designed for a project, and the functional department which must be convinced it's worth spending time to do that thing. The way a Toyota executive put it was "A great car is made from lots of conflict". I'm not doing this approach justice in my description. I suggest just reading Lean Product and Process Development by Allen Ward. Lots of good ideas in it.

lifeisstillgood 5y ago
The organisation structure of a car maker can be seen in a car dashboard. There is a light for the tyre pressure gauge because there is a business function for "tyres". Changing that is hard. Tesla has a screen where software decides what lights to flash - and dollars to doughnuts it's because there was not dozens of decades old business departments fighting to keep control. And the example you have above - a Product manager persuading functional teams is a separation of powers problem - think of the US government as a surprisingly long lived example One would need a lot of top management support to keep that from falling into one of two more stable systems - either the functional team leader tells the PMs what they are going to ask for, or the PMs get hold of budgetary control Either way the conflict is resolved.

ChrisMarshallNY 5y ago

I was just pontif- er...talking about this, yesterday. I am not a fan of the "MVP" concept, as it is defined in the software startup industry. I feel that it delivers time-delay disasters. Mostly, because of the deliberate, and premeditated, willingness to ablate Quality, in a drive for deliverable. We get bad stuff, fast. All too often, that bad stuff forms the nucleus of the product, for the rest of its lifetime. Basically, a foundation of sand. It's hard to argue against the "dollars and cents" rationale for it. People make money, this way; lots of money. As long as money and profit are the main measure of success (and it can be argued that they are the only ones that matter), we will have this drive to deprecate Quality, in favor of profit. Quality is expensive. Real expensive. I've talked about this before. But I've worked for hardware companies, for most of my life, and it's fairly rare, when hardware companies can get away with it; often, because laws and regulations. Also, tooling up a product line is a major commitment. You really don't want to cheap out on that. Distribution channels are also some heavy-duty overhead. For whatever reason, software shops believe that we are exempt from the restrictions that have governed all engineering; throughout history. In a way, this is true. Software is not hardware, and requires a drastically different approach. I always had a devil of a time, convincing hardware people of this. On the other hand, I don't like the idea that we are also exempt from the requirement to deliver a baseline level of Quality. Personal gripe. I'm an old curmudgeon.

kqr 5y ago
This is an all too common misunderstanding of what an MVP is. A bad MVP is a bunch of features thrown together badly in the hopes that parts of it will match market demand and that the market is willing to look past the quality problems. What follows after moderate success with this approach is a long journey to try to build back in some of the quality that was avoided at the start. The end is predictable: sprawling, mediocre software. With some luck it makes money. Often it does not. A good MVP delivers a single, deliberately chosen feature to a well-researched segment of the market. This single feature has excellent quality characteristics and blows any competition out of the water. On that success follows continued incremental, high-speed development, always with quality as a primary driver. But it takes discipline. In order to economically deliver quality, you must do the research, and you must be willing to deliver in really small, very well chosen increments. And that is hard. That takes excellent developers. It's easier to just throw something together and hope to get lucky.