7 ms·

Products Over Projects

256 points by kawera 9y ago

skybrian 9y ago
The opposite of this would be "build it to walk away." It's not obvious that every project worth writing some custom software for is worth having a dedicated team working on it. You need to think seriously about how to avoid changing dependencies, though. It's like planning an exercise in retrocomputing in advance.
- konschubert 9y ago
  1. Create a team to build a product and maintain it. 2. Once the product matures, and needs less attention, shrink the team or use the free capacity to build another product and add it to the team's portfolio. 3. If at any point in time the workload becomes to much, grow the team. 4. If the team gets too big, split it and distribute the product portfolio onto the two parts.
- mr_toad 9y ago
  In my experience, most software development projects have been more like "build half of it, throw it over the wall, and make yourself scarce." Especially when consultants are involved. I have never seen traditional project management techniques successfully applied to software.
  - pjmlp 9y ago
    I used to think like that, then I became a consultant and got to enjoy how companies whose main business is not at all related to IT do work. 100% of them don't care about code beauty or maintainability, just something that does what they need for their actual business, done in X days within Y euros/dollars/yang/.... So they get what they want, with the quality they are willing to pay for.
    - tonyedgecombe 9y ago
      Yes, it's hard to underestimate how poor most corporate software is.
brucephillips 9y ago
This should be called "problem-mode", not "product-mode". The distinguishing feature is that teams continuously work to solve a problem. This doesn't end when the product is finished.
- confounded 9y ago
  Software products are never finished.
  - rubidium 9y ago
    neither are houses or humans or science or forests or roads or hardware products or butterflies .... til they die at least.
  - hinkley 9y ago
    A software project is done when no one is willing to work on it anymore. - my third boss
cateye 9y ago
It doesn't take the contradicting interests in to account. People in IT should really stop to pretend that they are the only smart people that know how to run a business. A cfo can easily understand the benefits of an organizational capability to continuously improve a core business asset. But he also understands the difference between capex and opex and needs to take decisions in order to achieve the strategic goals of the company. This strategy can or can not define software development (for a specific goal) as a core in house capability that gets an investment. This relates also heavily with the defined core business etc. Without understanding the long term strategy of a company, it does not make a lot of sense to come up with generic advice. The ceo and the management board do generally (almost intuitively) understand which activities will generate competitive advantage. If they are not in the silicon valley hype, this can mean that they can make a deliberate choice to invest in other things than software teams. Is it really that unthinkable that other things than software can bring value to a company? Do all companies need to act like Google or Facebook? >>for greater responsiveness and a higher benefits realization ratio, “product-mode” is a more effective way of working than projects. This is a sweeping statement. This could definitely lead to higher benefits and lower responsibility for the consulting company. That is almost for sure. But that doesn't mean that a short living project organization is a bad idea by default. The choice needs a much more substantial argument like the probability of a positive realization result (depending on the complexity and uniqueness of the software) versus risk if it does not get realized etc. If it can't be bought of the shelf, it can be outsourced or developed entirely in house by long term perm employees... >>it may feel unsound to those who are used to approving big change programs with detailed roadmap... If a project can be predicted by a high enough level of certainty, I would say that there is nothing wrong with a detailed roadmap. Also here, a false dichotomy.
- bonaldi 9y ago
  >If a project can be predicted by a high enough level of certainty, I would say that there is nothing wrong with a detailed roadmap. Also here, a false dichotomy. In large orgs, roadmaps come to be depended upon by stakeholders and other internal dependencies, who immediately base their roadmaps and thinking around yours. That means the cost of changing something on yours quickly mounts — it's no longer a matter of hoping your boss is flexible enough, almost your entire org has to be able to cope with a massive re-roadmapping exercise as the changes cascade through dependencies. Sure, you said 'high enough level of certainty'. And that's fine for building bridges. Less so software. Not least because it needlessly constrains innovation. If a team comes up with a better idea part-way through building something that's on a published roadmap, what does it do? Change the roadmap and cause all the upheaval above? Try and hit the original date even by starting over on the new idea? Or just plough on building what it now knows is a less-than-best idea? I've seen teams do each of these things, and cause needless misery, all because of unnecessary roadmapping. It's such a seemingly innocuous request — "what things are you working on this year and what dates will we get them?" — yet answering it (as asked) can have dramatically outsized repercussions.
