Day 200 of Self Quarantine             Covid 19 Deaths in U.S.:  205,000

Rest in Peace Justice Ruth Bader Ginsburg                                   VOTE!!

Professor David Socha asked me a second question after “where do you observe different parts of the software product development life cycle – what is the diagram that shows where to observe?”

I am continuously sketching the answer to David’s question.  As usual, I start with the complexified version of the diagram.  Over the last week, David and I discussed, debated, added and subtracted a lot from this diagram.  This blog post is the first attempt to come up with a diagram of an Agile OODA (Observe – Orient – Decide – Ask) HCD (Human Centered Design) Loop (virtuous cycle) for software product development.

As I stare at this diagram, I realize it is more of a macro diagram and is heavy with framework systems that require a lot of description and unpacking.  And this diagram is “simple” because I would really mess it up more if I added all the loops of iteration throughout the diagram.

David did a nice job in “Observe, Don’t Ask Part 2” of enumerating all of the activities in the software product development life cycle where you either need to Observe or Show.  The more interesting question is where you wouldn’t do Observe or Show?  We both realized the challenge of trying to document what we mean versus showing a more complete context of what we mean.

As I tweaked the above diagram, I wondered if there was a diagram that showed the feedback and feed forward loops  or maybe a Venn diagram to illustrate relationships in a clearer way.  As I doodled with different loops, I realized that I had not referenced the OODA Loop that John Boyd developed as a fighter pilot.

Boyd’s work in developing the Observe-Orient-Decide-Act loop was an important step forward in military tactics.  This strategy was the basis for our winning so quickly in Gulf War I and was adapted for business and commercial use in the books Winning in Fast Time and Certain to Win.  While Boyd did not write any books, he was famous for putting his materials into an extensive slide deck and giving the presentation to anyone who would listen.

Boyd’s original OODA loop diagram looked like this:

I love that there are both Feed Forward arcs and feedback arcs.

The folks at IMARC AI provide a simpler update of the original OODA loop.

As I play with this simplified diagram, I realize it fits nicely underneath all of the steps and frameworks in the complex diagram.  The “observe” step is obviously the “observe, don’t ask” step.  The “orient” step fits nicely with what I mean by “show, don’t tell.”  The “act” step needs a reminder of don’t dilly dally with “Act, don’t delay” which is the fundamental speed insight of Boyd.  The decide step fits a mantra of “prototype, don’t guess.”  So many times in the product development process, the software engineers are forced to guess what is meant by a user story or a requirements document or a short discussion during a daily stand-up.  What human centered design practitioners learn early on is to do rapid prototyping even if it means doing paper prototyping.

I can’t help myself and realize that I have to add to the simple OODA diagram.  While I love the original icons, I didn’t like the ACT step as it implied thinking to me.  Acting is about moving and I wanted to have something that had hand movement.  I also felt that there needed to be something in the middle that was an indicator of the “so what.”  Where does the OODA loop for software product development lead – to value.

For each step in the complex diagram (and the many sub-steps), the work is about figuring out what to observe, and then what insights arise from the observation, that need to be carried to the next step to “show” the developers.   At each step there are one or more decisions.  Some of those decisions can be made based on “patterns that repeat.”  Others require some rapid and iterative prototyping.  The prototyping takes the guess work out of deciding what needs to be built – the “act” step.  Then once something is built, that prototype needs to be observed in use “in the wild” of an actual user’s environment.

Then, the OODA loop repeats until there is a measure of good enough as described in the Part 2 blog post.

“To claim that any given thing is Good Enough is to agree with all of the following propositions:

• • • • • • • It has sufficient benefits.
            • It has no critical problems.
            • The benefits sufficiently outweigh the problems.
            • In the present situation, and all things considered, further improvement would be more harmful than helpful.

The micro level OODA loop steps for software product development are:

Now that we have an idea of the core process underlying the more complex model, let us look at the components of the larger model.  The descriptions that follow assume that we are in an early stage startup where the product and the company are mostly the same thing.  Inside a large company the equivalent is intrapreneuring where a new product and new business are created together.

The macro OODA loop for software product development has several internal and external components.  The Observation step in the macro OODA loop is:

Over the years I’ve learned to start any new product idea by trying to fill out the nine boxes of a lean canvas.  The lean canvas below is an early draft I did for the Know Now book I am writing:

The lean canvas is a paper prototype of your product and business idea.  Filling in each box gives you a quick way to see what you know and what you think you know (The Four Boxes of Knowing).  The work is to figure out which box of content you know the least about.  That box becomes the priority to learn more about.  Most early stage entrepreneurs leap right into the Solution Box and have a wide range of ideas of how to solve for some problem.  Over the years I’ve found that I rarely understand the problem or the existing alternatives and who the early adopters might be.

For the Know Now book project, my hypothesis was that the early adopters would be product managers.  While I have done product management off and on for 20 years, I realize how little I remember about how I educated myself about product management.  So the first thing I needed to learn about is product managers and how they learned to become a product manager.

