History will teach us… something?
When Tim Berners-Lee first demonstrated the technologies behind what came to become the world wide web, he had little idea of the impact his invention would have. But what has happened since may allow us to look back and better understand how to look forward. While it took a couple of years for the web to move from academic and research circles to a more mainstream and commercialized space, some of the early battles are still reflected in what we see today.
For example, there is a constant struggle for control of the viewing experience on the internet. In the earlier days of the web, that struggle was represented by the browser wars with a large fight exploding between the dominant browser creator at the time (Netscape) and the dominant Operating System vendor at the time (Microsoft). The same fight can be seen today in the struggle over whether web applications or dedicated platform specific applications ought to rule the roost in the future.
The death of Netscape left the web barren for a few years as few contender to the supremacy of Internet Explorer emerged until the Firefox project finally found its footing. Over those years, the web largely stagnated, partly as the result of a deflation of the financial bubble that had arisen over the previous year but also partly as a result of the lack of a credible contender to the dominant browser brand.
Looking forward by looking back
When looking at the future, we can be a lot more hopeful today, because the odds of a winner-take-all have been lowered in some segments of the market. For example, the rise of iOS has been counterbalanced by the rise of Android and an increase in the number of web-based apps. With such a diversity in the mobile space, it also will make it difficult for new entrants to succeed. Marketplace tend to reward only a couple of groups and we are already at a point where we have 3 players. This is bad news for Microsoft and Nokia who are trying to play this from behind and have a real uphill fight to gain any serious traction, no matter how great their offering is.
In the tablet space, the story is a little more worrisome. Apple’s current domination of that market could lead to a new stagnant space unless a contender is identified. Amazon’s positioning of the Kindle Fire as a potential alternative may present opportunities to restore a balance, forcing all players to bring their best game. At this point, it appears that the marketplace has widely rejected other offerings in the tablet space so Amazon’s entry makes this an interesting case. The question at this point is not whether Amazon will topple Apple (it won’t) but whether it will introduce a product that appeals to a segment of the consumer market and forces Apple to keep improving its offering (and here, I would present the iPod roadmap as an example of how innovation dies in a marketplace, even if that marketplace is dominated by Apple: from a product standpoint, the iPods sold today have not really changed since the introduction of the iPod Touch four years ago).
On the standard front, we are seeing some fierce battle lining up in how browser supports new features of HTML5 and related technologies. As I pointed a couple of weeks ago, this is a good thing. The current diversity of browsers in the marketplace forces every player to attempt efforts at being on the cutting edge. This is the kind of thing that will speed up adoption of new technologies across the landscape as a whole and will help the open web become a strong contender for the future of computing. Technologies like HTML5, CSS3, WebAudio, and WebGL are helping the web become more operating system-like and, as such, increase its chances at becoming a strong player on any platform.
But looking at today and looking forward, we are seeing a marketplace that is increasingly fragmented. So what’s a startup with limited resources to do? Should one put all their eggs in a single basket and bet on a single platform? Should a company look at introducing fewer features across all platforms, spreading their product roadmap over a longer timeline? Or should developers go to the lowest common denominator and target through the web browser?
The answer is it’s complicated but, at its core, one needs to think about what is needed to move the company forward and get it to reach early measurement markers while still focusing on the future.
At Keepskor, we call that Roadmap 2025.
I know it sounds extremely ambitious for a company to think to 2025 when it doesn’t yet have a product in the marketplace. But the issue for most startup is not ambition but the lack of such thing. By focusing on Roadmap 2025, we get a sense of how the marketplace is evolving and how we want our product to evolve accordingly. Frequent readers of TNL.net know that this column is not really concerned about the next few months and tends to focus more on the underlying cultural and business trends that can have decade-long impacts. This is why things like the impact of DVRs on the television business were discussed here over a decade ago, or more recently, I looked at what challenges existed for books and television. The 2025 consumer market will be impacted by those changes and the way in which applications designed on the internet interact with that will also be impacted. As will the dominant platforms, one of which, we hope, will be Keepskor.
But how does a Roadmap 2025 look in the present? Well, put quite simply, the present is an early alpha. The minimum viable product the marketplace will accept for something much larger. But the MVP for a platform that will exist in 2025 is substantially bigger than the MVP for a simple app. And building it requires higher levels of abstraction than a normal product. For example, no one really knows what the winning front-ends will be in 2025. What we know is that they will be different than the ones we are used to today. So we design our platform to ensure that input and outputs are separated from everything else. In the short run, this creates an added layer of translation that increases latency (measured in milliseconds) to every transactions but a slowdown we consider acceptable for now.
The basic agile method of development looks to scrums that are moving the product forward in an iterated fashion, tackling one component or another over short cycles. The level of clarity as to what will happen in the next scrums is generally dependent on how far forward you’re looking as each scrum can move a product to the adjacent possible. In a long roadmap model, one iterates backward. For example, if you are looking at what your product looks like in 2025, do you know what it looks like in 2024? You may have a rough idea as to how the product should evolve along the way. Maybe you get a sense of what it looks like in 2020 or 2015?
I call this backwards iteration. Move from the ideal state and start planting base camps backwards. It’s a strategy I learned from long-distance skating (I’ve done runs of up to 65 miles on a single day). No one wins a long distance race by focusing on the end point. The win is only by focusing on the next 100 yards and iterating those forward. But before you do so, you need to have a sense of what you need to do by each of those 100 yard markers. And that means considering how tired you will be and how much slower you will be at the end of the race and working backwards to assess the best balance of expanding and depleting energy vs. yards won.
In a business, this allows you to build a model that is pretty accurate for the first couple of years, and only mildly less so afterwards. It also allows you to go back to the roadmap when major events happen and identify whether they will have any impact on your business (and if they do, whether this impact needs to be mitigated now, and can be mitigated by moving an item forward in the roadmap).
From a communication standpoint, it also makes it easier for people getting involved in your business to get a sense of where you’re looking to go. This may mean that some investors are not interested because they don’t buy into your vision (and that’s OK because those investors would be an issue further down the road if you’re still going down some of the same paths) and also means that some people will not be interested in joining the company because they don’t agree with the steps moving forward. I consider that early filtering as it ensures that your company gets proper buy-in from all stakeholders, thus lowering the chances that employees will leave once they are fully committed.
Study the past, understand the future
But a roadmap 2025 plan is not something that one pulls completely out of thin air. What it is, more than anything, is a set of assumptions based on close study of part events. For example, the majority of the Keepskor roadmap can be explained by events that have already happened. This grounding in history and historical trends helps us ground the business into models that have been proven to work in the past and which, when combined, turn out to be substantially bigger than the initial ideas.
When looking more closely at history, I get a sense that most areas of history have some cyclical component to them, with a pendulum swinging in one direction or the other but always moving us forward ultimately. The study of previous cycles is probably the greatest tool one has in understanding what the future can look like.
However, there is one thing to note: The distant future is easier to prognosticate than the closer one because things actually do change at a much slower pace than most would expect. In the 1990s many dotcommers, present company included, made what looked like wild statements about the future and how the internet would change everything. Circa 1999 and certainly in 2001, those seemed like crazy pronouncements but, in hindsight, the world we described as coming to bear at the turn of the century is pretty much the world we live in today: the revolution has just taken longer to take hold.
A personal note
For years, people have asked me why I was writing TNL.net as I didn’t seem to derive any real income from it and the things I wrote about were, on the whole, only tangentially related to what I do. Over the last year, I’ve come to discover that the writing of TNL.net is a somewhat selfish act. First, it allows me to crystallize a lot of my own thinking: the process of writing and editing an entry forces me to focus on a topic area very closely. It also forces me to review source material and historical data to ground and inform my thinking. And then, there’s the part where you, the reader, enter. Your emails or discussion help me get a better sense of some of the flaw in my argument.
Update: I generally start writing early in the week and fill the entry up over time until it gets published on Sunday evening. This week, Fred Wilson posted “Long Roadmaps”, a great entry that covers some of the same ground. I guess there must be something in the air here in NYC that gets us to think about those things.