As an industry, software based companies have seen a significant boom in the last twenty years. Since almost all software development has been in the context of emerging markets, a variety of techniques have evolved which are invaluable to successful market emergence, product and customer development. Some of these ideas are rooted in manufacturing (e.g. just-in-time and lean), but have been further developed through peer based intellectual pursuits of building new software ideas and discovering new markets.
Cycle Time
Cycle time is the amount of time necessary to perform one cycle of a repetitive set of activites. If one is improving one’s golf stroke, cycle time would begin when one tees up the golf ball, assess the shot, chooses the club, sets up, swings and sees the ball land. Until the ball 
stops, one can not analyze how that stroke cycle went (nor what to do better next time). Golfers practice their stroke at the golf range, decreasing stroke cycle time. At the range a golfer might drive 150 balls in an hour – that’s a lot of repetition and a lot of feedback ultimately making one a better golfer. Compare range practice to an average 18 hole game which takes 4 hours and maybe 100 strokes. At the driving range, one gets 6 times the amount of practice as on the course.
In business activities one can establish a cycle time in product development and then reduce the cycle time, striving to increase learning much like the golfer does at the driving range. There are six specific techniques which are evident in successful agile software development teams that help reduce cycle time and increase the learning through each cycle.
Product Backlog:
Working toward a Minimal Viable Product / Service (MVP/S)
A Minimal Viable Product or Service (MVP/S) is one where the set of features or offerings are just enough to compel a potential buyer or client to purchase the product or service.
A Product Backlog is the set of features or service capabilities which are considered desirable for an offering and may be developed toward the product or service vision. The Product Backlog is a simple list of capabilities which are prioritized from most to least valuable.
Much like a science experiment, the Product Backlog is a list of hypothesis – the features one perceives to be valuable. Only building them and testing their value in the marketplace will bear real value. Within each iteration of product development, the highest priority items can be implemented, taken to market and verified with a customer base.
Iterative Time Box
The Iterative development technique frames product development as a series of creative activities which allows for incremental and measurable progress.
Time boxes are fixed iterations where features are developed within an interval and brought to market for validation with a customer or client base.
The purpose of the time box is to bring discipline to the cycle time of product development, creating a cadence of progress, segmenting risk and increases progressive revelation toward creating the most effective product and service offerings.
Minimal Viable Product or Service (MVP/S)
As mentioned earlier, a Minimal Viable Product or Service (MVP/S) is one where the set of features or offerings are just enough to compel a potential buyer or client to purchase the product or service. Rather than build too much of a product or service prior to engaging customers, MVP/S helps reign in any proclivities for entrepreneurs to overdevelop a product or service before actually engaging customers for validation. Create less. Validate faster. Learn more. Adjust more quickly.
Goal Question Measure – Validate Value of MVP/S
Goal-Question-Measure is a technique originally created for shaping the development of software, which is largely an exploratory and creative process. This approach can also be effectively applied to emerging product and service development in business. The process is rather straightforward – develop a set of goals for a product or service development cycle. Those goals represent what one would like to achieve with the product in the marketplace. For each goal, one identifies questions that could be asked to characterise progress toward that goal. The measures themselves are simply the units which one would use to answer the questions.
Lessons Learned
While it may seem obvious that teams of people developing products and services should share results and conclusions from activities, it is surprising how often this conclusive activity is assumed as a natural course of work but not actually performed.
At the end of any iteration, the results of development and customer activity should be collected, shared and discussed. Conclusions can be applied to adjust the target market (clients) as well as to guide improvements for the next product or service offering iteration.
Lessons learned should be a formal activity. It is foolhardy to abandon the knowledge gained in the product and customer development cycle.
