Beyond Logo

author image blog beyond

Written by Alexander Hipp


article image beyond blog

Building Our Startup Roadmap

"The original iPhone did not include cut, copy and paste capability." Early adopters of Apple actually had to wait until iOS 3 to be able to easily copy things (source). But how come that a rather simple yet important feature like this didn't make the feature-set of the first version of iOS?

This example illustrates perfectly on how strategising and roadmapping works in startups or new product lines compared to established businesses. By creating a roadmap we are lying out what the current focus is and what comes next. We also consciously decide on what we don't want to spend time on.

At Beyond, we separate the vision, mission (1-3 years), the mid-term goals (1-3 months) with the current focus (1-3 weeks). Only for this period of 1-3 weeks we are in the position to build a roadmap. Anything beyond that is just pure guessing and very high level. We have a direction but not yet a clear execution plan.

To build a great roadmap we need to know a lot about our users, their problems and what we need to build that has a high chance of solving these problems. In a startup, you normally have none of them. You don't have many users, you have not fully understood the problem and therefore it's super hard to come up with great features or a roadmap.

The focus is on learning. We want to ship the smallest possible increment ("skateboard") of value to real users as fast as possible (source) to validate our biggest assumptions. Because if our assumptions about the users problems and the way we would solve it are wrong we are going out of business superfast.

In the case of the iPhone, the cut copy paste feature didn't make it on the roadmap, since it was not helping them to validate the idea of an iPhone in general. For them it was ok to ship this way later based on real user feedback.

The advantage of working in a startup is that it usually takes way less time to develop things and ship them. Less complexity, less hierarchy and stakeholders and also less users who need to learn a new behaviour. The faster we are able to ship something and learn, the shorter our feedback loops are. In an early-stage startup you don't have months or years to learn, you have weeks.

So instead of preparing months of work in advance we ship a first version of the feature, test it with real users, listen to their feedback and iterate. If something doesn't have the expected effect we either change it, remove it from the product or pivot.

The worst thing you can do in this stage is to build a perfect product ("sports car") for a year and then look for users who might find value in using it.

Join our waiting list

Curate and discover the best content on Beyond.
We're inviting new users every day.

Beyond on