How We Launched an App With Zero Meetings

Going through the process of designing, building, and launching an app with zero meetings is an accomplishment, given how many companies cannot operate without numerous meetings these days. As a Fractional CTO, I recently partnered with three startup founders to successfully design, build, and launch a mobile app MVP for them. The entire process took just under 2 months. However, during that time we were able to run a Software Development Lifecycle (SDLC) process without having a single live meeting with the 4 of us. We were located in 3 separate time zones (EST, MST and PT) and were a fully remote team.

So how did we do this and what was our approach? Read on and find out.

Tools We Used

We used only 4 tools to help us run through the entire process. Here was our choice and how we utilized each:

Trello

Trello was the main project management system. An important point is – we used it to capture work of any type and not just engineering work. Here is the breakdown:

• Feature Work – All of the product feature work was captured and monitored here
• Decisions – All decisions that we made together were also documented in Trello. This included a variety of decision
• Testing – Any test work that was performed, such as testing the app on a real iPhone and Android for the very first time
• Optimizations – All optimizations that were applied on top of the originally agreed upon product features
• Bugs – All bugs captured during testing.
• Infrastructure Work – Anything related to infrastructure setup, including account setup with App / Play stores.
• Launch Efforts – The initial launch efforts to each of the stores, which were a process of their own.

Additionally, we heavily used the commenting functionality in Trello for discussion, regarding specific work items (more on that in the sections below).

Discord

We used Discord for asynchronous communication, and there was no need for emails. We had only one group channel where the 4 of us collaborated. It allowed us to have full visibility and traceability of conversations. Everyone could follow and catch up, even if they were out for a few days.

Google Docs

We used Google documents as a repository for all types of documentation:

• Product information
• General documentation
• Agreements we made
• AI prompts used in the app
• GTM Strategy
• Branding information and assets
• Research documentation

   

Loom

Although not very often, Loom came to the rescue when a more complex topic had to be explained. On several occasions I recorded Loom videos to explain certain concepts in order to educate the founders, before all of us moved forward with a decision. This proved to be a very valuable and efficient approach for us.

Our Process

There are two key points to the success of our process:

1) It was defined, communicated, and well understood by everyone from the very beginning.

2) It was simple.

Here is how we did it:

Well Defined Scope

Before we ever signed an official agreement, we took the time to define the scope of the MVP. While the details of every feature were not described, we were very clear on what the features were and what they entailed. Everything was captured in a Google doc and later translated to Trello cards.

Having enough clarity but not too much detail allowed us to strike a good balance between having a clear plan and goals, while having flexibility on defining the details. This approach gave us focus and ability to explore and innovate.

Frequent Shipping

The founders had access to a test environment where new functionality was shipped almost daily, and sometimes multiple times a day. This gave them the opportunity to stay very close to the product as it was being developed in real time. They were able to see and test the latest developments on almost a daily basis.

Stakeholder Acceptance

Our agreement was that I would move Trello cards to the ‘Review’ column and the founders, as product stakeholders, would review and accept/reject every change. They were the only ones that would move cards from ‘Review’ to ‘Done’.

There were some minor exceptions, when there was no way for the stakeholders to validate a back-end/infrastructure change I had made. In this case, I moved the cards to ‘Done’ myself and took screenshots which I attached to the card.

Decisions Making

Along the way we had to make several decisions, regarding design, strategy, functionality, design, etc. each decision had its own Trello card as well. This allowed us to:

• Keep track of decisions and their progress
• Have discussions on pros/cons, and options, inside the Trello card
• Align quickly
• Have a record of what we had decided, if we ever wondered in the future
  
  

Trello Comments

This part was a very critical component of our process – using the comments functionality inside Trello. What many teams do is – discuss various work items, from their project management system, in Slack, email, etc. When this happens, the conversation is pulled away from the actual work item (feature, story, etc.). This creates disjointed information and more overhead as people have to go back and forth between project management and chat/email.

In our case, we made a decision at the beginning that any conversations related to a particular Trello card will take place inside that card and not outside of it. Additionally, we regularly used the ‘@’ mention capability of commenting, to get each other’s attention.

Discord

We had a single group channel in Discord where non-Trello items and general topics were discussed. A simple practice that served us well was, starting a new topic with a bolded header such as:

– – – TOPIC NAME – – –

This added to the visual organization of messages and discussions.