mannykannot 9y ago
It is ironic that, right now, we are in the midst of an event that shows this to be a false dichotomy, and that projects and products can be cross-cutting concerns. I am, of course, referring to the multi-product project of dealing with Meltdown and Spectre.
dboreham 9y ago
I'm not sure much can be done about this. It is what it is. Some organizations can afford to maintain an "A-team" to crunch through their problems with a good folk-memory. Other organizations can't. In addition the first kind of organization often needs something done pronto, ahead of when the A-team can get to it.
doug1001 9y ago
i would think Martin Fowler would know better than this. to argue that the meaningful rubric of effort ought to be a "product", he creates a straw-man called a "project" the much more meaningful comparison is to compare products versus "platforms" and "tools/infrastructure" if he had done that, then he i bet that he would conclude that all three rubrics of effort are necessary, and preferring one vs the other is a question of priority, not "do one instead of the other" ie: some things you built to sell; other things you build so you can build those things better and more efficiently; and still others you build for use as reusable or modular components across multiple future products, so you don't have to build the same component over again for each product that requires it "tools", eg: the 250-developer-hours spent on a "project" to create an automated testing & deployment pipeline, will likely net out in a few months and result in higher quality products almost immediately "platform": a "project" to factor out code common across many workflows in a typical web app, and re-implement that code as microservices having endpoints available to any of the multiple data flows that need them (for instance, "user-login & authentication", "user-profile fetch", "re-ordering user-search results using learning-to-rank algorithm" etc a project to build such reusable utility micro-services obviously don't result in a "product", and yet such a project is usually cost-justified (in CFO terms) even over short-term periods (< 90 days)
- pjmlp 9y ago
  Those 250 hours need to be payed by someone, which at an hourly rate of 100 euros, pretty average for some consulting gigs, gets us 25k euros. Who is going to pay them and how to validate how much money would have been saved, if those 25k euros hadn't been spent? Edit: should learn math. :)
  - oatmale 9y ago
    that would make it 25k not 250k
    - pjmlp 9y ago
      Thanks.
mikekchar 9y ago
I have found that what is important for a software team is having members that can work well together. It takes time to make such a team and some people can never work well together. Organisations should spend considerable effort building and maintaining effective teams. I am often surprised at how poorly this is understood. Technology also takes time to understand and be effective with. A good team can usually work on anything and still be a good team, given that they have enough time to ramp up, though. My personal feeling: build strong teams. Ignore technology for the most part. Put all your effort into getting people who work well together, working together. Allocate time and money into making sure that the team has time to gel and that they have the resources (tools, equipment, and working environment) that they need (hint: each team requires different resources. Think hard about what each individual team needs). After that you have choices. Keeping a team on a single "product" eliminates ramp up time. On the other hand, it also leads to singular ways of thinking and silos. If you have a "product" that absolutely needs responsive development all the time, then consider having a "product" team. On the other hand, not everything requires instantaneous response. A good team will usually be able to ramp up to very near full speed in about 3-4 months. For some things, that is completely reasonable. You have to consider the cost of maintaining a "product team" vs the cost of ramping up a "project team". The advantage of the "project team" is that a new team can often come in with new ideas that will improve the project. Moving project teams around from time to time can ensure that teams are exposed to other ways of thinking and this can help your organisation. The advantages and disadvantages are not necessarily obvious.
deleted 9y ago
[deleted]
gcb0 9y ago
both are already the norm on bigger companies. the money making products have product teams, pumping billions every year while handling tons of incidents and stress. the new initiatives have project teams. burning millions while having a coin flip chance of success and getting every promotions and bonuses.
baxtr 9y ago
I find it interesting to observe that Apple - THE product company - works in project mode. Apple is mainly organized by function. Presumably to avoid product silos
- tensor 9y ago
  My impression is that Apple works in project mode only for building a new project, not improving existing ones. The reason quoted for this was secrecy, not breaking down silos. Where did you read that they work in project mode more widely?
  - baxtr 9y ago
    This is what I assume reading articles like [1]. Obviously, there is no direct product P&L responsibility [1] https://stratechery.com/2016/apples-organizational-crossroads/ https://stratechery.com/2016/apples-organizational-crossroad...
gadders 9y ago
Working in big orgs, I've seen before the problems that too extreme a project mentality can cause. Developers who move on to the next project on another system losing institutional knowledge, systems left to "rot" because no-one has budget to fix them or keep them up-to-date. However, what they are describing is really a series of projects with the same team on the same system or "product". I think there are advantages to both ways of working, but the appropriate one needs to be chosen.
HeroOfAges 9y ago
I'd like to see more organizations adapt this way of thinking in terms of the way they build software. Turns out business functionality is a great way to define boundaries for a service in a micro-service architecture. There's really no reason why the application code that gets a list of book recommendations (functionality provided by the business) can't be completely separate from the code that provides the user with a bio for an author (functionality provided by the business), or ratings for a book. This allows teams to work independently and in parallel. Organizing software development around projects makes it more difficult for software developers to leverage tools for continuous delivery and deployment. Project based development really does slow you down. Hmm... I guess my way would be to have teams that work together to deliver business functionality over products or projects. Functional teams, if you will. I see thinking in terms of products as a step in that direction. *edited to clarify my earlier statement

