What Origami can teach us about Product Requirements

Tom Grant has started an interesting series of posts entitled Against a Grand Theory of Product Management. The articles are interesting reading, but make sure you have your thinking cap on when you start, because Tom is discussing an important but rather abstract topic.

He pulls in references ranging from Middle Range Theory (something I’d never heard of before) to Darwin’s theories (something I think we’ve all heard of but probably don’t adequately understand) to help convey his points. I had to read the posts a couple of times each to better grasp the specifics of his arguments.

In Part 2 of his series, Tom asks:

If someone can figure out why even the most meticulously written and reviewed requirements don’t stop some tech companies from making products that their users don’t like or can’t understand, that’s a big contribution to our little field of study. Best to have more middle-range theory before even thinking about the GToE [Grand Theory of Everything].

This is a great question. But before I answer it, I want you to watch the following video. It is from a TED Conference talk given in February 2008 by Robert Lang. Not only is this a fascinating video, but as you’re watching it, keep Tom’s question in mind. Don’t read on though until you watch the video. 🙂

[BTW, if you are impatient and read ahead, the important stuff starts at about 2:30 in the video.]

Lang talks about the evolution of origami, that took it from a traditional Japanese art form that most of us associate with creating things like this:

and turned it into an art (and science)  form that allows people to create things like this:

And what caused that evolution? In Lang’s words, the answer is “mathematics”, or more specifically, the creation and utilization of a set of rules that provide a language for defining what can and can’t be done in origami.

The rules define the crease patterns — the lines along which folds are made — in the paper. And there are 4 rules:

  • 2-colorability — any valid crease pattern can always be coloured with only 2 colours and will not have the same colour in two adjacent areas.
  • modulus (M-V) = +2 or -2 — at any interior vertex, the number of mountain folds and the number of valley folds will always differ by 2
  • For any vertex, the sum of alternate angles around that vertex will always be 180 degrees. e.g. a1+a3+a5 … = 180 degrees  & a2+a4+a6… = 180 degrees.
  • No self-intersection at overlaps – a sheet when folded cannot penetrate itself

[Note: if you don’t understand these rules, watch the video. 🙂 ]

Now these 4 rules define the properties of valid crease patterns, but there’s still something missing. How can those rules be applied to create sophisticated origami? In short, what goes in the box? (see 4:40 of the video)

Lang discusses that as well, and provides this diagram:

In short, the physical subject is reduced to a tree figure defining the key components (“flaps” in Lang’s terminology) of the subject. In this case, those are the legs, antennae, horns etc. of the beetle. That’s fairly easy.

Then some process must be used to take that tree-figure and create a base form for the final origami. He calls that the hard step.

And finally the base form can be refined to create the finished model. That’s fairly straight forward.

The “hard step” is accomplished using the rules defined above and the language for applying those rules. Given those rules are mathematical in nature, they can be written precisely and unambiguously and then executed to create the final model.

What does this have to do with product requirements and Tom’s question?

When looking at product requirements, there are analogies to Subject-Tree-Base-Model example given above.

  • Product Managers investigate  real world problems, needs, scenarios etc. (Subject).
  • They then take their learnings and create abstracted representations of them (requirements) using artifacts such as problem statements, personas, use cases and user stories (Tree)
  • These artifacts are then used by engineering teams to create prototypes and mockups etc. to ensure that the requirements were understood and addressed in the product. (Base)
  • The final product is built, tested, tweeked etc. with the appropriate “fit and finish” before being released. (Model).

Sounds pretty good so far right?

But herein lie the problems.

  • There currently is no language for requirements like the one defined for origami, that can precisely and unambiguously convey what is needed and define that in a way that ensures it can be built.
  • Requirements should be implementation neutral, but as we all know in technology, the ability to fulfill a requirement can often be limited by technology choices and decisions that were made well before the requirement existed.
  • Other constraints such as time, resources, knowledge, legalities, finances etc. all factor into how well a requirement can be met, or perhaps if it can be met or not.
  • In many cases requirements contain unknowns or ambiguities that are filled in by assumptions during the development process. This is a reality of developing products in a business environment.  In the origami situation, this is would never happen. A model (like the stag beetle) can only be built when the full crease pattern is defined.
  • There is no concept of people “liking” or “understanding” the origami in Robert Lang’s rules. i.e. Tom Grant asks about why companies build product their customers don’t like or understand.

This last point is key and deserves a little more discussion. What people like and understand is complex and is not static. In general, what people like is based on overall experience and emotion. It is not something that (currently) can be defined in a set of requirements.

i.e. users of this product must feel giddy with excitement the first time they use this software

So, can origami teach us something about product requirements?

Absolutely. The origami path from Subject->Tree->Base->Model forms series of transformations that is akin to the requirements gathering, communication and development process used when creating products.

Once a set of clear foundational rules for origami were defined and understood, not only did they open up new possibilities for forms never thought possible, but those rules formed the grammar for a language that makes precise and unambiguous communication also possible.

