I certainly align with many of the comments that the author makes about building software products. Primarily, I’ll speak to the combination of using visual tools to write documents and thinking through user stories. Though I’ve never actually been sure of whether or not I’m a visual thinker, I really lived and reaped the value of this at my startup experience this past summer. It’s interactive and high energy. If you’re sitting at a conference table while a single person types what you say into a story management system, you’re probably doing it wrong. I really liked the terms “interactive” and “high energy.” Oftentimes, when we held brainstorming meetings, or rather, “jam sessions”, and even retros, we used FigJam (a Figma product) to visualize our thoughts and ideas. It was easy to make this a collaborative process on FigJam, where everyone could participate with the task at hand and with other coworkers’ ideas using digital sticky notes and stamps. These sessions really did feel “high energy.” This also translated to speccing out user stories. For full-stack work, the engineers, too, would write and draw out user flows before writing any sort of acceptance criteria. (In fact, this user story driven mindset even translated to our testing methodology; we didn’t write unit tests or integration tests, but rather, we focused on writing tests that made sure a user task was correct and smooth). It was fun and effective to “jam” on work that I would have normally just written out in words, and I plan on continuing to do so, not just for professional work but also for school and personal work.
On this approach, a question I have is about the author’s emphasis that just because a document has been written, the words do not mean the same things to two different people. Naively, I have never really thought about that, but it is obvious that that is true. He mentions to mimic “vacation photos,” but what are some other practices, tactics, and norms that we can follow to make sure that documents can indeed convey a strong, singular message if that’s what we want them to do? I often find that work documents are created for folks who weren’t present at the live meeting. And at our startup, we heavily relied on asynchronous documents as one of our most critical channels for communication and information flow. How can we make sure that readers are on the same page? Or is that not even the goal in the first place?
