A short (ish) retrospective on writing the book
Triggered (in a good way) by a review of the book by Martin Chesbrough
Do you prefer the feel and joy of reading a physical book?
I love reviews like this, they take thought and effort to write.
Martin Chesbrough outlines the things he liked in the book and just as importantly the things that he went “meh” when he read it.
His review also reminded me of the journey it took to write the book and some of the decisions and trade offs I made as I crafted it.
The Business Model Canvas
I have been a big fan of both the Osterwalder / Pigneur Business Model Canvas and the Business Model Generation book for many many years and both the Information Product Canvas and my book are unashamed iterations of those, iterated to work specifically for capturing data requirements.
As Martin mentions I have referenced the fact I am standing on the shoulders of giants so to speak. Retaining the Creative Commons on the Business Model Canvas is what we need to do when we iterate it, given the gift we were given with Creative Commons being applied to the original canvas. This is the reason people are allowed to freely iterate the original canvas format to meet their specific needs and context. It grips my shit when I see people publish a canvas without a CC attribution, its literally a 2 sec cut and paste effort, come on people just do it already!. (here endith the rant!)
I actually tried to reach out to both Alexander Osterwalder and Yves Pigneur as I started to write the book to discuss what I should and shouldn’t do in terms of its design and format. I had a very interesting conversation with Yves around copyright on a books design vs a books contents.
The Intro Chapter
The intro section in the book was an ongoing struggle. I moved things around time and time again, trying to get the balance right between introducing the Why of the canvas and the Why of the book, as well as the usual table of contents and about me etc pages.
Each time I got the flow of the book reviewed I got feedback that forced me to reorder the draft flow yet again. Or I would get asked a question that required me to add another page in that chapter to provide more context or to provide a piece of content that was just expected to be in a book. It was surprising to me how hard this chapter was to write, given I expected it to be simple.
Learnings of a novice writer I suppose.
The Canvas Chapter
As Martin highlights the Canvas pages 22-63 are the core of the book, they explain how to complete the canvas. I loved the 3D canvas format in the original Business Model Canvas book, as Martin highlights it felt like a puzzle that needed to be solved but that could also be iterated if needed. So the 3D visualisation was always going to be in the book. This is one image I could have spent another year refining, if I had allowed myself the time, and that refinement would have provided marginal additional value (if any) so I decided in the end to make as “sketchy” as I could to stop me doing that.
The Examples Chapter
For the Examples chapter, there is something magical about giving somebody a completed canvas, and asking them a question about it. For example “what industry is this company in”, “what is the problem they are trying to solve” etc.
I could have just added the example canvases in the book with no extra context, but something interesting happened as I got other people to create the examples. They did things I didn't expect. I could see patterns in how they filled it out in ways that I don't. So I decided to highlight those things for each canvas. But I constrained myself to a page per example, so I didn't end up writing the equivalent of another book for each individual canvas.
Writing less is deffo harder than writing lots!
I will be adding more example canvases to the companion substack site as I collaborate with others to create them. I find learning by example is a great way of reinforcing understanding of valuable patterns.
The Discover, Size, Iterate, Prioritise Chapter
The next chapter is a smorgasbord of patterns that I use everyday when I work with the canvas with organisations . I have a large pattern and pattern template library which I use everyday when I work with organisations and data and analytics teams.
The chapter was originally called “Pattern Storming Patterns” but I found that I hit two problems as I wrote the content.
The first was I started “boiling the ocean” and wanted to add every pattern I used, even if I used it rarely with the Information Product Canvas. This was a problem I struck throughout the writing process, Ill say it again, writing less is harder than writing more (for me anyway).
I have ended up with a writing process I call Arm Waves, Hand Waves, Finger Points to help me be able to start writing the ocean and then refine my thinking down into coherent drops of water (or at leats a small puddle of ideas)
https://agiledatawow.substack.com/about
And the second problem was the definition of “Pattern Storming”. I constantly flipped between it being the defining of the patterns and pattern templates to using them collaboratively with others. Anybody who knows me well, knows I am semantic on semantics these days and so I needed to solve that problem. So I decided that chapter would only include the patterns that I used regularly with the canvas, and these were all focussed on Discovering, Sizing, Iterating, and Prioritising, hence the name of the chapter. I also finally worked out a definition for the term Pattern Storming that I didn't hate and added that to the book. Based on Martin’s feedback, I haven’t quite nailed that definition in a way that fully resonates yet.
Interestingly there are a number of other “storming” terms out there already, Event Storming, Model Storming etc none of those fit the definition I was looking for. Agile Storming almost made it into the book, but as Martin (and a few other people) have mentioned I talk about patterns a lot these days, so Pattern Storming just naturally fitted.
The Way of Working Chapter
The Way of Working Chapter again came out of feedback from reviewers of the draft book content. They wanted to understand where the canvas fitted “in the bigger picture”.
I have always struggled to define the macro view of Agile Data Way of Working. To me it is a pattern library not a methodology, the flow of the work and the patterns and pattern templates organisations and data and analytics teams use, and the way they use them, is very dependent on that organisations and teams specific context.
I decided to try and nail this problem in the book, and spent an inordinate amount of time iterating the four core diagrams that are in this chapter in the book, as I knew they would be reused across all the future Agile Data Guides.
Based on Martin’s feedback I think I still need to flesh out the context for these diagrams and craft more of a story around them. Which is not new news to me, I find these diagrams fall a little flat in the course when I am delivering it. My current feeling is it’s not the WHAT that is the problem it’s the WHY, but time will tell when I spend the time to iterate either the diagrams or the context for the diagrams again and then test it with people.
Interestingly this chapter and the pages within it, were the ones that I constantly moved all around the book in terms of flow, which in hindsight is a good signal for a writer that there is a problem they need to solve when this is constantly happening.
The Frequently Answered Questions Chapter
The FAQ chapter was a late arriving Chapter. I was always going to put FAQ’s in the book, but I originally had the idea of just having sound bites of the questions I would often get asked as part of another chapter.
I was running the virtual in-person course at the same time I was finalising the book's content (in hindsight this was an invaluable part of the process and one I will do from now on) and I found that I would get asked questions that I always answered in the same way. So I started to draft longer form answers to those questions in the book.
Then I started to worry that I was just repeating myself. I am a great fan of the “power of 3” and so as I thought about it I saw a pattern of one chapter to explain the canvas, a second chapter of canvas examples to reinforce that process, and a third chapter of long form text to provide a final reinforcement, all teaching the same things, but in different ways. So I decided to embrace the FAQ chapter as being a longer form text version of the content in the previous chapters, which I do call out in the intro to that chapter.
One of the things I didn’t do, was record the questions I got asked during the course, which I have now started to do. I will be creating additional articles on the companion substack site with the answers to those questions. I haven’t decided if I will update the book with those answers in a years time or not.
But I will deffo be recording the questions I get asked in the course for the next Agile Data Guide, so the FAQ chapter in that book will be much richer.
The Continue Your Journey Chapter
The last chapter has two pages written by Scott Amber. I didn’t want to have the usual intro blurb by somebody else at the beginning of the book as is the norm, it just didn’t feel like it would fit the design of the book. I also didn’t want that intro text to be their opinion of the book, funnily enough I have never seen an intro by somebody for a book that was negative.
I much preferred the idea of people like Martin being able to give a true unbiased opinion after they had read the book themselves.
However I started my journey into agile, data and ways of working by reading a lot of Scott’s freely available content, it helped (and still does help) inform a lot of the patterns that I use and share on a daily basis. So I asked Scott to write two pages for the book, which he kindly agreed to do, and then I left it to him to work out what he wanted to write about.
A Short Retrospective
I originally started typing this article out as a quick comment on LinkedIn but as is often the way I ended up spending an hour or so sitting in my chair, looking out at a beautiful view of Kapiti island and the ocean, listening to the waves crashing and typing a lot more.
It ended up being a form of retrospective on the writing process for the book, so thank you Martin for triggering these thoughts with your generous and considered review of the book.
And now it's back to working on the next Agile Data Guide, the Pink Book, “an Agile Data Guide to Data Personas”.
If you want to listen or read a little more on the writing journey behind the Green Book, you can find it on this podcast episode I did with Ramona.
Do you prefer learning via virtual in-person courses?
Do you prefer the feel and joy of reading a physical book?
Great retro - I can see your challenges. One thing worth calling out in the review or the retro is that this is a very graphic book. Full of diagrams, just like Osterwalder and Pigneur’s book, Business Model Generation. And I think this format is very under-used in tech literature. The diagrams give life and vibrancy to the topic. A canvas is a visual object/aid so the book needs to be highly visual. Well done.
Shane, having been thinking about writing a book for some time and encouraged by others, this has got me thinking about it again. You make a great point about how much harder it is to write less than it is to write more. Something for me to think about as I reopen my folder called "The Book" full of files containing snippets of content. I remember you posting in the early days that you set yourself a target of writing x number of words a day or was it a week or a month? I might try that approach and see if I can get past snippets for each of the chapters I have in my TOC snippet. Keep up the good work!