The Paranoid Method: Red Book Prologue
The Book about Creating Digital Products, The Universe and Everything
Dear reader!
The book was intended to be the method research which I and colleagues use in project practice and which helped us solve traditional problems of this field, connected with quality, timeframes and, most importantly, with the understanding of real goals of digital product creation projects. I wanted to find out what the heart of our “producer’s approach” really is and where the border between my personal work style and common principles to be used by businesses and professionals lies.
The approach described in the book at a certain moment got its name of “The Paranoid Method” due to certain reasons. I’m convinced that truly high-quality results in projects can be gained only by maximizing focus on the main purpose and the goals by holding the general picture in mind, from one side, and, from the other side, by not missing a single important detail.
While working on the book I left the boundaries of researching the method itself and set myself a goal to form a common vision for the business and for professionals on what digital products are and what possible approaches of their creation exist so that all project participants could communicate the same language. It became clear due to this reason, that the book should be divided into two parts in such a way that the first one would be oriented on business and would describe common principles of the method while the second one would serve as a practical guide for professionals who manage the projects, their design and development. The first book is called the Red one, the second is the Black one, with an addendum containing project documentation examples — the White one (White Paper).
The first chapter of the Red Book was published in the autumn of the year 2019. At the moment, the work on the last chapters is going on. The book is initially written in Russian while the English variant of each chapter is published as soon as it is translated, and you can follow the progress at Medium.
Prologue
42
One summer day I came to a media, architecture, and design institute. There was an open-air lecture space crowded with young people. Everyone came to hear a lecture from a girl who was a designer from Denmark. It was announced that she would tell about reflecting the real world in interfaces. But she had her own plans. She had recently written a book, and this lecture was one of the numerous ones where she presented the results of her work. Methodically, page by page on which there were sometimes separate pixels from a button’s upper corner, sometimes a MacOS Finder window with a list of filenames and sizes, sometimes just a blank white space.
At first, it seemed like an intriguing beginning of a lecture, but it was not. Around the twentieth minute, it came clear that everything was serious and would take a long time. I came for the answers but was given questions I did not want to deal with, with the most important being: what do I do here, and why do these people continue listening to this, and why did they want to ask questions at the end? Something was wrong with this world.
If you are, just like me at that moment, questioning yourself about what is happening now and what these two paragraphs are for, do not panic. Everything is fine, here you will indeed find the answers to the questions.
In this book, I describe an approach to digital product creation called “The Paranoid Method”. It is founded in two concepts — project design and producing. Here we do not talk about some universal approach which can be applied to any project. The Paranoid Method is a technology of unique product creation while some of its parts can be surely used in a lot of projects.
Most contemporary books place an accent on certain aspects, for example, interface design and development management. Here I tried to give a general picture, and this book should be looked at as a guide (to the Galaxy) which helps to see the whole process of product creation from start to finish. There should be enough information for everyone to follow his way, come up with his own product concept, design it, add a team of developers, and launch the project. Where needed, I give links to the sources which will help to get deeper into specific topics of software design, project management and software development.
For everyone to feel easy, firstly including me, the book is written in an essay format. If someone finds the style too informal, keep in mind that I wanted to make it even more lively and personal, so, you are not mistaken.
***
Searching for the model of project work where product creation is divided into project design and development was anything but easy. It often happened so that decisions that would become obvious in the future were hidden from sight by the well-established practice of thousands of people. It was uncertain, for which plausible reason you should have taken courage and claim the king to be naked. In my case, I think I did it. For it to happen, I needed to step away from habitual methods and, more of that, to leave the market I used to work at for more than 20 years, to finally find an approach to maybe the same customers but from another side.
I called the work model I found the producer’s model. The key character in such a model is the producer. The necessary combination of competencies in one person in IT industry happens to be extremely rare. Nevertheless, it was clear that this was the most effective model and it was worth it. We took one cinematic industry model of work as a cornerstone. In short, when an investor wanting to shoot a film finds a producer, he in his turn gathers a unique team consisting of all needed members — a screenwriter, a director, actors, and all those who are needed for the work. Just as in that case, when creating a digital product, the main point of approach is to choose only one person for the project — the producer. All the other rest will be done by him — he will lead the project all the way from a concept formulation to the project launch, calculating project economics and gathering a team on the go.
The History of the Question
For my words to not look as not well-founded, I will put the projects I worked on as an example. At first, I founded a company at 23 to make a business management system. At that time, I was already participating in a similar project and my older colleagues had hinted me how a systematic view on tasks helps find non-trivial decisions, for example, our collaboratively invented system of distributed logistic data storage for offline nodes. Working on a product I wanted to go further. Together with a team, we developed a system with a business process editor and a domain-oriented programming language which had a distributed architecture, a dynamical database structure, and integration possibilities.
The creation of the product took two years with the first client being the largest system integrator in Russia at that time. They implemented the system at 150 workplaces. For this client, we integrated the system with his corporate portal for a regulated document flow, and with the warehouse system also. Then we focused on the corporate portal niche by developing corporate portals for Microsoft and TNK-BP, analytical sales systems at Honda and Logitech, and by doing an internal service for an antivirus company. We gained a lot of experience including the knowledge that unprepared attempts of complex system creation without the necessary level of elaboration always lead to problems.
The most interesting projects began when we entered the niche of mobile apps. The first project was a mobile app for the livejournal.com portal. At that time, in 2009, it was at its peak popularity and we created the Android and Windows Phone apps. At that time, we were just finding out the optimal process which would join project designers, graphical designers, and developers. Next came the apps for a newspaper and for a playbill portal. And the publishing house app designed and developed by us became one of the world’s best apps for mass-media in 2014, according to Google. At that time, we had not fully tuned our project process but had fully understood the importance of preliminary project designing and it had been showing results.
Then were the service apps, and it was harder than the mass-media apps which mostly required a good graphical design. When creating the apps for a bank, for an online accounting service, for a federal electronic retail store, and for a travel service, we have been deeply thinking out the technical architecture also. Following that, we came to the conclusion that project development is something more than just user experience design. We took the previous experience of corporate system creation and built a project process which included all aspects of project design — functional, interface and technical design. I think we were the first mobile app development company to have such a thorough approach to product creation, from the design phase up to author supervision at the development phase.
By applying such an approach, we reached the limit of company development. Further growth would require simplifying the projects to work on. But I wanted to move on and try myself at something even more fascinating and complex, and I liked the design process itself, that is why I did not want to work at an administrative position. As a result, I managed to join my company with a friendly one, and in 2016 there appeared a new brand on the market of mobile apps development. As for myself, after a small break, I launched the Eleven Digital Artel where I am now the managing partner and an IT project producer.
The Search for the New Project Model
For the digital artel, I was looking for a brand-new project work model. It was obvious that classical project managers did not fulfil the required task complexity level I wanted to solve. First-class products are always born at the borderline of adjacent disciplines, and even by gathering different specialists in one team, it is not always possible to create something good. There needs to be an integration of ideas in a single person’s head. But even that is not enough: one would also need organizational powers giving the possibility to solve staff and budget questions. Also, everything should be linked to business tasks for which the digital product is created.
This is how the role of an IT Project Producer appeared, along with the Paranoid Method.
The new approach has let us work on big and complex products within a compact project team. Particularly, we have participated in several projects for Sberbank (the largest bank in Russia and Eastern Europe, and the third-largest in Europe) and Visa. Producing and design — the two key competencies of the Paranoid Method — has let us manage the distributed team while involving individual strong specialists and groups of developers from production companies.
Table of Contents
To Be Continued…
