Why startups fail
Many founders find themselves in a familiar story.
It starts with a great product idea. It matured for months and sometimes years while they worked in the corporate world. Friends and family are supportive of their plan, and market research indicates that they’re on the right track. They have saved up for years to bring their idea to life and have even convinced a few VCs to invest in them to help them get to market. All of this is because their idea is, in fact, a good one.
A few months in, they have a team going and the product is coming to life. Product and technology converge and they can finally play around with what they’ve been dreaming about for years. It’s rough around the edges but for the first time, they can see a glimpse of what they’ve been working on for so long. The future is looking bright.
But once they start handing it out to a few customers, reality hits. Nothing seems to works correctly. The website is buggy, the app crashes, servers error out and nobody seems to be able to address these issues promptly enough. Users sign up but don’t stay on. Metrics aren’t what was expected. Adding new features keeps breaking things. Their early customers get tired of the poor experience and move on. If their runway permits, they try again. Otherwise, they move on too.
So what went wrong? In one word: execution. Ideas don’t matter, execution does. A great idea alone will never make you succeed. Executing better than everyone else will.
Getting your company back on track
When struggling with execution, you have to go backwards before you can move forward again. You must assess every aspect of the product you’re building. Your design, technology and team tell a story, and if you listen carefully, it will reveal what you need to change.
When helping companies turn around, there is 3 major areas I evaluate. Their software, their product and their process. When getting all 3 right, you set yourself up to find product market fit quickly. Initial ideas are never complete, and your ability to iterate fast maximizes your chances of success.
The software review
One of the first questions you probably asked yourself when starting is what technology to use to build what you want. You were presented with an infinity of possibilities and have been wondering if you made the right decision. While changing technology mid-course should be a last resort, understanding the strength and weaknesses of the technologies you picked is critical to good decision making. To know if a chosen technology is the right one, you must first understand the product and the constraints the company is working with. Many experienced engineers and engineer leaders can help you make the right decision, but these are the main things you want to look for.
- Does the technology have good adoption in the community?
- Is it adequate to the company size?
- Is the team proficient at it?
- Will it deliver on the product you want to build?
When reviewing software, determining if the architecture in place is good or bad is the next thing to look at. Like a building, your product will collapse if the foundations are inadequate. Too often, this is where problems start. There is a lot of reasons why architecture can be bad, and sometimes, even experienced engineers build weak foundations when working with technologies they don’t master. Your software’s architecture must serve a certain purpose. A 10 people team doesn’t have the same need as a 2 people team. A 10M DAU product doesn’t need the same architecture as your MVP. You must make a determination based on your needs, but also understand common principles of a good architecture.
Separation of concerns - This principle is arguably the most important one. It ensures that even if you have pockets of bad code, your systems are designed so you can surgically address problems in isolation. Poor separation of concerns is the leading cause of costly rewrites.
Data flows - How your data flows in different layers of your architecture determines the integrity of what your users see and interact with. In most cases, you want to ensure your software’s data flows unidirectionally.
Reactivity - A couple decades into the 2000s, reactive products has become base expectation. Your data is live, and your UI should be as well.
Scalability & maintainability - Are things built in a way that you can easily iterate on? This is critical to ensure your business can grow and code often doesn’t scale to accommodate more users or more developers
If your software was a book, architecture would be it’s overarching structure, and your code would be its writing. Bad writing leads to a bad product. When reviewing software, you can’t read all the code at once, but reading through the main classes can tell you a lot about what works and what doesn’t. These are some important things to look for when reviewing code quality.
Language - Is the code actually using the language right? When the engineer doesn’t master the technology she’s working with, the answer is often no.
Error handling - Lack of error handling is one common reason software can behave unexpectedly.
Performance - Poor code leads to poor performance, and you must determine in what exact ways the patterns in use are causing your product to underperform. Either it’s slow or dropping frames, performance issues compound and lead to a bad user experience.
Tests - Depending on your stage and team size, writing good tests can make the difference between things breaking or not.
Monitoring and reporting
In early stages, founders often know things are going wrong, but they don’t know what exactly. Having the right data collection, dashboards and reporting in place can help alleviate the lack of visibility in your systems.
Data collection - Monitoring is about product analytics and error reporting. Collecting just one won’t tell you the whole story.
Dashboards - Is your data actually easy to visualize and understand? Do you have the right dashboards in place?
Reporting - Are you able to detect data changes reliably? Are your engineers notified when something breaks?
The product review
Design & UX
The Design and User Experience are what your users are exposed to the most. It reflects your brand in a way that is unmatched by every other aspect of your business. When building it right, your users will be delighted. When mistakes add up, you will instead build frustration.
Overall experience - This is the subjective impression you’ve had using the product. When you come in with a fresh pair of eyes, what you see are gold nuggets of information that have became invisible to those who have been working on the product for a long time. You’re overall experience using a product defines the quality of the experience.
UX issues - I like to collect specific issues I have with the User Experience. It can be little things such as the keyboard not dismissing when I expect it to, or bigger things like hidden features. A tight User Experience keeps your product intuitive to those who use it.
Consistency - Keeping things looking and feeling the same across your product and communications to your users is key to a coherent brand. Are you building a brand or a patchwork of different looking experiences?
When building a new product, it can’t just be marginally better than your competition. It has to be a substantial improvement to succeed.
Key differentiators - In what way is your product different from your competitors? What makes it better? Why should users move to your platform?
Core functionalities - What is your single core functionality? Is it as good as you can make it?
Competition - How is your main competitors differentiating themselves from competing products? What is their strategy? How are they evolving?
When collected properly, your product metrics will tell you exactly how your customers are using your product. Analyzing them should help you determine what you need to do to build engagement and growth.
Ensure data integrity - Is your data set complete? Is it easy to consume and digest?
Understand product metrics - When reviewing a product, understanding how it performs is key to putting the right recommendations forward.
Make data driven changes - Are your metrics a key driver of your iteration process?
The process review
The Software Development Lifecycle
Founders from the tech world often master the Software Development Lifecycle (SDLC). Those from different industries are learning as they go how to build and iterate on software. When reviewing a company’s process, I first look at their SDLC and ensures it delivers on the fundamentals. It is a process meant to ensure efficient building and iteration, and consists of the following steps that most tech companies will repeat over and over to continue to grow.
Planning - The planning phase should be focused on gathering requirements, defining the scope, establishing goals and timelines. It should be driven by knowledge and data.
Analysis - Once goals are defined, time is needed to define the product and technical requirements, understand feasibility and weigh tradeoffs.
Design - Once all is understood, teams get to design both their product and systems Implementation - The implementation phase is when building is happening. Engineers write code, and the product team ensures it is build accordingly to what users need.
Testing - Code always come with bugs. A combination of different types of testing (team, qa, unit, automated) ensures you deliver a quality product.
Deployment - This is when you launch your team’s hard work to users. As for everything, there is good and bad ways of deploying. Are you communicating changes? Are you monitoring for regressions? Are you automating deployment? A bad launch can easily ruin months of work.
Maintenance - New functionalities means more to support. The right process ensures you keep your existing offering stable, performant and competitive.
While this comes late in the review process, reviewing a company’s software and product will tell you a lot about the people behind these efforts. Bad software doesn’t write itself, and pointing out team deficiencies is critical to get a product back on the right track. When reporting on engineers, I often look at these key indicators.
Architecture / code quality - How is their actual work? Are they architecting things right? Is their code any good? Are they making things better or worse?
Productivity - Many engineers get away with working a lot less than their employer think. When looking at a company’s code and process closely, it becomes clear who produces and who doesn’t.
Cohesion - Individual contributions are important, but your team working well as a unit is even more. Bad apples drag your team down, and understanding interpersonal issues is required to maximize your team’s output.
Less is more
The first time I managed a team, we built a lot of different features at once. My team wrote a lot of code, and it all yielded a fraction of the expected result. My boss at the time told me I was peanutbuttering. It took me some time to understand, but in retrospect, he was right. We were trying to do too many things. It is a common mistake many founders make. Impact comes from doing few things very well. Less is more is a key principle that must be baked into your process so you don’t end up spending weeks or months building things that don’t move the needle. When working with a company, I always look at how much they’re trying to do, and always question their roadmap to ensure that they are not getting crippled by too many things.
Success is multi-faceted, and when helping a business identify their challenges, a lot of of factors must be taken into account. Many companies make the same mistakes, but knowing where to look is the first step to turn things around. Need help getting your startup to execute flawlessly? Let’s chat
2023-02-24 10:22 +0000