Surviving the quicksand of building new products from the ground up

4 min readJul 29, 2019

I’ had the chance to be part of a tiger-team dedicated to build a new project from the ground up. I know the taste of failure, disaster and success.

In this post, I share my thoughts on how to fail fast, succeed and make it through a hell of deadlines.

The Tiger-Team’s structure

The first step must be right for the sake of success. A technical leader is supposed to set the project architecture, coordinate the requirements with the customers and stay on sync with the project manager.

The technical leader got a big batch to handle. The development should be led by the technical leader. Having up to two experienced developers will make it through the first successful prototype. A successful prototype is delivered on production standards.
The Junior/s: Helping with maintaining the E2E testing, minor DevOps issues and Compliance.

Amazon has the thumb rule of two pizzas. I think the two pizzas would suffice for a tiger team. Since challenges gets real quickly, the team needs twice the amount of cholesterol and carbohydrates.

Study the facts

The stakeholders part requires a great deal of devotion: who are they? what is the scale? what’s their goal and expectations for the system? what are the requirements and deadlines? How much dynamic and flexible the requirements are? How they will reach the product?
Study the competitors and the market. It saves a great deal of time and help the team to spot the blind spots in knowledge.
Rethink the requirements! Don’t let the confidence trick you. Use data and evidence.
What is the success story of the product that the tiger team images?

Understand what’s in the domain

Understanding the requirements and the goals of the stakeholders will put the product on the same track. Understanding the competitors best practices will chart the territory of failure so it can be avoided.

Demo and the Quicksand

Any developer can hit the keyboard and write a code that compiles. you can find hordes of them in any cube farm. Getting it right is a whole different case.

I remember a time when I started the Friends Location, who happened to be sort of a new idea. I visioned my success by working fast and getting the app up on google play as fast as possible.

Several months later, I wanted to add some new features. It was impossible to commit anything without destroying something else — the programmer hell. Oh dear! despite the brainpower and motivation, I was swallowed deep in the quick sand.

What went wrong?

1. I had to acquire the right skills to get the design right. Such skills require a great deal of dedication which any young developer lacks.

2. My prioritization for what is Urgent and what is Important was incorrect.

Charting the loose sand spots

I had to understand the two greatest value of software:

Behaviour: This is the Urgent value of software.

Architecture: This is the Important value of software.

I should have prioritized as follow:

1. Urgent and Important

2. Not urgent and Important

3. Urgent and not important

4. Not urgent and not important

The architecture should be considered in the first two stages while the behaviour comes at stage 1 and 3.

The behaviour concerns the stakeholders is urgent and there should be a demo ASAP to better track the advancement. Usually, when you ask the project manager about the how to prioritize the architecture, they will put it last, thinking that the stream of requirements could be applied with minor modifications. However, reality is different. Relying on future refactoring is not an option as the requirements stream will keep flowing. Making such refactoring a fictional goal.

Myth busting

I was surprised when I follow a well designed and TDD(Test driven development), a less time was required to accomplish the first demo.

The first version of Friends Location took me almost a month. However, after starting from the ground up with the right prioritization, it took me almost 15 days.