Cover
Michael DubakovFibery founder
Essays

Practical tips on how to understand when to close a startup

April 21, 20215 min read

As long as I’m an entrepreneur, I never had to give up a company. My very first experiment with being a startup founder turned out to be relatively successful. At the same time, our company had to shut down several products (a game and a couple of mobile applications). But right now, we are making Fibery. We started in January 2017, and by April 2018, as a startup, Fibery still wasn’t in production. Was there a need to close the project, then? Or was finalizing it a smart choice? Did we need to review the whole business model already then? What does it even mean to finalize? Let’s figure it all out, step by step.

The average reasonable period for a product company to muddle through without customers is about a year. This is about the timespan the team can keep sanity while not getting any feedback from real users or potential buyers. Sure thing, if the product is very sophisticated, the first release may take several years. But if we are not talking about rockets, for a software startup, one year is about right.

After a year, the team gets frustrated with existential thoughts like “Who needs all that, anyway?” and “We haven’t come up with anything groundbreaking, so this startup is probably going to fail.” Obviously, such questions aren’t exactly good vibes for a startup, so you need to try very hard to avoid this phase before the product release.

Sometimes, something useful (say, a great product with a unique value proposition) can be made and released in three months. Your case? Go ahead and release it asap! In all other cases, I’m not a great fan of MVPs, especially in the business-to-business segment, because MVPs just don’t hit as a release does. However, MVPs are extremely good for testing hypotheses.

Personally, I’d never give up a company before a product is released. By the way, the definition of a release is very relative: from a closed beta for a couple hundred potential buyers/users to a public release with fanfares and a live stream on Instagram. I do believe that releases provide a crucial point to encounter your users, and a lot becomes clear in this encounter. It’s impossible to make the right decisions before having worked in the wild. Before a release, everything may seem lackluster, the design isn’t vibing, and the 84 NECESSARY features are not implemented—while IRL, the product turns out to be extremely useful, even an overnight success. Users alone can determine the ultimate product’s value. Without them, you can only put purely speculative stuff on your pitch deck.

Are there cases when it’s necessary to close a startup before a release? When the team has no more faith in the product. If this happens, working for a few more months won’t make any sense: without faith, the results are mediocre, people do sloppy jobs, and the overall dynamics of the team are screwed.

Okay, then, you release a product. What’s the next step? IPO? Inform stakeholders you’re the next big thing? Well, if users are jumping for joy, you’re good to go. But what if they aren’t? That’s the most interesting time! Listen to their feedback very carefully, and draw conclusions.

Useful (thus positive!) are deep, specific requests, such as “I tried to implement your product, it’s kinda okay, but here’s a specific case where your product doesn’t deliver, could you implement this or that feature?” Such queries show that the likelihood of introducing the product into a company is impressive, because people took the time to figure it out.

The negative signal is getting lots of superficial feedback like “Mwah, it’s not better and not worse than other similar tools” or “Wow, it’s very cool but very hard to use!” If this type of feedback prevails, most likely, you’ve made some fundamental mistakes and it might be too late to fix them.

But what if things aren’t tremendously great, but the team still has faith? Set clear deadlines and metrics. For example, we’ll work four more months, and we want ten companies to implement our software and an NPS > 8. After four months, if our software is only implemented in five companies and the NPS = 7, no more pondering when to close a startup. We stop there, because it was yet another regular startup failure.

You’d say, what a shame. So much effort invested! What if we still believe the product will skyrocket! Should we close it anyway? Should we accept the Silicon Valley idea that failure is an essential part of a process and where startup failure rates are sky-high? My answer is really simple.

I work on a product as long as I believe in it. That’s why I work on Fibery.