@wcoolsThe number one priority right now is to get the first version of our product out as soon as possible.
One advantage of time or budget constraints is that it forces you to really think about what the focus should be of your product. Spending a bit of extra time at the beginning to think about how you can simplify the product and reduce the scope saves a lot of time in the long run. The “If I had more time, I would have written a shorter letter” quote is applicable to code, UI, product and marketing as well.
The most obvious way to ship faster is to build less.
Every line of code we’re adding to the product is code we might not have needed in the first place. Maybe certain ideas won’t work out and we need to scrap them later. Or maybe nobody cares about the product in the first place. If the product does take off, we need to maintain all of it. It’s much harder to remove features than it is to add them, in terms of keeping users happy.
This is not the time for premature optimization in our code or being architecture astronauts: we need to ship. That said, spending a bit of time sketching out what screens should roughly look like helps us identity places for re-use.
For example, one of the main components for Thymer will be the editor. On top of that, we also want people to be able to schedule their tasks. If we would dive right in without thinking these features through, we might end up building two completely separate controls for them. Looking at it more closely, they can actually be the same component. We simply might have to make some parts read-only, and date headings will be like headings in a doc, but dynamically generated. And instead of spending a lot of time on a preferences panel, we might just reuse the editor again to show a configuration file or sorts.
Simple products are better products.
Reducing the number of “concepts” doesn’t just reduce the number of components to build. It also makes it much easier for users to understand the product. When there are only one or two core concepts, it’s easy to get a good “mental model” of what the app is and how it works.
For example, many text editors in the past had several modes. Different options were available in different modes, like a view mode and an edit mode. Not only would you need to build both as a developer, but users had to understand the two concepts and deal with working with both. Larry Tesler worked on the idea that interfaces should be modeless (and famously drove around with a “NOMODES” license plate).
Both a good and a bad example of reducing UI concepts is Windows. The Start Menu, introduced with Windows 95, is absolutely brilliant in that sense. Even the most technophobic users only had to learn one concept: whenever you want to do something or you get lost, just click “Start”. Simple to build, simple to pitch, simple to understand.
Windows 8, by huge contrast was a complete mess. There’s a bunch of different start menus, with completely different styles. You had to learn all those concepts and they had to explain why it was better. Same for Settings vs Control panel (and there’s probably more). It takes more time to build, and just confuses the user.
The Home screen and Home button on iPhone is similar to the simple concept of the start menu. I notice how explaining how an Android phone works to a family member without too much tech experience is much more difficult than explaining how to navigate an iPhone. With iPhone you just explain they click one button at any time to get back. Onboarding is way faster with products introducing fewer concepts.
Simplifying the USP and marketing
As a bootstrapped startup, you won’t have the resources to be everything to everyone and outbuild your competitors. You also shouldn’t, because it’s easier to pitch a smaller product to a specific niche than selling large integrated solutions to everyone. You need to build more, need to explain more, need to onboard more, and need more buy-in from more decision makers.
Focusing on just a few core concepts is also important when thinking about your USP and describing why your app is better. Competing against another product which does “A, B and C” by building “A, B, C and D” is typically a bad idea, especially when bootstrapped. So rather than a mix of features and concepts, narrow things down to one simple concept you can describe in a sentence. A lot of marketing is about repeating yourself, and if there are dozens of concepts you need to explain, it waters downs the message about what makes your product worth trying.
