While looking over some presentations of new software projects/companies, it was hard to ignore the fact that some of them had missing major functionalities or even worse, the investors were pointing out some showstopper bugs. I’m talking about new companies, young ones, that probably got already a round of investment.
Other thing I noticed was that some companies, after 6 to 12 months after their initial investment, end up drowning in bugs and refactorings which are causing dev work to hinder and not develop new features as planned. Those missing features are often the reason of a failed second investment round.
Of course, these are the worse case scenarios and it’s not happening for ALL the startups. It’s not something I wish, it’s just something that I see everyday. All the major sources specify the same kindof news: “About 90% of startups fail. 10% of startups fail within the first year. Across all industries, startup failure rates seem to be close to the same. Failure is most common for startups during years two through five, with 70% falling into this category.”
Identifying this problem, I took the role of the CTO for a testing company. The main goal is to help start-ups building quality work. This is what it matters, because others success is our success. Our role is to bring expertise and fresh perspective to projects, contributing to the overall improvement of software quality within an organization.
So, how important is QA for you, and when do you decide it’s time to invest in it? Have you seen good ideas not getting investment because of bad quality? How is anybody overcoming this?
A lot of big established companies are drowning in bugs and needing to refactor too. Thats software.
You’re right. But also those big companies have legacy clients. They have a client base that accept those bugs.
As a tester, it’s in my DNA to see less bugs in production. Don’t you get mad when you see easily fixed bugs in very known apps? Don’t you start thinking how fast you would’ve fix those bugs and why are they present in prod?
Frankly I see much more of the opposite problem: startups waiting way too long to ship because they’re trying to fix all the bugs / set it up to scale / etc.
But that’s not what qa does. Or at least, this is not what I want to do. You are seeing qa as someone who’s doesn’t want to ship fast. You are seeing qa as someone who tries to fix all the bugs. This is not a health qa approach.
As a QA accelerator, we want a very short TTM in order to get fast feedback. We know that fixing all bugs could sometimes be a waste of time and effort, so we agree upon proper prioritization. QA doesn’t mean moving slow!
Don’t forget that there isn’t dev vs qa here. We all want the same thing. Quality in production.
Things startups should not pay for until they have figured out that they can make money doing so:
- Legal
- Custom website
- QA
- Office space
- Hardware
Niiice! Let’s agree to disagree. I think there’s big a difference between “should not” and “choose not to”. The world is full of different projects and ideas, each needing their special something. This could mean a legal department, an office space, or hardware, qa, etc.
Generally speaking, you invest heavily in quality once you have product market fit and therefore have a churn problem less related to the product features and functionality.
The common adage here around product market fit is that you want to be selling water in a desert - your customers don’t care that the water has some dirt and sand in it, they need it and are tolerant of its imperfections.
With a cash strapped startup you do need to deliver version one fast and version two right. If you take the time to it right at the beginning, chances are that you will run out of money before the product is even out.
Worse, you might work your ass off building something polished that will not resonate with the market and generate any sales - so you will have to redo it all anyway. It is very very very very rare that a startup nails the product market fit on the first try.
Yup. Version 1 fast and version 2 right. The problem is that normally feature requests a, b, c, and d come rolling in, and quality updates are postponed to version 3. Then, with a growing customer base, in comes half the alphabet in feature requests, and quality updates are postponed to version 4, 5, or 6.
It’s not easy to balance new features vs paying technical debt. I see building software like buying a house.
Very few young people can wait long enough to buy a house in cash - they need a mortgage.
Very few young companies can afford wait long enough to build perfect software so they need to borrow some technical debt.
Just like your mortgage, you need to pay back technical debt even though you’d like to spend your money (or ressources) elsewhere.
I’ve seen rounds fail because of not reaching sales goals, not proving PMF, market being too small, not solving the right problem. You could say I’ve seen rounds fail because of bad/wrong product features. Never have I seen a round fail because of bad product quality.
Interesting take! I don’t think you’re wrong - just a surprise.
I don’t think you’re wrong about the importance of QA. But not in early-stage startups when speed is the most important thing. We didn’t have ANY tests written before raising our (pre)seed round and expanding to another market.
Then, development slowed down, it took 30% more time to launch new features and test them (which is an eternity in startup world.)
I never had ANY investor ask me if we’re writing tests, what does our QA look like, how are we ensuring product quality. What ALL of them asked is - what’s your churn. If the churn is high, then there is something wrong with the product (wrong features, bad UX).
I don’t know what you do exactly, I just commented because of the round sentence, but I don’t think early-stage startups are your best target group. :) Except for maybe fintect, healtech, industries with big consequences if something goes wrong. I imagine QA is more important for them than for random SaaS tools.
First, thank you. You raised some very interesting points here.
You are right about investors. They never ask about testing, but honestly, they don’t ask about programming languages neither. Or if your backend is using sql or nosql. They want things done. They are usually non-technical and they don’t want to get into these kind of details.
Or product is not just testing for bugs. Or main focus is to create a mindset inside the young organization, that keeps testing on the table. We try to ensure that each stage of software development aligns with the quality standards. We push for Agile and DevOps. We try to be the end user advocate and raise potential business issues. We try to find defects earlier in development because it’s much cheaper than finding them in production.
And no, all of the above is not taking more time. QA doesn’t mean loooong development time, loooong processes and loooong time to market.
You’re also right about the numbers. Those statistics are not all about bad product.
I’m an experienced software developer who’s just dipping his toes into entrepreneurship again. I don’t mind moving fast - I’ve had to do that plenty! But I’m also a sucker for quality, security, performance so I need to remind myself what I’m doing sometimes. I’m currently building something simple that is somewhat niche but proven market then use it to learn more about the sales & marketing side of things. It’s a product that’s centered around security so I have been taking my time with it especially since it’s relatively small. Then I’ll be more well equipped for a larger undertaking. At least that’s my plan!
I worked for a startup as a developer. It was more important to add features that bring on customers than to appeal to some standards that the developers want. When bugs come up you fix them. Once you find a buyer you start maturing.
> "About 90% of startups fail. 10% of startups fail within the first year.
Yeah but often this is not due to quality issues alone. There could be more fundamental problems with product-market fit (unless you are defining quality so expansively and calling lack of demand as always stemming from poor quality product). As a QA guy, that seems to be your axe though tbh…
I stand corrected. The numbers I displayed earlier were not product related.
Those missing features are often the reason of a failed second investment round.
Can you back that up with data? In my experience, shipping new features only matters insofar as it affects usage and revenue metrics.
One in particular that comes to my mind is: Jawbone One other personal favorite is Karhoo: The problem was that app codes never seemed to expire and people would use £100 worth in free rides.
There’s also Quibi. Here it wasn’t only product, I admit, it was more of a multiple reasons to fail, but bad product is one of them.
There is a very big list of startups that fail due to bad product or judgement. I joined my company in order to help others avoid this. It’s not my intention to actively not release fast in production. It’s more of: release fast in production quality work.
The word quality has different meanings to different people in different contexts. In my experience, a lot of these conversations are oversimplified to the point of uselessness. I can build something that doesn’t work infinitely fast.
There’s two sides of quality: what the customer experiences (how well are we testing our idea against customers) and what the internal folks experience when they try to add or change what we already built (how fast can we iterate). You can define what matters, or you can tell everyone to “go fast and not worry about quality” and let them each decide what trade-offs to make independently.
QA is never a priority until you start having outages every week in production, normally around series A if someone in the engineering has a quality mindset or series B if clients churn because of unreliable product this starts to be a concern.
QA adoption within engineers is cultural and it takes time to mentor people, create processes, and adopt those processes, in my experience the tech side of it is the easier part to put in place.
Helps tremendously if the CTO or VP empowers QA from early on.