There is almost certainly a set of rules and language for precise definition and communication of requirements, but it has not yet been clearly formalized. That is likely a necessary stepping stone in the maturity cycle of product development.

But even with that requirements language, changing market landscapes, customer preferences and needs, technological, resource and time constraints will all work together to make product success a “grey box”, where those with great vision, insight and execution are likely to succeed but never guaranteed that success.


Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine


9 responses to “What Origami can teach us about Product Requirements

  1. Some readers are going to feel nauseated when they read this comment, but the differences between product management and origami that you identified are compelling reasons to use agile development methods.

    It would be nice to define all the requirements up front in an exhaustive and perfectly rigorous manner and hand them off to designers and developers to build. But the reality is that product development involves too many risks and uncertainties. Agile embraces these imperfections and builds ways of addressing them into the process.

    For this reason, I believe product management should be spearheading agile processes and evangelizing them to development, not vice versa.

    • Roger,

      Thanks for the comment. As I’ve stated on this blog (http://onproductmanagement.net/2008/10/30/agile-pm/)

      I view Product Management (and in fact most other business functions) as having been “agile” for a long time. The lone holdout was in fact Engineering with their long drawn out process for specifying, writing and testing code.

      I once wanted an “alpha release” (because waiting for beta was too late) of some functionality in a major product release. I wanted early user feedback so that critical issues I saw in the design (but Engineering didn’t 😦 ) could be addressed in a timely manner.

      It took a lot of convincing to get Engineering to agree, though they eventually did agree and deliver the alpha.

      Now those same teams love being “Agile” and ask how early feedback can be had.

      But, this change was only going to come from within the Engineering community. It couldn’t be dictated by outsiders.

      Who are the outsiders who could tell Engineering how they should perform their jobs? 🙂

      But, these agile methods don’t eliminate the need to have a language and set of rules that enable us to define, communicate, implement and validate requirements much more precisely and unambiguously than we do today.

      As John says below (and I like that analogy) – “The new development in Agile software development simply allows us to build smaller experiments that can be quickly validated.”

      • Saeed, it’s a real stretch to claim that product management has been agile for a long time. It’s impossible for one department – whether development or product management – to be practicing agile in isolation. It requires a team synchronizing their iterations to bring demos in front of customers and discover requirements that could never be elicited up front. And pushing developers for an alpha release doesn’t cut it.

        No one advocated “telling Engineering how they should perform their jobs”. Rather, I stated that product managers should spearhead and evangelize agile processes. The benefits of agile tend to converge around frequent demos to the product manager and customers. The product manager is at the focal point, and thus it’s natural that a product manager who really understands agile take the lead in evangelizing it to the product team and to executives.

  2. Personally I feel that while the analogy has merit, it is not a good fit because of a couple fundamental factors. In the end, Product Management has more similarity to physics and the process of developing a scientific theory than other disciplines.

    An unstated assumption in Origami, is the platform (flat sheet), the scope (1 sheet square sheet), and implementation (folding). This cannot be said with product management.

    Rather, product management is like developing economic or sociological theories. We make assumptions about what the users need (hypothesis ), design an experiment to test out the hypothesis (prototypes), and execute the experiment (launched product, and capturing the results). Success of the product will tell you if your assumptions are correct or not.

    Just like much of physics (outside of purely theoretical physics) requires engineering to construct the experiments, so does Product Management requires high level of engineering to develop the product (software or otherwise). But the core of our “craft” is really about the social sciences, such as sociology, behavioral economics, and other related game theories, and the mathematics that goes with them.

    The new development in Agile software development simply allows us to build smaller experiments that can be quickly validated.

    I am curious as to what others think of this approach.

    • John

      Thanks for the comment. I was looking at the analytic aspect of origami as an analogue to the requirements gathering and development process, but not to Product Management as a whole. There is a distinction there, though perhaps I wasn’t explicit enough.

      Product Management overall needs to be much more analytic, but you are right, the “craft” is tied into “softer” disciplines such as sociology, psychology etc.

      I do think a language of sorts needs to be formalized to more adequately articulate and validate requirements. Right now we are muddling along with what I consider somewhat primitive tools. I don’t have answers to what the new tools should be, but I know there must be something better.

      • There have been attempts to “formalize” the language we use to articulate requirements, and I like some of them – e.g. the Volere method.

        From my experience, they help you to “cover all the known corners”. What they cannot do is ensure you’ll build a great product, just one without apparent holes in it.

  3. Of possible interest – fabulous new documentary: http://BetweentheFolds.com

    “This film is much more than a loving look at the fascinating, brilliant characters who
    devote their lives to folding paper. It reveals origami itself as richer and more intricate
    than you could imagine… and by the end, you find yourself convinced that the mystery of
    folding could be one of the universe’s deep secrets.”
    — Chris Anderson, Curator, TED Conference