Practice Systems Thinking: 1) from Impact Map to Causal-Loop Diagram

A few years ago, I wrote about "how does LeSS optimize organizational ability to learn?". I saw the potential of practicing systems thinking to enhance both product and process learning, but lacked the concrete steps to make it happen. Now, I gather more thoughts and experience, thus mean to write two follow-up articles - this one is on product learning, and the other will be on process learning.

I always feel hesitant to introduce systems thinking in product domain, because even though it can help in theory, it seems not enough empirical evidence to support its adoption. In contrast, impact mapping is a more recognized technique, and they are both based on logical thinking underneath, so I wonder if we could use it as a stepping stone to systems thinking. While practicing impact mapping, I suggest to do it in a freer manner and focus on establishing the influence path between features and goal - how every feature is expected to cause and has actually caused achieving the goal. In my recent experience, the client one day discovered that it was akin to CLD (Causal-Loop Diagram) - aren't we actually practicing systems thinking? Yes, this approach - from impact map to CLD - could indeed work!

Impact Map vs. Causal-Loop Diagram

Impact map is the outcome from impact mapping. It is a structured mind map, having a goal in the center, with features connected to the goal. CLD is a basic tool in systems thinking. It consists of variables, links and loops to illustrate system dynamics.

They both show causal relations, and both encourage to broaden the space - who else and how else to influence the goal in impact mapping, what other variables influence the dynamic in systems thinking.

However, there are some further benefits through the practice of systems thinking with CLD.

  • By loosening the structure in impact map, we are freed to create as many causal links as needed, usually leading to more granularity, thus more clarity and rigor.
  • With more variables explicitly being added into the picture, it provides an opportunity to broaden the space further, as we can ask for each variable - what else causes (drives or limits) its change; what else its change leads to.
  • With systems thinking, it explicitly asks to extend the time as well - how each variable changes in both the short term and the long term.
  • Loops may emerge, and provide further insights for leverage, e.g. exploit reinforcing loops for growth, remove the limits from balancing loops.

Next, I will use an example to describe the process of moving from impact map to CLD, and demonstrate the advance in thinking out of it.

Convert then Expand

This is an example of impact map.

from Impact Map to CLD - 1.jpg

Let's see how each structural element in impact map relates to CLD.

  • Goal could be represented as a variable that we would like to optimize, i.e. a variable as system optimizing goal.
  • Actor provides perspectives to broaden the space. While modeling with CLD, they are not variables, but can help us think of more variables and see more dynamics.
  • Impact is the most critical piece to connect deliverables and goal. We can extract it to create a causal link between each deliverable and goal, with as many intermediate variables as needed.
  • Deliverable may or may not be directly represented as a variable in CLD. They can be actions to change variables.

Without much difficulty, we can convert the example impact map into the below CLD.

from Impact Map to CLD - 2.jpg

Here are a few notes:

  • "revenue from ads" is a variable directly from the goal.
  • I add quite a few intermediate variables, such as "#impressions", "CTR" (Click-Through Rate), "frequency of visits", "length of visits", etc., for more clarity and rigor.
  • Among the 5 deliverables, I add corresponding variables for 3 of them (push updates, special offers and better pagination), but the other 2 (forums, chats) are just actions to change the variable "ways to engage". This is to better illustrate the possible relations between deliverable and variable.

Then, we work this initial CLD further by expanding time and space, and discovering interactions and loops, i.e. practicing systems thinking. The below is one expanded version.

from Impact Map to CLD - 3.jpg

Here are a few notes:

  • About push updates, there is a limit for the "#push updates", as high number of updates will increase "user annoyance". I add a variable "relevance of updates", then discovered R1-loop that drives the "frequency of visits" through better "understanding of users", thus more relevant updates.
  • About special offers, though it drives more visits, thus, more revenue and profit, more budget to fund even more special offers (shown in R3-loop), it increases cost as well, thus puts a limit (shown as B1-loop). I add a variable "relevance of offers", which brings about a similar dynamic (shown in R2-loop) as "relevance of updates".
  • Forums and chats provide ways to engage users, so that they can stay longer during their visits. I add a variable "content quality". There are two related reinforcing loops. R4-loop is to drive the "length of visits" with higher-quality content by the company through better understanding about users. R5-loop is to drive the "length of visits" also with higher-quality content but by active users themselves.

Do you see the advance in thinking with the expanded CLD? That's the motivation behind moving from impact mapping to systems thinking.

When do we do all these? Same as impact map, there are as-is and to-be views for CLD too. It is an iterative process to keep exploring, learning and updating. As this is on product learning, it mainly happens during PBR and Sprint Review.

If practicing systems thinking in product sounds too far, impact mapping could be a stepping stone. Beginning from impact mapping, perhaps one day we will be practicing systems thinking without notice.

Read more

Scrum master ทำแค่เนี๊ยะ

Scrum master ทำแค่เนี๊ยะ

เวลามีคนถามว่า Scrum master ทำอะไร แล้วผมตอบว่าทำให้ Scrum เวิร์คสำหรับทั้งองค์กร ซึ่ง โฟกัสหลัก ๆ 4 อย่างก็จะอยู่ที่ Product owner, ทีม, engineering practices และ องค์กร บางครั้งที่ผมจะได้ยินเสียงตอบกลับมาเบา ๆ ว่า “แค่เนี๊ยะ?” ในฐานะ

By Chokchai
how to สร้าง Knowledge Management

how to สร้าง Knowledge Management

ตอนเรียน Large Scale Scrum กับ Jurgen de Smet สิ่งหนึ่งที่ผมได้เรียนรู้ คือ ปัจจัยสำคัญหนึ่งที่ทำให้องค์กรหนึ่ง ๆ จะเร็วขึ้นได้ คือ จะต้องเรียนรู้ไปพร้อม ๆ กันได้ ซึ่งถ้าอยากทำแบบนั้นได้ก็จะต้อง share ownership

By Chokchai
โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

ซามูไรที่ได้รับความไว้วางใจให้แก้ core logic จะมีสัญชาตญาณซามูไร คือแก้ตรงนี้ จับยามสามตาแล้วรู้เลยว่าจะไประเบิดตรงโน้น แล้ววิ่งไปสกัดบั๊กไว้ก่อนความเสียหายจะเกิด (ถ้าเป็นในหนัง ตอนนี้เป็นบทที่บั๊กร้องว่า “มืงรู้ได้ไง?!” :D) หลังจากที

By Chokchai
ประสบการณ์ TDD

ประสบการณ์ TDD

มันมีบางชั่วขณะ ที่ผมอินกับ Test-Driven Development (TDD) มาก จนอยากจะแนะนำทักษะนี้ให้คนเขียนโค้ดทั่วโลกที่สนใจเลย ผมคิดว่า ทักษะนี้มีผลเยอะมาก ๆ กับความรู้ความชำนาญในการเขียนโค้ดของผมทุกวันนี้ แต่ที่ผมไม่เคยอธิบายเป็นคำพูดออกมาได้คือ ทำไมนะ? เมื่อเช้าตอนกำลังอ่านเกี

By Chokchai