I read the article Product Beats the Process and  felt compelled to respond

Product Beats Process

The author, Jeff Morris Jr. is right, the populous or customers at large probably do not care about how we arrived at the product. They do not care about the process. They do not care about the creative problem solving that went into bringing the product to life.  They do not care about specific Jira or defect report tickets.  They do not care about long hours, personality clashes, and design trade off curves.  However, I disagree when the author says they only care about how it feels in their hands and nothing else.  This disagreement is not based upon some statistical analysis so, perhaps he is correct. It is however, based upon my personal priorities and experience, and I find it difficult to believe that I am a singularity.

What matters is that we build products that make customers smile and realize something new about themselves.

Being an engineer type of person, oriented to working, practical and perhaps marginal aesthetics, I am not sure what matters is that the product makes me smile.  That is the reason for Tequila, Rum and Moonshine.  At my age, I think I know much about me (and not enough about everything else), and really do not expect a product to help me discover some inner truth about myself.  I especially do not want to learn that I am not fast enough to outrun the product that is trying to kill me because the people nor the process that delivered it had not considered key attributes or the quality of the product.

The quality of the product likely matters to the customer

What matters is that we build products that make life more fulfilling for billions of people by giving them access to education and new ideas.

Now we are getting somewhere, these things do matter from my perspective.  The things we build should make the customer’s life better or easier. That is the point.  The product should meet these expectations reliably and repeatable.  If our product makes education easier or more ubiquitous, or help create new ideas and innovation we can consider the product a success.  If it helps keep our company afloat and our employees taken care – that is great.  If the product is not so reliable or repeatable, well let’s say if I had purchased a product that worked only occasionally or gave me mixed results, sometimes good and sometimes errant, I would not be happy- and probably seek another supplier for the widget.  To be blunt, I will go to your competition, assuming your product did not kill me or cost me a fortune, or alienate me from this type of product for the near future.  These things can happen when the process is incapable.

Are there easy wins in our production apps that we could have discovered instead of seeking the perfect process?

I agree with the author on this regard, the process, is not the be all end all; delivering a suitable product within the business case cost confines is the objective.  That is, the process is not what pays the bills and retains customers when it is working.  However, what happens when the development is entirely adhoc, or non-existing, or the process is poor and we deliver a product late, after spending considerable resources?  What happens if the quality of the product in the field means virtually every unit is returned?  What about recalls? What happens if our product physically harms the customer?  This happens in the real world when there is no process or incapable process.

Does the process matter?

The point is, the process does not matter when it is capable and delivering. The moment we encounter the afore mentioned challenges, the process begins to matter, only it is too late. It matters to the developing organization.  It matters as your company loses business to the competitors, while you are paying restitution for the damage your product has done in the field.  Errant or non-existing processes can lead to these things.

The reason for a process (or collection of processes), is to provide measure of repeatable outcome and provide some understanding of the product and needed controls on the development.  It helps us control the maturation process for the product, and provides measurable results that let us know when the product is mature enough for launch. It provides a measurable baseline  from which we can make some quantifiable statements.  This quantifiable baseline can then be controlled  It helps partition the work among the teams within and outside of the organization, and yes, sometimes this apportioning of the work is part of the problem.

Process and Adaptability

There is often more than one way to achieve the objectives of a specific process, and sometimes, the primary, preferred or documented process approach may not work as described.  That does not necessarily mean abandon that process objective.  We first must review if that specific process objective is required for this product or project.   It can be that the objective did not apply to this product, and therefore this portion of the process can just be eliminated.  However, if we need to accomplish this process objective, and the documented approach is not possible, all is not lost.  This is when we use our creativity and collective intelligence to adapt to the situation, finding other ways to achieve the objective.  Product development is not prescriptive, the work often contains considerable learning about the product and the team as we move through the development life cycle.  We should neither advocate for the banishing of a process (Jeff Morris Jr. does not do that) nor should we stick to the process as if it had great sanctity.  We should use what we know, measure, learn, adapt and continue that process ever refining and getting better, knowing there are going to be times when the process will not be able to deliver and we will have to adapt to meet that process objective.

Capable Process

Conclusion

Product beats process only when the resulting product is capable, meets the customer’s needs and expectations, and can be economically produced.   The process is a base line from which a continuous and conscientious improvement based upon what is known about the present process – this is not possible with adhoc approaches.  If you are not getting these benefits from your process it is time to rethink your approach.   When the company loses money on the product (if we are a for profit entity), the customer is harmed, the company is in litigation, then the process absolutely matters, and it is not possible to retroactively fix.  This is especially true when it comes to litigation, and investigation as to how we delivered the product (what processes did we use).