The key components of the Observe step come from the Human Centered Design process that I learned about at the Institute of Design.  Ideo offers a range of online courses and extensive consulting services that help companies implement a robust human centered design process.  A starting point for learning about Human Centered Design is Vijay Kumar’s book on 101: Design Methods.

As I interviewed several product managers, I was also coaching several early stage startup CEOs.  I realized that one of the challenges in an early stage startup is that the CEO acts as the product manager due to lack of funds.  In an early stage startup, the product and the company are one and the same.

In parallel with identifying users to observe, the CEO as product manager is also developing a business plan for the product and trying to understand the external environment as depicted in the micro OODA loop.  Useful frameworks for observing the external world are captured in the Scenario Planning Process and in collections of useful frameworks.  The kinds of information that the CEO is looking for are social dynamics, economic issues, political issues, technological issues, culture trends, legislative and regulatory trends, and ecological issues.

Along with observing external factors, the CEO is always trying to estimate TAM, SAM and SOM for the potential product.

Now that you have identified the users to observe and performed the observations (where possible using video ethnography), then it is time to ORIENT.  The Macro OODA Loop for Orientation is:

As you make sense of your observations there are several frameworks that guide what to look for.  The observations should include the full flow of work.  Within the flow of work you are looking for the hassles that a user encounters.  Adrian Slywotzky describes hassle maps in his book Demand: Creating What People Love Before They Know They Want It and in a short monograph on The Art of Hassle Map Thinking.

An example of a hassle map is the one that Zipcar created:

No matter how manual or automated a given work flow is there are still hassles that a user must overcome.  This step of the Orient process is to identify all of the hassles and to start looking for solutions to eliminate the hassles.

Service Science emerged from IBM as their business transitioned from hardware to software to services.  Jim Spohrer in “The Emergence of Service Science: Toward Systematic Service Innovations to Accelerate Co-Creation of Value” provides a diagram of the evolution of automation of a manual task.

After identifying the hassles of a user, the next step is to understand where the user’s work environment is in the sequence of work evolution.  Each step has a different set of software development activities and degree of difficulty.  For most of my professional life, I focused on human systems that are mostly manual and then looked for ways to augment that system.  Spohrer points out that is just one step along the path.  Over the last 20 years of software product development in the eDiscovery space, we’ve seen the progression to Augment with our Attenex Patterns product, and then to outsourcing with companies like FTI Consulting and Lighthouse, and now with full automation with the AI/ML capabilities of NUIX Discover.

The next step in orienting to what you observe is understanding whether there are particular steps that have the most costs or that lead to the most revenue.  In the eDiscovery market the EDRM model is the generic view of the work flow.  When we did our early studies, we realized that most of the costs are incurred in the four boxes of processing, review, analysis and production.  We could make a huge difference on the cost structure of a matter if we focused our augmenting efforts just on those four boxes.  While all of our competitors tried to solve for each of the boxes, many of which weren’t generating costs, we focused on where the costs were.

Usually when finding out where the costs are in any workflow, you will also identify the bottlenecks or constraints to the work process.  Eli Goldratt with his Theory of Constraints asserts that in any give work process there are only 2-3 bottlenecks or constraints.  He recommends that the automation work focus on the bottlenecks.

Now that you have gone through the orientation steps of the Macro OODA model for software, it is time to build a prototype solution to test your understanding of what you have observed and oriented.

These prototypes can be as simple as a paper prototype as described in Vijay Kumar’s 101 Design Methods or as complicated as a software prototype.  Fortunately, our tools for building software prototypes have gotten so good that even complicated prototypes can be produced quickly.  Each week that goes by show cases another low code or no code tool for building sophisticated applications.

The Lean Canvas is a paper prototype of a business.

With the first pass of the Orientation loop producing a prototype, it is time to test the prototype with a real user in order to DECIDE what to do next.  The Macro DECISION Agile OODA loop is:

There are four possible actions that you need to decide on to move forward:

• 1. Go on to the next step
  2. Recycle within this step
  3. Pivot (take another approach)
  4. Abandon the project

When moving in fast time, the most likely decision is that you need to recycle within this step.  If you have done good work in the Observe and Orient steps, the step 4 of abandoning is unlikely.   If you have recycled several times and don’t seem to be making progress, it is often advisable to go back to the Observe and Orient steps to see if you missed something.

The first step within DECIDE is to commit to doing daily demos rather than agile daily stand up meetings.  The purpose of the daily demo is to SEE the actual progress being made.  It is a combination of understanding what was accomplished the previous day and designing the work for the next day.  The meeting should be rapid fire and last for just 15 minutes.  Once or twice a week, enough problems with the daily design may become evident and a longer stand-up meeting is scheduled to explore in more detail the execution problems with the prototype.  These longer meetings typically use the micro OODA process to go back to basics.

