How to map your startup business process?
I strongly believe that every team member must understand the business process, especially an engineer that is going to translate it to the code. Joining greenfield projects differs greatly from joining big companies. There is no documentation, no preexisting code that can be reverse engineered and very vague understanding what is actually expected. An engineer cannot expect that founders will provide clean acceptance criteria, because they usually figure it out on the fly. This means that sometimes an engineering team feels like they are doing circles. This is difficult on both ends, especially if “the business people” have little to non experience working with engineers. Everyone has expectations stemming from the way they used to work, their background and there is a need to establish a common vision for the whole team.
Ways of working are a subject to change especially when the team scales. If an engineering team grows from 1 to 2, it is 50% of the team that has to be onboard, however usually have a different set of practices. Processes change whether we like it or not, so the best we can do is to invite new members to contribute and get some buy in.
Tools
There are tools designed to build a shared view and discover solutions. First that I would like to mention is Design Sprint from Google. Citing the authors: “Design Sprints quickly align teams under a shared vision with clearly defined goals and deliverables”. There are 6 phases:
- Understand - to create a shared knowledge base across all participants
- Define - define a specific context and desired outcomes of potential solutions
- Sketch - generate a broad range of ideas
- Decide - decide the focus of the sprint
- Prototype - build a prototype for the concept
- Validate - put the prototype in front of users and get feedback
That can be used separately, however authors suggest using it all together. I have been a participant in a workshop including phase 1 and must say it was intense. I will definitely cover a full cycle in the future.
There is also a Domain storytelling workshop that aims to express the process in the form of a graph with the use of pictograms, in the spirit that “Sometimes three good examples are more helpful to understand the requirements than a bad abstraction”.
There are a number of others (mentioned in the references section), yet my favorite is Big Picture Event Storming. In the linked article you can find an in depth coverage of the topic. The process consists of following stages:
- Kick-off - an introduction to the domain problem
- Chaotic exploration - everyone puts important events in the system on orange sticky notes and puts randomly on the wall
- Enforcing the timeline - all sticky notes are organized in a way that forms a timeline of events
- People and systems - events are triggered by a person or a system, they are introduced as new sticky notes
- Problems and opportunities - instead of resolving every issue during the workshop, we put placeholders on the wall to state problems or opportunities
- Pick your problem - prioritize the work
I love it because it is very lightweight, involves all the people in the room and spans engagement. It guides in building a shared vision of the business process and addresses misunderstandings early on. I have used it a number of times and I am always surprised by the results. For remote teams I strongly recommend using miro.com
Practice
Kick-off
In this phase we want to cover the background of the project and high level goals.
In the previous article we started running an imaginary startup with the following mission statement “It is difficult to grow plants, that is why we want to help plant owners to grow their plants and keep them alive”. We started very small by running a hypothetical Facebook Group focused on helping people grow plants. It caught the attention of a 10000 users who became active members, and we started seeing people repeatedly asking similar questions like: “I live in X, I have very little sun in my apartment, but would like to have a 1.5m plant with big leaves, What plant do you recommend?”.
As our mission is to help plant owners, we decided to build a tool that will allow people sharing their experience with growing plants and others to use the knowledge to pick the right plant for them. (There are other ways to address this, I chose this one, from an educational perspective).
Chaotic exploration
This phase is best executed in teams, there are 2 of us working on this. It starts with putting all the important events on orange sticky notes. It is important to use past tense in this phase.
After this stage we got following result from our 2 participants:
It is typical that different people have different focus, some provide more detail than others, some focus on technical aspects like “a record is saved”. Notes can also be written in very different ways. There should be no judging, this is a safe space for our team to innovate!
Enforcing the timeline
In this phase we all together try to introduce a timeline, by putting sticky notes in the right place of the process. We got the result below. Dotted rectangles group notes that basically represent the same thing, so we can just keep one of them. Notes in the same column are considered to happen at the same time.
Usually at this stage a common vocabulary starts to occur, giving us a hint on the domain elements and stages of the process. On the left hand notes refer to reviews and on the right to search. I did a small cleanup: removed duplicates and replaced some notes with the “common vocabulary” to make it more readable.
People and systems
At this stage we introduce actors in our system that trigger actions in the process. Yellow cards for people and pink for systems. In our case there are no system triggers, that’s why there are only yellow cards. If we decided to add schedulers, email sending, webhooks etc, these would be our system actors. Even though multiple actions could be triggered by a generic “user”, or “client” it is good to introduce a named role for the sub-process.
Problems and opportunities
During the previous 2 phases, there could have been some misunderstandings, or places that could cause some problems. For example 2 stakeholders cannot agree on vocabulary, or how processes diverge. It is a part of the process to not talk about such problems for too long. It is a moderator’s job to stop such discussion, put a red note on the wall and leave it for another day. However, as this is innovation happening, participants can come up with opportunities that are not necessarily a part of the current process, but could bring a lot of value to the product. Opportunities are added as green cards
Pick your problem
Real life scenarios tend to be more complicated, that’s why there is an even bigger need for prioritization.
In our case we can clearly see two sub-parts of the system. One related to review submission, second to plant searching. At this stage we decide to start with the reviews, as data provided in this part is displayed in the search.
Summary
Today we have made the first step in building an MVP. It started with mapping a business problem that is going to be translated to designs and code. We used the Big Picture Event Storming technique that helped us visualize the process and split it into sub-processes. All that with a bit of fun and sticky notes!
We are one step closer to actually building the thing!