256 points by kawera 9y ago

The opposite of this would be "build it to walk away." It's not obvious that every project worth writing some custom software for is worth having a dedicated team working on it. You need to think seriously about how to avoid changing dependencies, though. It's like planning an exercise in retrocomputing in advance.

konschubert 9y ago
1. Create a team to build a product and maintain it. 2. Once the product matures, and needs less attention, shrink the team or use the free capacity to build another product and add it to the team's portfolio. 3. If at any point in time the workload becomes to much, grow the team. 4. If the team gets too big, split it and distribute the product portfolio onto the two parts.
mr_toad 9y ago
In my experience, most software development projects have been more like "build half of it, throw it over the wall, and make yourself scarce." Especially when consultants are involved. I have never seen traditional project management techniques successfully applied to software.
- pjmlp 9y ago
  I used to think like that, then I became a consultant and got to enjoy how companies whose main business is not at all related to IT do work. 100% of them don't care about code beauty or maintainability, just something that does what they need for their actual business, done in X days within Y euros/dollars/yang/.... So they get what they want, with the quality they are willing to pay for.
  - tonyedgecombe 9y ago
    Yes, it's hard to underestimate how poor most corporate software is.

brucephillips 9y ago

This should be called "problem-mode", not "product-mode". The distinguishing feature is that teams continuously work to solve a problem. This doesn't end when the product is finished.

confounded 9y ago
Software products are never finished.
- rubidium 9y ago
  neither are houses or humans or science or forests or roads or hardware products or butterflies .... til they die at least.
- hinkley 9y ago
  A software project is done when no one is willing to work on it anymore. - my third boss

cateye 9y ago

It doesn't take the contradicting interests in to account. People in IT should really stop to pretend that they are the only smart people that know how to run a business. A cfo can easily understand the benefits of an organizational capability to continuously improve a core business asset. But he also understands the difference between capex and opex and needs to take decisions in order to achieve the strategic goals of the company. This strategy can or can not define software development (for a specific goal) as a core in house capability that gets an investment. This relates also heavily with the defined core business etc. Without understanding the long term strategy of a company, it does not make a lot of sense to come up with generic advice. The ceo and the management board do generally (almost intuitively) understand which activities will generate competitive advantage. If they are not in the silicon valley hype, this can mean that they can make a deliberate choice to invest in other things than software teams. Is it really that unthinkable that other things than software can bring value to a company? Do all companies need to act like Google or Facebook? >>for greater responsiveness and a higher benefits realization ratio, “product-mode” is a more effective way of working than projects. This is a sweeping statement. This could definitely lead to higher benefits and lower responsibility for the consulting company. That is almost for sure. But that doesn't mean that a short living project organization is a bad idea by default. The choice needs a much more substantial argument like the probability of a positive realization result (depending on the complexity and uniqueness of the software) versus risk if it does not get realized etc. If it can't be bought of the shelf, it can be outsourced or developed entirely in house by long term perm employees... >>it may feel unsound to those who are used to approving big change programs with detailed roadmap... If a project can be predicted by a high enough level of certainty, I would say that there is nothing wrong with a detailed roadmap. Also here, a false dichotomy.

bonaldi 9y ago
>If a project can be predicted by a high enough level of certainty, I would say that there is nothing wrong with a detailed roadmap. Also here, a false dichotomy. In large orgs, roadmaps come to be depended upon by stakeholders and other internal dependencies, who immediately base their roadmaps and thinking around yours. That means the cost of changing something on yours quickly mounts — it's no longer a matter of hoping your boss is flexible enough, almost your entire org has to be able to cope with a massive re-roadmapping exercise as the changes cascade through dependencies. Sure, you said 'high enough level of certainty'. And that's fine for building bridges. Less so software. Not least because it needlessly constrains innovation. If a team comes up with a better idea part-way through building something that's on a published roadmap, what does it do? Change the roadmap and cause all the upheaval above? Try and hit the original date even by starting over on the new idea? Or just plough on building what it now knows is a less-than-best idea? I've seen teams do each of these things, and cause needless misery, all because of unnecessary roadmapping. It's such a seemingly innocuous request — "what things are you working on this year and what dates will we get them?" — yet answering it (as asked) can have dramatically outsized repercussions.

mannykannot 9y ago

It is ironic that, right now, we are in the midst of an event that shows this to be a false dichotomy, and that projects and products can be cross-cutting concerns. I am, of course, referring to the multi-product project of dealing with Meltdown and Spectre.

dboreham 9y ago

I'm not sure much can be done about this. It is what it is. Some organizations can afford to maintain an "A-team" to crunch through their problems with a good folk-memory. Other organizations can't. In addition the first kind of organization often needs something done pronto, ahead of when the A-team can get to it.

