what early startups value
Not all startups are created equal. Paul Graham defines a venture or entity that has the potential to grow fast. Often, people conflate the term to mean something that raises capital for growth. And if it doesn’t, it’s bootstrapped.
Most often, people use the term startup to define a trade with the hope of building a venture that can potentially grow through raising external capital. And given today’s fund structures external capital is seeking a 100x return as there are plenty of options to invest under the lower risk asset returns (i.e real estate, public stock, commodities)
Why does this matter? Because raising funds inevitably reduces your optionality. You’re looking to build something that can scale where the product or service can be replicated at no or low marginal cost; and software provides the highest leverage leading to startups being software or software enabled companies.
Given the majority of products lean on software as an enabler, early teams predominantly have a higher breakdown of technical roles. So having a technical role or being closer on a technical spectrum is a favorable skill. Note, people often misconstrue being technical as writing code but its a much larger spectrum.
Here is a breakdown of some hybrid skills that be valuable to any team particularly at the earliest stages.
Being a product manager with data analysis skills and setting up product events in app or write relational queries to build meaningful KPI dashboards is an easier and valuable skill to master. i.e Segment, Metabase, Zapier, Airtable.
Designer with the ability to write html/css and often build entire marketing sites or functional framework components that can be handed over to product engineers can help minimize the back and forth and QA process. Webflow, Framer, Storybook, Figma > code conversion tools.
Marketer with the ability to setup and build instrumentation and processes for your own growth and lead generation experiments. i.e Google Analytics
What has favorably changed in the last decade is the explosion of no code tools and workflow tools that are often built with these roles in mind. It might still require reading the documentation or going through videos on how-to’s but the integration process is often interactive and requires at most dropping in code snippets.
Generalists are often favored to specialists or specialists with complementary skills that they do not often possess but are open to trying. Conversely, for technical candidates being able to write, sell, design and be willing to help outside your core role can help you stand out outside the pack.
Given the lower cash salaries and lack of PMF, early teammates are often self-selecting with members that can deal with ambiguous roadmaps but still construct concrete products. Unlike writing and discussions that are often nuanced, writing code is a workflow of binary decisions. You can “checkout” the items in the cart for purchase or you can’t. There are a concrete number of flows and screens to complete any task. Regardless of your team’s vision, you are building multiple skateboards that will solve a problem for a type of user, and disregard the endless edge cases. Building products with edge cases, through testing is often a luxury and learning to build a muscle that favors how to build for 1 user over a billion gives you more trials that the core need is being met.
On that note, building something for 1 user can often be done as a proof-of-concept so consistently demonstrating the ability to hypothesize, design, build and test this iterative loop is often the most underestimated skill.
Given the explicit nature of product teams to have discussions and think critically which are sought after skills to build robust systems, they often lead early products astray. The term commonly used by software engineers to describe spending excessive time on trivial decisions is “bikeshedding”. But early products are subjective at best to define what is trivial.
Instagram added filters well after it was released to the public, but without knowing if the experiment was going to work, spending a week deciding how many filters and what filters to select could have simply been tested in a matter of a day. The contradictory advice I want to present here is that teamwork through experiments is less favorable because that decision making process inevitably takes more time. The benefits of being “exacting” and finding the PERFECT filter is less valuable than trying ANY filter.
While speed is the emphasis given at early stage teams, it’s not the entirety of the story. Speed of delivery provides quick feedback loops, reduces “bikeshedding” conversations and reduces edge cases that might not matter simply because the value of learning if this product or service is going to be valuable is greater than all the process that goes with building products and services that work 100% of the time, handle every case or can scale to thousands of users.