The PATh to Hours

My claim:

Most of what matters in software is the (average) time to walk between Please (I'd like the software to do something else to solve a problem) And Thank You (Now the software solves my problem).

Some organizations have models that traverse the PATh in hours ... others plod along in years or decades. Some folks sell a reduction from Years to Quarters.

It's especially interesting how different the product discovery parts become as you follow the PATh towards hours.

If I can deliver yearly or quarterly, my problem is guessing (usually badly) at what the customer needs.

If I can deliver value into customers' hands in weeks...then my problem in software is getting stuff to customers so we can learn what's wrong, and fix it.

If I can deliver value into customers' hands in hours ... then my problem becomes: What 3 or 5 things are we going to try with different customers, so we can learn how they respond to several options, and then construct a better answer tomorrow.

I'm going to call out what's GOOD about each step along the PATh, and then about what you can do with the next step.

Presented by Kyle Aretae
Kyle started writing code in 1981, and hasn't been away from a computer for longer than a vacation since.

Over the last 40 years he's been a practitioner, teacher, coach and leader for technical as well as agile topics, and he's co-authored a couple books.

His most impressive sounding role was CIO of the inc #1 fastest growing startup in the US.