Lessons From A Startup
Building a startup isn't easy. Here are a few takeaways from me and Nick (my co-founder).
It doesn't need to be perfect. Just a proof-of-concept, large waitlist, or precise go-to-market strategy with details to back it up. Assume Murphy's law: things will go wrong in any given situation, if you give it a chance. Try to be so prepared that you don't need to take unnecessary chances... but don't let this stop you from taking the right risks. Sometimes you have no other options. Either you do it now or you do it never. But obviously, if it 's not time sensitive then you can postpone risks; however, most startups do not operate like this.
Understand pivoting. Don't get too attached to your idea. Love it, sell it, and believe in it, but when it eventually comes time to pivot (and it always does), be empathetic, decisive, and be quick. Know the in's and out's about why and how you're pivoting. Whether it be mis-reading your consumer audience, regulatory & compliance issues, or high overheads; boil the problems you're facing down to their core. Building the right set of advisors and team can help.
Proactively try to find flaws in your strategy and product even if it hurts admitting flaws to your own idea and vision that you have worked on for months, so that you can anticipate what challenges you might face, know ahead of time what the issues are and how you can best pivot, rather than always being caught of guard and making expensive bets on odds you haven't fully considered. Speaking with users is very helpful in guiding this self-criticism. If you don't ask these questions yourself, you might as well be building a broken product. It will also make it difficult to recruit "smart" prospective investors, partners, or employees, because you will likely not be able to synthesize a strong argument on-the-spot if they point out a flaw in your model. Obviously, you can try to socially engineer people and use various rhetoric devices to retort, but in the end, this is not a timed political debate. You have 15 minutes to build your case and the VC you're pitching to has a team of analysts and as much time as they want. Sometimes you can synthesize a strong argument after-the-fact, but sometimes the flaw might be also be very foundational to what you're building. You should try to identify and fix your flaws or if the flaws lead to you fundamentally being unable to deliver value then you should know that as soon as possible, rather than betting on "dumb" investors not asking the right questions. In the end, as a founder, it is important to lead but even more important to lead in the right direction, because the flaws of you and your company will catch up with you one day if you choose to ignore them or are not bothered to look for them. So be overconfident but don't be oblivious.
If you outsource development, do research inside and out on the prices people pay and the structure of those agreements. Don't be afraid to ask!... about pricing, for referrals, and for a cap on how much you're willing to spend for a given project. Month-to-month development gets messy and for startups, it usually doesn't align incentives to everyones' needs.
Even more important than the price you pay is making sure you properly evaluate the individuals you're working with because price is entirely meaningless if you don't know what quality it gets you. Even if they were well suited for a similar project of another client, they may not be well suited for you: have those developers now left the firm, did they use the exact framework/language you're working with, over what time-frame was the work done and with what incentive structure, etc. Traditional indicators of experience like "10 years experience" are entirely meaningless as a method of describing skill in this field; these metrics are usually used by cunning managerial types to oversell. What matters are the specific projects they worked on, how they contributed to those projects, and how fast they completed them. Make sure that if you're working with an outside firm, that they have long-term relationships with their developers, rather than hire them as needed. And especially at the beginning, know before you even start your engagement, you should have the names, experience, and CVs of all the developers who will be assigned to your project, even if there are 1 or 2 "senior" devs who want to put themselves--in the end its probably the junior devs doing the grunt work. Also you need to consider the scalability of the firm your working with: will they be able to quickly hire additional resources if necessary? are they over-allocating their resources (if they say a senior dev will work 80% on this project even though he is already assigned to another project, can that really work)? does the cunning managerial type have the skills necessary to properly evaluate new employees, especially if you're working on a tech stack the firm is not very familiar with? And lastly, the sunk cost fallacy also applies to hiring and working with people. Even though you might build up relationships with many individuals at these firms, you have to know when to pull the plug and not let yourself get sweet-talked.
Although project-based engagements are preferable to month-to-month engagements due to their costs being controlled, they might harm you more than going m-t-m. In the corporate world, where the scope and strategy are usually set in stone and known long in advance, project-based engagements are perfect. You might try to emulate this safety in the startup world, however, because the scope, strategy, and timelines are usually always shifting, it is basically not possible to lay out a concrete scope at the beginning of the project and you just end up paying for a more expensive version of m-t-m. In come cases you can find subsets of your scope that you know with great certainty won't change, however, you should almost always choose agile, high-quality people that can pivot over the apparent safety of a project-based contract.
Ultimately it boils down to a simple fact. If you cannot trust your devs to deliver your project in the timeframe you described in a m-t-m contract, then (1) you didn't explain or define the scope well-enough, (2) your developers/firm don't have the necessary skills/expertise, (3) your timeframe is unreasonable, or (4) there are too many uncertainties about what you are trying to build (which will will be exacerbated in a project-based contract).
The best way to fine out which one it is, it to talk with as many firms as possible, asking the devs to explain the scope back to you, which specific high-level steps they would take to achieve the scope, and what challenges they think they might encounter on the way. If they cannot identify at least a dozen very specific challenges unique to your product then they don't understand your product well enough or you should be very concerned if you don't already have another competitive advantage beyond the "coolness" of your product.
Know your consumers (it's easier said than done). It's natural to want to appeal to many people at once and be indecisive. Find out your target audience. Are they gen-z, millennials, gen-x, baby boomers? How is their income/wealth? Does their gender or ethnicity matter? What do they value and what are the metrics for those values? To know your consumer is to know your branding and help you as a founder build company values.
The most important aspect of knowing your consumers is talking to your consumers. Often times you might generalize your experience of belonging to a specific group (generation, ethnicity, etc.) or that of your friends as a way to find out the needs of your consumers. There are two main issues: (1) if you are building a startup at 19, you are likely not representative of the group your are trying generalize for and (2) you are underestimating the out-group homogeneity effect. If you are trying to make assumptions about groups you are not even part of then just stop right there, because you probably misunderstand what it means to be part of that group. Obviously, you can use assumptions to generate initial ideas, but it should go no further than that.
Although for day-to-day life we often encounter statistics and group individuals by external factors (age, race, ethnicity, gender, income), this should not be your first go-to for defining consumers. Try to think beyond the groups defined by extrinsic factors. Through speaking to users, start by trying to define your groups by intrinsic factors (beliefs, motivations, hardships) and use that understanding to extrapolate to external factors, so that you can easily identify such consumers while still having a deep understanding of their needs. You will find product market fit much faster and be less dependent on assumptions.
Of course we founders want to her that our product is amazing and that the problem we're solving is really a burning one. However, if after speaking with many consumers, with them clearly understanding the pain point you are trying to solve, none of them seem to find the problem you are solving meaningfully painful, then you should take this as a sign to rethink what you are building, rather than to ask questions or do experiments in a way to evoke the answer you as a founder want to hear. Don't massage what your users are saying to fit your confirmation bias. If you do, you might end up building an expensive solution in search of a problem that doesn't exist. This is especially problematic if you are late to the market, only building an incremental improvement over what other well-funded competitors are currently offering, and for a problem that people pain point that people don't really feel.
Create buffers. Whether it be a lawyer, mentor, advisor, investor, colleague, etc, find people who can give you a reason to do the diligence you need to make certain decisions. (Hint: consumer interviews can be the buffer too. A lot of time as a founder, you may think you understand a situation more than you actually do. Make consumers feedback your buffer and see what your target market has to say.) If an investor offers you a price and is pushing you to take it, you'll be able to say "I'm super excited. I'll run this through ___ and I'll be sure to get back to you soon." It goes for just about everything internally and externally in a company (hiring new employees, fundraising, dealing with disputes between founders, etc).
Find out why others failed. Was it not the right time? Lack of capital? Regulatory & compliance? Wrong team? No product market fit? Reach out to as many people as you can -- this information is gold.
Don't stop with the first answer you hear to this question. Different people will give you different reasons as to why something failed. Often people will also blame their failures on external factors even if they are of their own making, so you need be aware of this. You need to get all the reasons to have a good understanding.
Don't make assumptions about why others failed if you are unable to get information about why they failed. It is more harmful to make false assumptions than to be unknowing but aware.
Don't use the failures of others as an argument for your success.
And most importantly, always be aware of your confirmation bias. Especially if you are passionate about what you are build, you might be interpreting someone else's failure in a way that is most convenient/beneficial for your situation, even if in reality it should be seen as a yield or stop sign. We founders are most likely to do this when we see a company very similar to ours.
Always ask twice. Try to have multiple experts you can ask about information critical to your business and product. Especially if you are operating in an industry as opaque as the financial space, a single person will often times not know the full picture and unknowingly make assumptions based on their previous experiences. You also need to have the conversations as soon as possible. Even if an expert tells you that you should have nothing to worry about, you should continuously find other experts who think the opposite; only that way you can have the knowledge to create a resilient and agile strategy.
Good read Sugg. I can echo plenty