This article was originally published in The Hatched. It was written by Samuel Beek and edited by Wytze de Haan.

As a product manager, I've always been fascinated by understanding what it is that makes some SaaS companies succeed in making products that conquer the world, while many others try and ultimately have to admit failure.

I truly believe that high performing SaaS businesses run on a success formula and there's no better graph to prove my point than this: once SaaS companies hit their first $10.000 in annual recurring revenue, the speed at which they grow is exponential.

There's a holy grail in product development that every SaaS business dreams of designing into their product. It's called the ‘compounding growth loop’.

On a very basic level, a compounding growth loop is when you make it possible for your product to become more valuable to users upon using it more often and with more people. Compounding growth loops are what make products like Facebook, Pinterest or Slack so successful: the more of your friends or colleagues you invite to it, the more value you get out of the product.

Having worked on many SaaS products myself has made me realise that highly effective product teams don't just try to design compounding growth loops into their product, they also borrow the concept and implement it into their own strategy for guiding product development.

Each new product decision they make becomes infinitely better because they feed the results of the previous product decisions back into their decision making process.

Sound complex? I've broken it down into what I will now dub the SPA-model™ (Samuel's Product Approach) for highly effective product teams:

Building great software is all about effective time and resource management.

SaaS startups usually have a million and one great ideas parked in the backlog of their roadmap, but development teams have limited time and are an expensive cost.

Most product managers spend too much time debating the “right” decision, where instead they should be making “a decision”. The problem with too much debate and too many opinions is that a good decision will rarely make up for the time and productivity lost by taking the momentum out of your development team.

This isn't a new thing: Maimonides, a jewish philosopher, already wrote about this in the 12th(!) century: “the risk of a wrong decision is preferable to the terror of indecision”.

All great digital products go through iterations, not in the last place because you won't get real user feedback until you've shipped your idea and it's up and running. It's more important to decide with speed than to get things completely right the first time.

Instead of getting bogged down in looking for endless data to support your hypothesis, look for confidence. Ask yourself what the minimum information is that you need to be able to champion making this product decision. What would convince you that there's a realistic chance the idea will work?

It's always better to ship fast and evaluate after, than to get stuck trying to find consensus on how to move forward at all.

Now that you're making decisions fast, let's revisit how you can actually avoid crashing and burning the company by not making bad decisions all the time.

Product management is strangely similar to investing. There's a concept we can borrow from the world of investment that will help you learn from each decision you make — whether bad or good. One of the most successful hedge fund investors of the world, Ray Dalio, lives by a mantra that best introduces this concept:

If you’re moving fast, it’s acceptable to be wrong on occasion, as long as you can use the learnings to be right the next time. In order to do this effectively, you need to establish a hypothesis for each major product decision and evaluate whether it played out as you had intended once you have enough information to evaluate.

By making your assumptions explicit, your evaluation will be much more valuable:

Either way, wrong or right, you're learning.

Remember that ‘compounding growth loop’ I mentioned earlier?

As you start creating and validating new product hypotheses, you should start bundling them together into a document that helps you make more informed future product decisions by encapsulating all of your wins and failures.

I call this living document your “Product Framework” and it's essentially a bible that your team should reference every time it makes a roadmap decision. It's also extremely useful for onboarding new employees and making sure that product knowledge doesn't leave the company completely when senior members leave the team.

As with many living documents, they can become unwieldy the more they are used. At a certain point, it can add value to distill the majority of your confirmed hypotheses into proven insights that relate specifically to core product questions like “who is our user?” and “what problem(s) is our app solving for them?”.

Your marketing colleagues will usually have comparable insights to the same question, so it can be valuable to compare notes or work on the document together.

How do you keep development teams happy and productive? Now there's a question many management teams have grown grey hairs pondering about.

When productivity falls behind (for whatever reason), many companies will look to tooling or training as a means to solve the problem. There is no shortage of consultants that can advise expensive trainings like Scrum or Agile, but I have yet to see these methodologies significantly impact a product team’s performance.

One place you do see a lot of highly productive teams is at Hackathons. Whenever I'm at such events I have to laugh when I hear puzzled business people try to figure out how it's possible that developers are so productive in comparison to their normal way of working at the office and while working on a project that doesn't even pay them!

Then they try to organise internal company hackathons and it doesn't work. The reason it doesn't work is because they copy the wrong ideas.

It's not the event format that makes people productive, it's the fact that they work in a small team towards a clear common goal. There's no process, fancy team methodology or an appointed Scrum leader, just the shared goal of creating something that's ready to ship by the end of the Hackathon.

Interestingly enough.. it works. Teams figure it out as they go. If they need to address a roadblock, they will. If they need to do research, they'll make it happen. As long as product teams are motivated and excited about what they’re doing, they will figure out how to get there without the need of any predefined process.

The companies that struggle with their productivity usually have a very different issue: often it's a result of being unable to explain why or how the work their teams do contribute to the overall success of the company.

The Product Framework can solve this, because it explains why the work matters. It reminds everyone why we're building what we are and articulates the potential impact a positive outcome of a product decision could have on the success of the company.

Even in the case of a negative outcome, the Product Framework helps remind everyone that even a failure helps create learnings that become the foundation of success.

You don't need to implement a Product Framework to perfection in order to still get significant results. Even an MVP of this process will help you speed up your decision making and help communicate the why behind important decisions to everyone with a stake in helping you design a product that will conquer the world.

Interested in hearing more about how I've implemented this myself? Feel free to reach out via Email or Twitter. Also, Veed.io is hiring!

This article was originally published in The Hatched. It was written by Samuel Beek and edited by Wytze de Haan.