The participants in the daily demo should include the appropriate developers (usually a front end UI developer and a back end data manipulation and storage developer), a senior architect, a product owner or product manager, and a business owner.  An ideal room for a Daily Demo should include a large screen that can be seen by all and a white board for design discussions.  The meetings should be recorded and an audio transcript is generated.  Photos of the white board are also taken and included in the records of the meeting.  The meeting artifacts become the fodder for the weekly and monthly retrospective analysis.

The second step of the DECIDE step is to do a limited release to target users and have them use the prototype in an actual work environment.  The software should be instrumented so that actions the users take can be analyzed.  Video ethnography techniques to record what happens around the software usage are important to capture as well.  The product owner and UX representative check for additional insights through analysis of the telemetry and the video ethnography that are brought to the next day’s daily demo.

A key part of the DECIDE step is evaluating the prototype against the Outcomes and Impact that the product will have for the customer’s business.  An Outcomes focused product development effort is described in a “Product Produces Outcomes.”  As part of the Observe and Orient steps the product team develops a North Start Metric to guide the development.  The North Star Metric should be closely related to the desired outcomes for the product.

After DECIDING what to do next, it is time to ACT and launch a version of your product to a larger customer audience.  The Act Macro OODA loop is:

Now it is time to take ACTION.  As mentioned above, there are relatively few types of decisions to make during the DECIDE step.  “How to decide whether to adopt, adapt or abandon” describes a process for acting on the decisions.

As you progress the first time through the cycle, you are deciding whether it is time to launch an Minimum Viable Product to gather information from a larger sample size of users.

Through telemetry data you quickly identify who is using the product on a regular basis and these users are good candidates to perform more in depth observation.  Opening up your product to a larger audience, particularly in cloud SaaS (software as a service) environment, helps you capture key metrics for product success:

• • How many users invited to participate actually sign up and log in?
  • How regularly do the participants log into the product (ideally multiple times per day)?
  • How much do the participants use the product?

The answers from your telemetry data and your qualitative research should help you answer the key criteria for getting ready to launch your V1 product and your business.  The launch criteria are;

Bringing all the pieces of the macro agile OODA loop together, we have:

The first pass through the macro agile OODA loop gets us to a V1 of a product that becomes the test for a product solution fit as described by Ash Maurya at Leanstack.  The meta agile OODA loop cycles through the macro OODA process as the product evolves from V1 to Vn and the product becomes more of a Whole Product as described by Geoffrey Moore and Philip Kotler.

The Leanstack model identifies the key criteria that it takes to scale from an idea to a product solution fit to a product market fit to a product at scale.  Maurya’s books Running Lean and Scaling Lean describe the journey to scaling.  At Leanstack, Maurya provides tools and coaching services to aid early stage startup teams to navigate the journey to scaling.

For enterprise software products, there is another key element of software product design which Geoff Moore describes as the Whole Product concept to avoid the startup disaster of the chasm.  Moore identified that most startups don’t understand that the earliest customers are not representative of the Early Majority customers.

Moore in his books Crossing the Chasm and Zone to Win illustrates that the Whole Product concept is the method for avoiding the chasm and scaling.

Most enterprise software product development teams only focus on the core and generic product layers.  Yet, in order for a customer to use a product to produce an outcome that will have a business impact the expected and augmented product layers are needed.  These two layers usually involve creating partnerships with other suppliers of related products.  From a technical perspective this means creating application programming interfaces (APIs) within your own product and using APIs from those products you are partnering with.

Throughout this whole process of Agile OODA HCD software product development, you are trying to co-create value for the customer.  The service science researchers have nicely formalized the value co-creation process represented by this diagram from Vargo and Lusch in “Service-dominant logic 2025.”

The diagram provides both a virtuous cycle of value co-creation and a narrative of how the pieces flow together:

“Actors involved in Resource Integration and Service Exchange enabled and constrained by endogenously generated Institutions and Institutional Arrangements  establishing nested and interlocking Service Ecosystems of Actors …”

That is certainly a mouthful of complex concepts from a pair of academic marketing professors.  What is means to me is that in order for any company that produces a product to receive value it must first help co-create value with its customers.

The diagram below summarizes the keys to “Observe, Don’t Ask” in order to reduce the uncertainty of software product development by using the Agile OODA Loop at a micro, macro and meta level in order to reliably and quickly generate successful products.

Observe, Don’t Ask.  Show, Don’t Tell.  Prototype, Don’t Guess.  Act, Don’t Delay.

• • Part 1   Observe, Don’t Ask.  Show, Don’t Tell
  • Part 2   Where does “Observe, Don’t Ask” show up in software product development?
  • Part 3   The OODA Loop
  • Part 4   Orient, Evaluate and Prototype
  • Part 5   Video Highlights for Show, Don’t Tell
  • Part 6:  Show the software, don’t try to describe it