Early-Stage Innovation: Roadmap for an early-stage software venture
Part 1 of 12
A software startup is a fundamentally different type of venture from the early-stages of other products and services. The software industry, at all its varied levels of granularity, evolves at a much faster rate since the speed at which software engineering teams can react to changing customer demands is much faster than the engineering teams for any other industry. As such, entering a segment of the software industry requires a fundamentally different roadmap in order to take an ideated solution to minimum viable product (MVP) launch that can achieve product-market fit, than the roadmap required for launching a manufactured product. While the principles of enterprise and entrepreneurship are generally consistent across industries and their associated sub-sectors, the actual execution of a software startup launch differs uniquely from the executive path one might take in a different industry.
In this series, I will breakdown the practices for taking an idea to minimum viable product launch for a venture in the software industry. This path is the earliest stage of a software venture, and success along this path tends to be the discerning factor in separating “people with ideas” from “software founders.” Further, this series will cover the specific actionable tasks for aspiring founders to engage in before building any technology; given the nature of the software industry, and the speed at which competition emerges and declines, the success of a software product and company largely depends on the proper prioritization of early-stage activities and their execution more so than acquiring financial resources, developing detailed ideas or business cases, or collecting a diverse team of human capital. In other words, the success of the launch depends on the proper execution of priorities with high expected returns.
The essence of this series is to logically construct a prioritized roadmap or guide for aspiring early-stage software founders to follow in order to identify a valid, minimum viable product within a solution space that would constitute the tangible intellectual property of that software startup. The roadmap itself will be constructed around a framework of identifying the most valuable early-stage activities for aspiring founders to execute, and then translating those activities into a parallel framework for identifying your minimum viable product (which would have an associated minimum viable business model). In terms of a financing timeline, this roadmap intends to cover the stretch of time between problem-space identification and pre-seed funding/early-stage build.
The logical scaffold which this roadmap will follow can be imagined along this analogy: consider MVP launch (the destination) to be the summit of a previously uncharted mountain, and consider the starting position to be at its base. There are many potential paths by which one could climb up that mountain, and there are many more paths one could follow that could lead to failure. Further, because this mountain is previously uncharted, there isn’t a definitive path one could take to reach the summit; as such, the climber/entrepreneur has to map out the path forward. In mapping out that path forward, the climber/entrepreneur must make some assumptions about what is most valuable, and it can be assumed that a decision is most valuable if it can propel the climber/entrepreneur closer to the summit, but at minimal possible expense to the climber/entrepreneur. Thus, this constructed roadmap is not a prescriptive path forward, since every mountain/software venture will have different requirements and decisions to make, but rather a guiding set of principles and tools that aspiring software founders can follow in order to chart out a path to reaching MVP launch.
So where do we begin? In the abstract, we need to determine what are the highest priority activities in which aspiring founders should engage. Y-Combinator’s prevailing philosophy, which is consistent with thought leaders ranging from Eric Ries and Steve Blank to Joseph Schumpeter (who articulated a similar sentiment in different words, of course), is that an early-stage founding team should focus on two uses of time: (1) customer discovery and (2) product development. Customer discovery, I define, as the process of understanding personas within your target problem space and their most pressing pain-points for which a software product would be useful. Product development, I define, as systematically organizing a backlog of high-value features and engineering these features in accordance with your backlog.
However, the simplicity of this breakdown should not suggest the processes within each workstream are equally simple – it is quite possible to immediately assume what activities should be executed within each workstream, and consequently, it is quite easy to initiate a bunch of different tasks that we assume will take us to our goal, but are actually distracting resources from the real objectives of each workstream. To this end, it’s necessary to deliberately follow the assumed logic of identifying what is most high-value in terms of reaching the right outcome, and recursively funneling down to a sets of tasks whose outcomes map to different time scales. In potentially more familiar terms, this can be thought of as the process of subdividing workstreams into initiatives, epics, and stories, but for both customer discovery and product development.
So in order to determine what to do within these workstreams, the essentials of which I will cover over the course of this series, we will use the “expected value” framework, which is an analogous logic to the statistical definition of the term, “expected value.” In statistics, the expected value of an event is the sum of the products of each possible outcome and its respective probability of occurrence; in other words, it’s the mean or average event outcome. In launching a software venture, there usually isn’t a clearly quantifiable set of probabilities that map to the outcomes of potential decisions, so we have to make assumptions about the likelihood an outcome will occur; further, we have to define what exactly the “value” of an outcome would be, since it’s not as clear as, say, the result of a dice roll or a bet on a horse race. As such, the “expected value” framework in the context of making decisions along the path from an idea to product launch is more of a logical structure for managing assumptions and being systematic in decision-making, and is structured along the lines of being deliberate in tracking assumptions and ensuring the most valuable actions (consistent with assumptions made by the aspiring founders) are consistently pursued. Further, in the case of a negative outcome, the “expected value” framework allows founders to more systematically address the assumptions that were made along the path leading to the negative outcome and learn from failures in an efficient capacity. Later in the series, we will discuss how to use “expected value” to make decisions, but for now, we can make the assumption that we are going to evaluate activities along the roadmap based off of their “expected” returns to helping launch a minimum viable product.
As such, the specific activities recommended in this process of roadmap construction are activities which are generally believed to be highest value for an early-stage startup (and will be justified along the expected value framework). So taking Y-Combinator’s (and other similar venture organizations) recommendation that early-stage startups focus all of their effort on customer discovery and product development as the larger arcs of activities, this roadmap will be constructed by determining the specific activities that have the highest expected value towards launching a minimum viable product, given context-specific assumptions and hypotheses that inform decisions made.
Taking a step back, the way that I framed early-stage decision making for a software venture seems awfully rigorous and unnecessarily abstract – why am I taking such painstaking care to map out the cognitive framework early-stage software venture builders, instead of focusing on, say, more concrete and practical action items? The pragmatic reason for starting with a mental framework before diving into the details of actual activities (which will be covered) is because the mental framework is the most scalable part of launching a venture; given the nature of entrepreneurship, founders are constantly forced to make numerous decisions in uncharted business, technology, and product territory, and as such, require some sort of consistent system for making decisions about everything from features to customer requests, from hiring new team members to developing a go-to-market plan. Consequently, it is of paramount importance that the decision-making framework is cogent, consistent, and allows for clear retrospective in the case of failure, since it will be responsible for guiding the startup along from idea to product launch. And while a Stanford MBA or twenty-plus years of experience in a particular field may (or may not) be useful, founding a venture is definitional a novel “expedition,” and unilaterally relying on successful strategies, decisions, and experiences from a previous set of experiences opens one up to substantial risk of failure. And this risk of failure isn’t theoretical – 90% of startups fail.
Altogether, this roadmap will aim to advise aspiring founders on how to set up the processes, both mental and managerial, that will allow their software ventures to achieve commercial success. As is the nature of entrepreneurship, a field of charting out the frontiers of business and commerce, there will be cases that defy expectation or assumptions. Thus, “expecting the unexpected,” regardless of how trite and tautological, is an appropriate way to think about the path ahead. With that cliché nestled among our heavily abstracted framework for expected value, let’s begin to construct the rest of this roadmap, beginning with a methodology for prioritizing tasks.