I constantly find myself reminded about the hidden costs of features.

37signals’ chapter on this is great, but it doesn’t apply to how I operate.

I’ve extracted the core idea here, as well as updated the list of things that new features involve for me.

1. Say no.
2. Have strong opinions. Whoever proposed the feature might be emotionally 
attached to it, so there are often arguments here.
3. Have meetings. Whoever proposed the feature will likely keep bringing it up.
4. If "no" again, end here. If "yes," continue...
5. Prioritize the feature
6. If it's a big feature, break it up into parts. Negotiate requirements.
7. Sketch the feature. At this point, the feature is appears almost done in the eyes of 
everyone except the development team.
8. Possibly disagree on the design.
9. As the feature gets more fleshed out, it often gets bigger after being prioritized.
10. Re-prioritize.
11. Contact the developer who is actually going to build it.
12. Make sure that the developer understands what's involved.
13. Be in contact with the developer to answer their questions. Update the requirements
as it becomes clear how the code is going.
14. When the developer is done, make sure that everything works.
15. Read over the code. Make sure it's tested and well written.
16. If it's not properly tested, send it back to the developer or write the tests yourself.
17. Make sure that the design will work for your customers.
18. Make sure that the design works in ie6.
19. Make sure that the design works in ie7.
20. Make sure that the new feature works with old data.
21. Setup whatever metrics the feature needs, like an a/b test.
21. Make sure the feature is secure.
23. Make sure that the metrics that were added don't break anything.
24. Merge the feature with the master branch, fix any conflicts.
25. Make sure that marketing copy / terms of service don't have to be changed.
26. Deploy the feature. Run migrations. If it's adding a column or index to a table
with millions of rows, make sure nothing crashes.
27. Make sure the feature actually works in production.
28. Run sql queries and check analytics to see how the feature is going.
29. Report on how the feature is going to your team.
30-32. Continue to checkup on the feature. Spend time running regressions or other analysis.
Have discussions with team about whether or not to keep the feature.
33. Make tweaks to the feature if it isn't succeeding.
34-40. Make more tweaks until it either clearly does or doesn't succeed with customers.
41. Consider how the feature will affect pricing.
42. Update pricing if necessary.
43. If the feature failed or succeeded notify the team.
44. If the feature failed and team members really don't want to get rid of the feature, 
keep it and maintain it. Otherwise, spend time getting rid of the code and making 
sure that everything still works. If it succeeded, spend time ending the a/b test and 
making sure everything still works and that customers have relatively seamless experiences.
45. Continually make sure that no other new features break this feature. 
Maintain the test suite so that this feature always works.
46.  Going forward, continue to make sure that this feature is successful in its metrics.
47. Update AARRR metrics to consider this feature.
48. Consider the impact on this feature of other new features, in terms of how customers engage.
49. Deal with longer-term bugs caused by the feature that weren't obvious initially.
50. Deal with customer support issues caused by a minority of people not liking the changes.
51. If the feature involves ongoing work, for example moderation in the case of a forum,
continually do this work.

Lots of hidden costs.