Software & Business Development, and The Tree Kangaroo

Modern software and business development follow more and more the principles of Lean Startup like promoted by Eric Ries and Ash Maurya. In short: continuous innovation to systematically uncover what customers want, deliver products they cannot refuse, and grow their business models.

IMHO some of the key principles are:

• Fail Fast, Fail Cheap
• Assume = makes an Ass of U and Me

By focusing on what to do in the very near future, the investment in case of failure is easy to absorb. The number of assumptions are few and quickly testable in practice. Further, the stakeholder engaging directly with the product/service is invaluable.

If you can start with a solid working solution already, small incremental innovation can bring you quickly in interesting places.

It is but a small jump (pun intended) to the tree kangaroo. Evolution demonstrates that with many small incremental evolutionary steps it is possible for a kangaroo to become tree dwelling.

Equally with developing software and business, focused small incremental steps can take you to different places.

However, the question to ask is: do we want a kangaroo able to dwell in the trees, or do we need some creature capable to dwell in the trees? Even when it needs to be both ground and tree dwelling, nature produced plenty of other creatures quite capable of doing this; e.g ants, snakes, frogs, monkeys, squirrels.

Therefore, know what you are after. Begin with the end in mind. For incremental changes do not necessarily get the best solution if you started in the wrong part of the solution space.

But wait! Isn't the whole point of incremental changes to prevent the problem of defining something with too many assumptions? If it is unlikely to know what the solution must look like, then how to identify the right part in the solution space?

Probably I'll do another blog on this one. I see it as laying a puzzle without the end result picture as a reference. A big heap of pieces in which there are also pieces belonging to another puzzle. Shape, color, size ...there are sometimes indications that a piece cannot be part of the puzzle.

Likewise with engineering software and business solutions. Don't rely on trying to imagine the end result for most likely it will be different from what you now can imagine. However, it is quite possible to upfront define a number of criteria that very likely must be in place in order for the solution to work.

By having a good profound understanding of the (implicit) needs of the stakeholders (be aware of explicit needs like: we want faster horses) good robust criteria can be formulated, tested, and applied. Criteria can identify some parts in the solution space that never will work. Criteria can even point towards some parts in the solution space that are hopeful. Criteria also channels creativity.