Startups fail for the same reason you might. The typical failure case for startups include no market need and failing to pivot quick enough. These are also risks faced by larger companies but they're harder to notice. A typical solution from leadership is to remove processes and promote behaving "like a startup".

One does not throw process out the window in order to succeed. If this were the case; injecting chaos into a team would be the dominant strategy.

The key to running a successful product team is to establish a culture that seeks to aggressively shorten the time it takes for the team to make mistakes and learn. Shipping the wrong thing in one week is better than shipping the wrong thing in 6 months.

Long Term Risks

Long term plans lack the existence of genuine feedback, instead feedback is received on the idea in our head and how the idea is perceived in someone else's head. This misalignment is one of the risks we bake into the development cycle among others that aren't obvious when we have a long development horizon.

A plan is the route we take from the current state of the world A and the world we wish to exist B. When we commit to the plan we are hoping that this new world will be the place everyone wants to be. If 11/12 startups fail this indicates we are generally bad at envisioning futures.

Quarterly releases has the risk of assuming what is true today will still be still in three months and that everything will go according to plan during this time and not be derailed by something that takes priority.

If things do go according to plan and we get to release, the best case scenario is that the vision is only three months old. However in reality one learns, ideas mature and the state of the real world can change in a short time.

Long on-going projects are hard to back out of. Admitting defeat is hard especially if a competitor fails finding product market fit for the very next thing you're waiting to release. There's the sunk cost fallacy, political stake, emotions and the missed opportunities from having to sit down and crunch in the last minutes of release. Even having your head in the problem can help you realise that it might not work out and we have to ask ourselves if we've reached the point of no return.

A project that is under an on-going and long product iteration cycle needs to constantly reassure stakeholder that everything is alright and will be alright. Additionally there's the pressure being applied from shiny new ideas that have novelty appeal and are more exciting to talk about than the thing we've been actively working on for the last two months.¹

These are all systemic risks that are not built into the product but are built across the delivery process. A company that releases quarterly has a minimum reaction time of 3 months.

What can we do?

We have two goals. Find out what is valuable and minimize the time it takes to deliver that value. Ideas are cheap, customers pay you for what you release they don't pay for what you plan.

Learning comes from the user and you can skip discussions or second opinions. Getting something into the users hands is the opportunity to learn far more than you might from a peer. Spending 2 weeks to fail is far cheaper than spending 3 months and now you can take what you've learnt into the next cycle.

Successful startups are skipping advise from the experts and just seeing what works. Senior leadership can sometimes hold innovation back and a little naivety can go along way. We need maturity to say "I don't know" and bravery to say "Let just give it a go".

Identify the processes that are busy work, work that feels productive but slows down your ability to release. This could be planning meetings with teams that have nothing to do with your project.

Focus on development that gets you signals instead of releasing fluff. You don't need to release the entire picture, if you have the opportunity to release only one thing and that thing helps you determine if your vision is wrong, you shouldn't be building anything else.

Do some now

Delivering something now is better than delivering it all at later.

Don't delay learning, if you release a product to the world after months of working on it, you're going to be doing a lot of "learning" after that release. Only if it's not incredibly hard to separate that parts that are cruft and the parts that are valuable in this release - it is far easier to learn iteratively than it is to learn while you're putting out fires.

There are no rules, you are allowed to release something and have users find it by chance or selective introduction. Releasing a feature is different from announcing a feature. Some users might never come into contact with the feature, and those that find it might ignore it since it doesn't fit their use case. It is fine for things to not be a fit for all customers, but the users that find it's useful have had value delivered to them without you needing to complete the entire project. To these customers you've done this quicker than expected and now you're being paid earlier than expected.

Value can be delivered even if it requires manual work. Managing to automate 40% of the workload while requiring the rest to be fine-tuned from the user will be seen from the determined customer as saving them 40% of the time, they won't see the job as half done. Their concern is getting to market, they have their own competitors and you've just given them a 40% head start. Had you not released early, they would have to do the 40% themselves anyway.

Waiting to serve all use cases delay some of your customers when they could be using that time to make their money. Doing 20% of the work might be 10% more than a competitor, and releasing sooner positions you better and can de-risk churn.

Are your customers even asking for it? You can get through releasing 10% of the plan and suddenly all your existing customers adopt the feature without you needing to sink time into the other 90% of the work that you had assumed would be needed to convince them. Ditch the plan, ask them what's next.

If there's one truth or take away from this post; it's that the importance of something being done diminishes over time so the sooner something is delivered the higher it's overall impact. No matter how small.