Shipping 'fast'

I hear it all the time, "we need to build and ship fast" and very often, it translates into shortcuts that compromise quality. A few months later, I end up in the situation where a band-aid has been used on a bullet wound.

What I have realised is that shipping 'fast' has two meanings. The first one is the mistakes we have all made - speed, which usually means less time spent. The second one is to build for the perception of speed, which is the right approach to building products correctly.

Keep product and business objectives in mind

Always remember what you're trying to achieve. Consider how do the defined success metrics tie back to what you're doing, and to the main objectives.

Understand all dependencies

Gain a technical understanding of how things are built - components, back end structures and data. This makes it easier to see dependencies when designing features, and helps me prioritise deliverables based on them.

Give the perception of speed

The key question here is, "how can I deliver immediate value with minimal effort?" Small, but regular updates give customers the impression that constant value is always being delivered. Customers are more likely to stay more engaged with the product knowing that improvements are being released every couple weeks.

Prioritise constant, gradual progress instead of radio silence for months and then, hopefully crossing your fingers that the Big Bang release of a massive feature works.

Impact for the business

At the end of the day, you could design the best product that meets all of y our customers' asks, but if it brings in nothing for the business, it is not a sustainable approach.

When I am prioritising key deliverables for each sprint with the team, I am also making sure that the added value for customers bring in some positive impact for the business. Simply put, happy customers should mean more business.

Plan well, communicate often

Always work closely with your team and always know what's going on. Break down the initial MVP into mini pre-MVPs that are scoped out carefully (and realistically) for each sprint.

There are three tracks running at the same time - back end, front end and product. At the start of each sprint, the team knows the exact deliverables at the end of the 2 weeks, and the potential scope for the upcoming sprint. Each sprint's mini release would then gradually accumulate to the final MVP release at the end of say 8 weeks.

And on a final note, all of this takes time and practice. There will be bumps along the way before the team starts to run like a well oiled machine.