doug1001 9y ago

i would think Martin Fowler would know better than this. to argue that the meaningful rubric of effort ought to be a "product", he creates a straw-man called a "project" the much more meaningful comparison is to compare products versus "platforms" and "tools/infrastructure" if he had done that, then he i bet that he would conclude that all three rubrics of effort are necessary, and preferring one vs the other is a question of priority, not "do one instead of the other" ie: some things you built to sell; other things you build so you can build those things better and more efficiently; and still others you build for use as reusable or modular components across multiple future products, so you don't have to build the same component over again for each product that requires it "tools", eg: the 250-developer-hours spent on a "project" to create an automated testing & deployment pipeline, will likely net out in a few months and result in higher quality products almost immediately "platform": a "project" to factor out code common across many workflows in a typical web app, and re-implement that code as microservices having endpoints available to any of the multiple data flows that need them (for instance, "user-login & authentication", "user-profile fetch", "re-ordering user-search results using learning-to-rank algorithm" etc a project to build such reusable utility micro-services obviously don't result in a "product", and yet such a project is usually cost-justified (in CFO terms) even over short-term periods (< 90 days)

pjmlp 9y ago
Those 250 hours need to be payed by someone, which at an hourly rate of 100 euros, pretty average for some consulting gigs, gets us 25k euros. Who is going to pay them and how to validate how much money would have been saved, if those 25k euros hadn't been spent? Edit: should learn math. :)
- oatmale 9y ago
  that would make it 25k not 250k
  - pjmlp 9y ago
    Thanks.

mikekchar 9y ago

I have found that what is important for a software team is having members that can work well together. It takes time to make such a team and some people can never work well together. Organisations should spend considerable effort building and maintaining effective teams. I am often surprised at how poorly this is understood. Technology also takes time to understand and be effective with. A good team can usually work on anything and still be a good team, given that they have enough time to ramp up, though. My personal feeling: build strong teams. Ignore technology for the most part. Put all your effort into getting people who work well together, working together. Allocate time and money into making sure that the team has time to gel and that they have the resources (tools, equipment, and working environment) that they need (hint: each team requires different resources. Think hard about what each individual team needs). After that you have choices. Keeping a team on a single "product" eliminates ramp up time. On the other hand, it also leads to singular ways of thinking and silos. If you have a "product" that absolutely needs responsive development all the time, then consider having a "product" team. On the other hand, not everything requires instantaneous response. A good team will usually be able to ramp up to very near full speed in about 3-4 months. For some things, that is completely reasonable. You have to consider the cost of maintaining a "product team" vs the cost of ramping up a "project team". The advantage of the "project team" is that a new team can often come in with new ideas that will improve the project. Moving project teams around from time to time can ensure that teams are exposed to other ways of thinking and this can help your organisation. The advantages and disadvantages are not necessarily obvious.

deleted 9y ago

[deleted]

gcb0 9y ago

both are already the norm on bigger companies. the money making products have product teams, pumping billions every year while handling tons of incidents and stress. the new initiatives have project teams. burning millions while having a coin flip chance of success and getting every promotions and bonuses.

baxtr 9y ago

I find it interesting to observe that Apple - THE product company - works in project mode. Apple is mainly organized by function. Presumably to avoid product silos

tensor 9y ago
My impression is that Apple works in project mode only for building a new project, not improving existing ones. The reason quoted for this was secrecy, not breaking down silos. Where did you read that they work in project mode more widely?
- baxtr 9y ago
  This is what I assume reading articles like [1]. Obviously, there is no direct product P&L responsibility [1] https://stratechery.com/2016/apples-organizational-crossroads/ https://stratechery.com/2016/apples-organizational-crossroad...

gadders 9y ago

Working in big orgs, I've seen before the problems that too extreme a project mentality can cause. Developers who move on to the next project on another system losing institutional knowledge, systems left to "rot" because no-one has budget to fix them or keep them up-to-date. However, what they are describing is really a series of projects with the same team on the same system or "product". I think there are advantages to both ways of working, but the appropriate one needs to be chosen.

HeroOfAges 9y ago

I'd like to see more organizations adapt this way of thinking in terms of the way they build software. Turns out business functionality is a great way to define boundaries for a service in a micro-service architecture. There's really no reason why the application code that gets a list of book recommendations (functionality provided by the business) can't be completely separate from the code that provides the user with a bio for an author (functionality provided by the business), or ratings for a book. This allows teams to work independently and in parallel. Organizing software development around projects makes it more difficult for software developers to leverage tools for continuous delivery and deployment. Project based development really does slow you down. Hmm... I guess my way would be to have teams that work together to deliver business functionality over products or projects. Functional teams, if you will. I see thinking in terms of products as a step in that direction. *edited to clarify my earlier statement