How Do Entrepreneurs Decide What To Do Every Day?
I've met with countless entrepreneurs in my career, and I find myself continuously enamored by how they address the question of what they do every day when they wake up. There are a myriad of urgent tasks, and it's impossible to tackle them all.
Entrepreneurial endeavors are marked by significant opportunity and equally significant risk. At Originate, we've learned that once you’ve identified the opportunity, you must then focus on mitigating the risk in order to execute well.
This answers the question of what should be done each day - identify the biggest risk and act to overcome it.
It can be helpful to bucket these risks, and we use four categories to do so: Market, Business, Product, Technical.
It's not only critical to successfully identify a large market opportunity, but to also have an inherent advantage in that market. With startups, this typically comes from an individual with a deep understanding of the market supported by a vast network of connections.
An established company, on the other hand, has the ability to leverage existing relationships to gain an advantage over startups that would need to invest substantial capital into customer acquisition. The current battle for mobile payments between incumbents (Apple, Chase, MasterCard) and startups (Square, Venmo) is a great example of this.
The key here is to have insight into the market trends. Is regulation (or deregulation) changing the industry landscape? Are international markets opening up? Are incumbents losing their innovation advantage? A great vision can express an insightful view on the future of the market.
The leadership of the business will drive all important decision-making. If ineffective, everything falls apart.
This is particularly acute in recruiting. If a company cannot draw in the right staff (from customer success to engineering), the business will falter before it gets off the ground.
Another key risk here is funding. This is a factor in both startups and established companies; investors need to be convinced to fund the effort. Capital injection can come through a VC with funding from their LPs, management pulling from profits, or customers with money from their pockets.
Every venture needs a clear path to funding. The business model and milestones need to be designed to mitigate this risk. If you’re looking to attract a VC, you need to recognize their expectation for 10x returns within 4-5 years. If you aren't designing for rapid, exponential growth, raising VC funding will prove challenging.
Product risk pairs with the aforementioned risks, but focuses on the end-user. Have you identified a key emotion or pain point that will trigger a need for your solution?
Originate leverages clickable prototyping to mitigate this risk. By running our target user (someone who matches the persona) through a lower fidelity "concept prototype", we can watch for signals that the solution resonates with them. This is an observational activity (we use the Think-Aloud Protocol), not an inquiry (never ask if someone 'likes it'!!).
Using these observations, we can then flesh out a higher fidelity "experience prototype" and watch for UX tension points that indicate key interactions need to be rethought.
Testing via prototyping greatly increases the likelihood of designing a product version that delivers something of real value to the user.
And by the way, a clickable prototype can also help to mitigate business risk. Nothing attracts stakeholders more than the ability to touch and feel the product early on.
There are two aspects of technical risk that we focus on: Architecture and Confidence of Execution.
With a rapidly changing technology landscape (especially in open source), determining what is risky and what is ready to be built upon is increasingly difficult - a trend that will only accelerate.
Experience with a range of technology stacks and architecture approaches is critical to making wise decisions.
Experience isn't always enough. Specific proof of concepts need to be developed to determine the best technology approach.
Is the framework flexible enough for rapid development? Can it scale to the needs of the launch? (btw - a common mistake is to design for too much scale too early which greatly limits your ability to iterate as you learn)
Is the framework in active development, but not changing so much that your engineer will need to spend half their time keeping up with all the breaking changes of new versions?
Confidence of Execution
Anyone who has built real software has experienced this - the first 80% of the features takes 20% of the time. The real pain comes in attempting to get the final 20% of the features over the finish line. This effort can drag on for months.
Typically, this is caused by features that are much more complex than anticipated. Sometimes that’s because of a poor understanding of the product that’s actually needed (which you can address via prototyping). But often it’s the result of something that was much more difficult to achieve than anyone had realized.
The proof of concept approach can help in mitigating this. To determine a realistic timeline for implementing a complex feature, we can map out the riskiest technical pieces up front and put together throw-away code that will act as a guide. I've seen two days of POC save two months of development time.
Search is a great example. There are 4-hour, 4-day, and 4-month solutions to search. On a wireframe they all look the same - a magnifying glass with an input box.
Is a simple SQL lookup enough? Will Elasticsearch or Algolia out-of-the-box instance suffice? Or perhaps fully customized search with elaborate filtering options is needed? Let’s grab some real data and examine the search results for various queries to find out.
Avoiding these rabbit holes is the key to delivering on time.
Once you have an understanding of the key risks within these four categories, you can rank them and implement mitigation strategies for each. Great products are the result of doing this quickly and thoughtfully.