If you're wondering if this is gonna be an entire ad for the book, don't worry. It won't be (maybe a little). This article aims to demonstrate that agile practices, the ones we so passionately teach, can be applied beyond the obvious. Let's be honest from the beginning; it wasn't as smooth as we hoped. However, over this 2.5-year journey, we have learned a ton. Skin in the game, passion, vision, and mostly grit and perseverance helped us to achieve the product we wanted to create. Whether the product delivers the value and the outcomes we hoped for is something we have yet to validate. Because as we all know, everything is an assumption until it's in the hands of the user. To make the content come alive, we created a fictitious company called Magnum Opus, a traditionally market-dominating player in the biometric security market, struggling to keep up with its competitors. It needs to change to survive. This is the case study in Solving for Value: A Journey of Ambition and Stupidity. So, let's dive into (some of) the practices we used.
Vision
After decades of combined consulting experience, we noticed many organizations run into the same problems and work with the same dysfunctions, and all (at least, the vast, vast majority of them) think they are special. We found out that the only way they are special is that every organization is unique, like every person. The challenges they face, however, are not. It's our mission to help organizations deliver awesome products that deliver great outcomes. We decided to write down our experiences and arm the reader with the tools and techniques that helped us.
We had one concept very clear in mind: this is not going to be the next theoretical management book. There's enough of those. We call this a bar book. The tone should reflect our personalities. We're not corporate or theoretical, for that matter. The relaxed style of writing reflects that yet makes it pragmatic and actionable. Why, you ask? Great question! We want to deliver empathy for those in the trenches, going through the weeds. Product management is hard. Changing the organizations and applying Scrum (or any other framework) is even harder. We wanted the reader to know they are not alone. We've been there too. We started writing the book from a Scrum Master perspective. The further we went into the process, the more we saw the limitations of this perspective and noticed the gradual market change from a framework-oriented to a product-led market. Even though we talk about Scrum in part, this framework can be changed to any other framework. The lessons, challenges, dysfunctions, and antipatterns are the same.
Inspecting & Adapting
As we teach in our classes, we should continuously inspect and adapt to changing circumstances and emerging information. The direction of the book was one of the many things that changed. We initially tried to apply Scrum to write. Work with two-week Sprints. Visualize our Product Backlog. Work with stakeholders. Although parts of it, like visualizing, helped us structure our work, writing a book doesn't have the complexity that makes a framework like Scrum truly work. That, and the fact that with two authors we couldn't really work as a team. We abandoned Scrum, but kept parts of it.
Other examples of inspecting & adapting were (but definitely not limited to):
- Specific parts of content;
- Writing style (type of words, but also when to apply things like semicolons professional, UK vs US English, etc.);
- What type of jokes did and did not work;
- Pricing;
- To work or not work with a publisher;
- Making content last.
Short Feedback Loop
As stated earlier, it was a multi-year journey. To validate we were on the right track, we asked the Mastering Agility Discord community for volunteers who wanted to proofread the first bits of the content we wrote, apply the feedback, and deliver a new Increment of the book. We didn't deliver the entire book there, but it helped us craft and reshape the prototype and direction of what we thought was valuable. Some things we left out in the final version. This is also where we experienced again how hard it can be to kill your darlings. Sometimes, we really liked the message of something we wrote or found the message valuable. Sometimes, it was just a personal thing we wanted to write down. For instance, the desire to write a book in the first place came from Sander's sense that it was weird to one day leave this life and have nothing noticeable that shows he ever lived (apart from his beautiful children, of course). Although that was a very personal and intimate detail to the Introduction chapter, it was received as very heavy and out of tone with the rest of the content. That is one example we took out.
But also as authors with very busy schedules (I mean, we teach classes, do consulting, speak at conferences, travel for work, host a podcast, write articles, have busy family lives and pets, and still have to do shameless self-promotion on LinkedIn as well), we needed to stay connected and aligned to ensure we were still delivering the product we envisioned. When starting, we did so by writing paragraph by paragraph. Due to schedules, we changed that to writing out the storyline in its entirety and then fleshing out the contents chapter by chapter. Each author delivered a complete chapter and integrated that into the main document.
Besides that, we worked with an incredibly talented graphic artist, Olina Glindevi, to make our storyline come to life. We created a Whatsapp group with the three of us to communicate quickly, a Google Doc for the concepts we wanted to see visualized, and a Google Drive page to share the images in. We are in LOVE with these images.
A/B Testing
Other things that we had fairly clear but had multiple ideas or versions from, like the cover design of the book, we checked with the community. We never specified what we exactly wanted with these concepts initially, but we wanted to gauge the reaction and sentiment from our target audience first. We then combined that with other areas where we did A/B testing (in our classes, with colleagues, etc.) to make a decision.
The example above shows the Discord community going for the cover with icons only on the back, while other groups combined the version with icons on the entire cover came in with the most votes.
Fixing Problems over Executing Solutions
One of the biggest questions we faced initially was whether to work with a publisher. After multiple conversations, gaining information, and weighing the pros and cons, we decided to go for self-publication. This had one big downside: we had no clue how that worked, as we'd never written a book. The benefit that made us go for self-publication, though, is that we had full creative freedom, whereas many publishers decided how to style and design the book. Now, we were in full control. That meant we needed to figure out:
- Physical size of the book;
- How to get the book on Amazon;
- Graphics;
- Chapter styling;
- Creating Kindle version;
- Differences between paperback, hardcover, and if we should create both;
- Translations;
- Referencing;
- Spelling checks (one tends to get blind to them after a while);
- Marketing;
- What categories to serve;
- Author bio;
- How to get ISBNs (and apparently, the bar code is required separately too);
- Cover design;
- Pricing;
- Many other things we've probably forgotten.
Conclusion
A question we've received numerous times now is, "Would you ever do it again if it takes all that effort?" The answer is yes, absolutely. We feel we created something valuable, useful, and applicable. We learned so much about the process, and we are incredibly proud of the end result. Applying the concepts we teach made it even more interesting. And with that, we can also unveal something else: we already started working on the next book that goes deeper into products.