I believe that development costs should inform every activity that takes place when developing software.

Achieving this is not as easy as it sounds, as it doesn’t come up naturally with the typical division between product, design and development roles.

Take the following flow:

  1. Product people decide that some feature is needed
  2. Designers come up with some design
  3. Developers implement it

Minding development costs means that product people won’t decide what to build next based only on delivered value (however that is measured). It is acceptable to choose a feature that is easy to implement over some other that is very difficult, even if the value it delivers is smaller.

Similarly, designers won’t consider they have a blank slate where everything is possible. It is perfectly fine to favor a design that is worse, regarding UX desirability, if implementing it represents a fraction of the effort that the first alternative.

Finally, developers won’t blindly implement what they are asked to. They make sure their voices are heard before and after work starts. And they consider development costs a first-class citizen when making implementation decisions.

What do you achieve with this? Optimizing your system as a whole. Development costs are real. Not everything is equally difficult to create. If you ignore this, you might be optimizing activities when considered in isolation, but you are hurting the system as a whole. For example, your product-owner might be doing a terrific job coming up with valuable features, but throughput will be terrible if you keep hitting implementation tasks that consume most of your time: most features will never see the light in time.

Often, the emphasis is put on the feedback cycle between users and the team building the product. Iterations between the different parties within a team are crucial for the same reason: dealing with uncertainty. Conversations need to happen, and development costs should be a frequent discussion topic.

Development costs should be a first-class input for most of your decisions. And you should start pondering them early in the process. Don’t wait to start with technical work before considering them. Being able to choose simple systematically is a super-power.