Abstractly Concrete

July 24, 2013

I was coaching a team trying to finalize the re-building of a 10 year old product and found we kept losing sight of the bigger picture.  The team was very detailed and I kept trying to move them to a more abstract discussion, as all of the details bogged us down and kept us from seeing the complete solution.  Being too detailed caused us to only cover a small part of the product and made it hard to see the broader picture.  We can only hold so much detail our minds at one time.  If we stay more abstract we are to see the complete picture.  After several more pushes on my part one of the team coined the phrase “Abstractly Concrete” as what I was trying to get them to do. It stuck.


“Abstractly Concrete” is a concept that is relevant to the Problem Statement, as well as the Solution Statement. It defines the mindset of these two documents as being high level (abstract) yet being precise (concrete).  It expressly avoids get bogged down and detailed.  The Problem Statement defines the problem a product is solving for the customer. The Solution Statement defines the approach being taken to solve the problem. Producing these documents at the right level of abstraction allows the team to be in sync on what they are about to do.


At the risk of being ironic, I think there is a balance to be drawn here that is hard to describe precisely.  It is important to be specific about the problem but not detailed. For example:

  • A statement that is too vague: “The end-users are experiencing long delays in having their problems addressed after they have called them in.”

  • A more precise statement: “The end-users are not being served efficiently because the service technician is losing the list of complaints that are called in. There is no methodology for logging and tracking complaints.”

The second statement is actionable while the first one is not. One could argue about whether it is sufficient, which is exactly the point. A good Problem Statement defines statements that are actionable.  The gory details do not matter when you are trying to decide the direction.

The concept of Abstractly Concrete comes out of the need to have many people review the problem that is being solved and the solution that is being proposed.  Staying high level and complete allows more people into the pool of people who can influence the direction. A detailed document is beyond reach of most people because there is too much to absorb. If a larger audience is going to be involved in review, then the document needs to define the whole solution, but be short enough to fit into most people’s ability to absorb.  The details will come later because right now the broader issues need to be reviewed and agreed upon.


Both a Problem Statement and a Solution Statement are broad documents that look at all aspects of the problem and make sure that they are thought through enough to know how they relate to the other aspects of the problem. A deep document provides a great deal of detail about each aspect of the problem, or the solution in the case of a Solution Statement.  It is the detail that is to be avoided in both of these documents as it is unnecessary and slows things down[1].


In more traditional Waterfall Development processes a Requirements Document is written to define the Problem Statement and the details of the solution space.  A Functional Specification is written to detail all of the features and capabilities of the solution. These are usually formidable documents to review. Neither of these forerunners are the right model for what we are trying to do.  They are far too detailed for the current methodologies as they assume all can be known up front, it cannot.  In Agile/Lean, we tend to push the details to a later stage.  What can be known is higher level and more definitional. It is guide whose details will be filled out iteratively in the future.


Like most things in a Lean Solution environment documents are meant to be small steps with frequent iterations. The power of being Abstractly Concrete is that it allows a broader problem to be reviewed in a timely manner. Be high level and abstract but firm about what is that is being defined.




[1] For the Lean experts out there this is a small batch, not a big batch effort.



© 2011-18 Westerly Consulting LLC, all rights reserved



Share on Facebook
Share on Twitter
Please reload

Featured Posts

I'm busy working on my blog posts. Watch this space!

Please reload

Recent Posts

November 23, 2015

September 11, 2014

Please reload

Please reload

Search By Tags
Follow Us
  • Facebook Basic Square
  • Twitter Basic Square
  • Google+ Basic Square

© 2017-18 by Westerly Consulting, LLC

Westerly Consulting, LLC

All photographs by Fred Engel